How long should I run a GTM experiment before deciding if it works?

Three floors decide the length: the clock, the count and the sales cycle

A GTM experiment runs until three floors are met at the same time: at least two full weeks on the calendar, a minimum number of events per variant that you fixed before the first send, and at least one sales cycle for any metric that sits past the first reply. The date you decide is the date you wrote down before you started.

Most answers to this question give one number, usually two weeks. That number is right as a calendar floor and wrong as an answer, because a GTM experiment is not a page test with thousands of visitors a day. Ten outbound replies in two weeks tell you less than a hundred in four. And if the thing you are testing is whether a segment buys, no number of weeks shorter than your sales cycle can answer it. This page gives the three floors, the minimums per experiment type, the stop rule to write first, and the decision at the end. What to measure inside the test is covered in what to measure in early GTM experiments.

The clock, the count and the road. All three have to be far enough along before you decide.

Floor one: the clock, and why it is counted in whole weeks

The calendar floor is two full weeks, extended in whole weeks, because buyers behave differently on different days and a single week can be an odd one. The floor exists to average out the week, not to produce evidence by itself.

Wingify’s long-running guide states: “The average recommended A/B testing time is 2 weeks” and advises you to “test over at least one business cycle and ideally two.” See how long should you run an A/B test. Product Digest, summarising Kohavi and colleagues’ rule for web experiments, puts it as “a test should cover at least one full week and then extend in whole weeks”, and adds the line that matters for GTM: “The sample size is a floor and the calendar adds a second condition.” Read experiment duration and exposure. GTM Playbook applies the same logic to pipeline tests: run “Long enough to capture at least two full weeks”, in its experimentation framework.

For B2B the week has a shape: Monday inboxes are full, Friday afternoons are empty, and a public holiday in one country removes a day for part of your list. Two weeks gives each weekday two chances. Extending in whole weeks keeps the shape balanced; stopping on a Wednesday because the count was reached overweights the start of the week.

Floor two: the count, with minimums per experiment type

The count floor is the number of events per variant below which you cannot tell signal from luck. It depends on what you are testing, and it has to be fixed before the first send, because a count chosen after you see the numbers is a count chosen to agree with you.

The frameworks that name numbers are practitioner opinion rather than measured research, but they converge. GTM HQ sets per-channel minimums: “100+ contacts contacted, minimum 2 weeks.” for outbound, “1,000+ impressions, minimum 1 week.” for paid, and “30 days minimum for any organic traffic signal.” for content, with the rule that “Minimum run periods must be enforced even when early results look promising or disappointing.” See how to build a GTM experimentation framework. GTM Playbook puts its volume numbers on the baseline, not on the test: its examples measure the current reply rate “over the past 90 days, minimum 1,000 sends”, a landing page “over the past 60 days, minimum 500 visits” and a win rate over “past two quarters, minimum 25 deals”, with the warning that “If you do not have a baseline with sufficient volume, running an experiment is premature.” Its worked hypothesis then tests “across 500 sends to matched prospect profiles”, and it gives the sentence to pin above your desk: “A 3% reply rate on 50 sends is not a significant result.” Metadata’s guide to campaign tests states “The key factor is sample size, not calendar time.” and names a common guideline of a hundred conversions per variation, while noting that lower-volume B2B campaigns may need to run longer; see campaign experimentation.

Experiment type	Event you count	Count floor per variant (practitioner guidance)	Calendar floor	Typical total
Outbound message or subject line	Positive replies	100 contacts sent, ideally more	2 weeks	2 to 3 weeks
Landing page or homepage message	Sessions and one conversion action	A few hundred sessions	2 weeks	2 to 4 weeks
Paid channel test	Impressions and clicks to a conversion	1,000 impressions and enough clicks to see a conversion	1 to 2 weeks	2 to 4 weeks
New channel	Qualified conversations	Enough conversations to compare with your current channel	4 weeks	4 to 8 weeks
New segment or ICP slice	Recognition in calls, next steps	Interviews or contacts per slice, same message, side by side	4 weeks plus one sales cycle	6 to 12 weeks
Pricing or packaging	Accepted proposals	Deals, which means the sales cycle sets the floor	One sales cycle	4 to 8 weeks or longer
Content for organic traffic	Impressions and clicks in search	Days of indexed exposure, not sends	30 days	1 to 3 months

Every duration calculator documents the mechanism behind every row: the smaller the difference you want to detect, the more events you need, and the longer the test runs. Amplitude’s duration estimator says it in one line: “Smaller MDEs require much longer test durations.” At seed stage the lesson is to test for big differences. A message that doubles the reply rate shows up in a hundred contacts; one that improves it by a tenth needs volumes you do not have, and is not worth finding yet. A segment test is the slowest row in the table; how wide the slice should be before you test it is in how narrow a seed-stage ICP should be.

Floor three: the sales cycle, when the metric sits past the reply

Any metric that happens after the first reply, such as a meeting held, a proposal accepted or a deal closed, cannot be judged before at least one sales cycle has passed for the contacts you reached in the first week. If your cycle is six weeks, a four-week pricing test has measured nothing.

This is the floor the two-week rule ignores. GTM Playbook names the problem: “For low-frequency tests (enterprise win rates), you need much larger sample sizes and longer time periods.” The practical way out is to pick a leading indicator that happens inside the window and decide on that, while recording the lagging metric for later. Martal lists the indicators that predict revenue: “Reply rates, meetings booked, SQL conversion rate, and pipeline value are the metrics that predict revenue.” and separates diagnostic metrics from them: “Open rates and send volume are useful for diagnosing deliverability problems”. Read rethinking GTM strategy for 2026. Ziellab’s GTM process framework makes the same point about leading indicators, which it reports monthly “because they move first”, and asks for “A retirement threshold, so a sequence below an agreed reply rate after an agreed sample gets turned off rather than left running.”

So the rule for a slow metric is: decide on the leading indicator at the review date, keep the test’s contacts tagged in the CRM, and read the lagging metric one sales cycle later as a second decision. Both decisions are written in advance.

Write the stop rule before the first send

The length of an experiment is decided before it starts, in a record that names the hypothesis, the baseline, the primary metric, the count floor, the calendar floor, the win and loss thresholds, the review date and the owner. Without that record you have a tactic, and a tactic ends when someone gets bored or excited.

GTM Playbook’s opening sentence is the diagnosis: “Most product marketing experiments are not experiments.” GTM HQ’s version is that teams “run tactics.” Both ask for the same cure. HubSpot’s guide to growth experimentation adds the stopping condition in plain words: “Stop an experiment when it reaches statistical confidence and the result is clear”, and “Extend an experiment when results are directional but inconclusive, the sample size is too small, or external factors skewed performance.” CMCG’s operating rhythm insists each experiment has a decision rule and a retrospective, and runs a weekly review as “a 30-minute standing meeting” where experiments that have reached their decision point are closed; see the experimentation operating rhythm.

The weekly review is where the rule is tested against your patience. Look at execution every week: are the emails arriving, is the page loading, are the right people on the list. Do not look at the result as a verdict until the review date. If you must look, write down what you saw and what you did not change.

Do not change the test while it runs, and write down what happens around it

Once the first send is out, the variant, the list and the metric are frozen until the review date. A change in the middle does not improve the test, it starts a different one with the old data still attached. And the world does not stand still for your two weeks, so the record names the holidays, launches and campaigns that fall inside the window.

GTM HQ gives the common case: “If the outbound reply rate is low after week one and the team revises the subject line, the experiment is now measuring a different hypothesis than it was designed to test.” Its rule is “Run the experiment as designed; capture the new hypothesis for the next test.” GTM Playbook’s checklist has the same line, “Do not change variables mid-experiment”, and adds the second half under contamination control: “A major product launch, a pricing change, or a market event can contaminate an experiment running at the same time.” Wingify’s advice for page tests carries over to GTM: “The same goes for tests during sales or other significant promotional periods that attract atypical internet users.” A public holiday in the Netherlands or a school holiday in half your list does the same thing in the other direction.

Three practical rules. First, list the outside events before you start: public and school holidays in the countries on your list, your own launches and newsletters, a conference your buyers attend, a competitor’s announcement you already know about. Second, if an event lands inside the window, do not stop; extend by a whole week and note the event next to that week’s numbers, so the review can read the dip or the spike for what it was. Third, if you must change something because execution is broken, treat it as GTM HQ does: close the record, write the reason, and start a new one with a new end date. The one thing you may change without restarting is nothing.

Why peeking ruins the answer, and the two legitimate early stops

Checking the result repeatedly and stopping the first time it looks significant produces far more false winners than the nominal error rate suggests. The only legitimate early stops are harm to the people in the test and a broken setup.

Evan Miller’s simulation is the standard reference: “Repeated significance testing always increases the rate of false positives”, and “The more you peek, the more your significance levels will be off.” Stopping at the first reading that crosses the usual five percent threshold, with no real effect present, gives a false positive roughly a quarter of the time in his example, more than five times the nominal rate. His cure is the record from the previous section: “Committing to a sample size completely mitigates the problem described here.” Read how not to run an A/B test. Heinz Marketing’s observation is the human side: “Too often, tests get cut short because we’re eager to see results.” See testing for smarter campaigns and GTM strategy. Wingify adds the complement: “Just remember to be patient, even if you reach your sample size early.”

The two exceptions are not about results. Stop immediately when the test harms prospects: angry replies, spam complaints, a message that misleads. Stop and fix when execution is broken: emails bouncing, a tracking link that fails, the wrong list loaded. Then restart the clock. A good early number is not an exception; it is the moment you are most likely to fool yourself.

Scale, iterate or stop: the decision at the review date

At the review date you make one of three decisions against the thresholds you wrote down: scale if the primary metric beat the win threshold with the count floor met, iterate if the result sits between the thresholds or the diagnostic shows a fixable fault, stop if the metric fell below the loss threshold with the count met. Inconclusive is a valid outcome and gets its own reason.

GTM HQ labels results Confirmed, Rejected or Inconclusive and requires a stated reason for any inconclusive result; it also gates the move from a qualitative first phase to a quantitative second one at “at least 70% of interactions confirm the core premise.” Eric Ries’s framing is older and the same: the job is to “learn whether to pivot or persevere”, and the “unit of progress for Lean Startups is validated learning”; see the Lean Startup principles.

Decision	Condition	What happens next
Scale	Win threshold passed, count floor met, no harm signals	Make it the default; write the next test against the new baseline
Iterate	Between thresholds, or a diagnostic shows a fixable fault	Change one variable; new record, new end date
Stop	Loss threshold passed with the count met	Archive with the reason; reuse the list for the next hypothesis
Extend once	Count short at the review date, execution clean	New end date in whole weeks, then decide; no second extension
Inconclusive	Count met, result between thresholds, nothing to fix	Record the reason; the effect, if any, is too small to chase now

What you keep from each decision is as valuable as the decision. The method for recording it so the next test starts smarter is in GTM experiment learning you can reuse.

Where a 90-day plan fits

A 90-day GTM plan is a container for several experiments of two to six weeks each, not one experiment that runs for ninety days. Treat the quarter as the budget of attempts, and each attempt as its own record with its own end date.

Martal advises founders to “treat the first 90 days of execution as a structured experiment”, with a weekly review cadence. Qatalys’s 90-day GTM plan structures the same quarter as a month of foundation, a month of “Market Activation & Real-World Testing” and a month of “Feedback, Optimization, and Scale”, tells you to “Schedule weekly learning debriefs” and to “Focus on leading indicators: website visits, trial signups, meetings booked, and sales conversations held.” Ziellab is candid about its own ninety-day figure: “That is an estimate from the sequencing above rather than a benchmark.” Use the quarter the same way: a sequence of decided tests, with the leading indicators read weekly and the lagging ones read one sales cycle later. Which tests to put first is covered in which GTM experiments to run first, and the point where the sequence turns into something you can repeat is in turning traction into a repeatable GTM motion.

Pitfalls

• A single two-week rule for every test, including ones whose metric takes six weeks to happen.
• A count floor chosen after the numbers came in.
• Stopping on a strong Tuesday, so the week is unbalanced.
• Blending two segments into one result, then extending until the blend agrees.
• Reading open rate as a result instead of a deliverability check.
• Extending a second time because the first extension was inconclusive.
• Rewriting the subject line in week one because the numbers looked thin, then reading both weeks as one test.
• Running the window across a holiday or your own launch without writing it next to the numbers.
• Treating a quarter as one experiment instead of a sequence of decided ones.

When not to run it as an experiment at all

Do not run something as an experiment when you cannot produce enough events to meet the count floor in a time you can afford, when the decision will be made for other reasons anyway, or when the thing has already been settled by the last test and you are rerunning it in hope. In those cases do the work as a tactic, say so, and spend the experiment budget where a decision depends on it.

Below the floors, the honest form is a learning interview or a pilot with a named customer. Ten conversations with the same three questions teach more than a hundred emails to a list too small to read. Who runs those conversations when there is no team yet is in who runs GTM experiments without a team.

A pre-registration record

Experiment: <name>
Hypothesis: if <change> for <segment>, then <metric> moves from <baseline> to <target>
Primary metric: <one>   Diagnostic: <one>
Count floor per variant: <number of events>   Calendar floor: <weeks, whole>
Sales-cycle floor: <yes/no>; lagging metric <name> read on <date one cycle later>
Win threshold: <number>   Loss threshold: <number>   Between = inconclusive
Early stop only for: harm to prospects, broken execution
Frozen until the review date: variant, list, metric. A change closes this record and opens a new one.
Outside events inside the window: <holidays, launches, campaigns, conferences>
Weekly check (execution only): <day>   Review date (result): <date>
Owner of the decision: <name>
Decision taken: scale / iterate / stop / extend once (new date <date>) / inconclusive, reason <text>
What we keep: <one line for the learning library>

How Piet runs these tests with post-seed founders

Piet Baudoin is an AI-native growth marketer at Poldermarketing, a one-person practice working remotely in Dutch and English. He builds and runs go-to-market work rather than only advising on it: the segment lists, the messages per variant, the CRM tags that keep each test’s contacts readable a sales cycle later, the weekly execution check and the review at the written date.

The aim is the one described on the rest of this site: from invisible to a conversation with the person who decides, through a sequence of tests you can trust. How that fits a wider plan is in how I work. If you want a second pair of eyes on a test you are about to start, or on one you cannot decide, begin with a free growth scan.