Test Duration Calculator
The formula
What the test duration tells you
Converts sample-size math into calendar truth — and enforces the two rules that actually break experiments: weekly cycles and seasonality windows.
Calculation: Days = (per-arm × arms) ÷ (daily × traffic split). Enter your inputs and every substitution is shown below the result.
Reading the result
Two full weeks minimum even when arithmetic says nine days; the weekend cohort is a different animal and one cycle is an anecdote.
Rules of thumb: 2–4 weeks for most CRO; longer only when effects are genuinely small
Limitations and best practice
Novelty effects decay: the first-week variant win is often a dip in second week — duration is a bias control, not just an information clock.
This calculator gives an estimate based on standard formulas; it is not professional financial, medical, legal or engineering advice. Verify anything you plan to act on with a qualified professional and your own records.
Frequently asked questions
Can I end early for a big loss?
Does ramp-up skew the start?
Source & methodology
Experimentation practice.
How Test Duration works — and what your result really means
Time is the one input nobody can renegotiate, which makes getting the arithmetic right worth the minute it takes. Test Duration is the kind of number people argue about from memory. This page ends that argument with arithmetic you can watch happen: enter your figures, get Calendar time required in real time, and see every substitution printed below.
The number itself is the easy part. What takes judgement is knowing which inputs are facts in your situation and which are guesses wearing a decimal point — a distinction this page makes explicit for every field above.
People rarely disagree about arithmetic; they disagree about assumptions that were never written down. Printing the substitution and the sensitivity ranking removes that category of disagreement for Test Duration.
Every figure in the prose is generated by the engine rather than written beside it — the worked example resolves to calendar time required = 29.8 days on the default inputs, and the sensitivity section ranks the inputs that move the result — Daily eligible visitors first, at ≈11.1 % of the headline for a ten-percent error either way in that input. Read the sections in order and you will be able to reproduce every figure by hand.
How Test Duration is computed, line by line
The engine implements a single stated model: Days = (per-arm × arms) ÷ (daily × traffic split). There is no hidden coefficient and no login-gated precision — the formula printed is the formula executed, which is also what makes the result citable.
Visitors needed per arm (example value 12,741) is a numeric input whose unit is fixed by the label; a wrong unit is a wrong answer wearing a plausible disguise. If you are unsure what belongs in this field, look at the printed steps: the substitution shows exactly how the engine uses it.
Variants including control (example value 2) is a numeric input whose unit is fixed by the label; a wrong unit is a wrong answer wearing a plausible disguise. Replace the example with the figure from your own records — the tool recomputes instantly and the printed steps follow your numbers.
Daily eligible visitors (example value 1,748) is a measured number in the unit named by the label; the formula does not convert for you. This input feeds the formula directly; a defensible figure here is worth more than false precision anywhere else.
Share of traffic in test (%) (example value 49) is a numeric input whose unit is fixed by the label; a wrong unit is a wrong answer wearing a plausible disguise. Check the convention first: if the source says “6.5 % per year”, type 6.5 and let the formula do the rest.
A fully worked Test Duration example
Rather than describe the calculation, here it is end to end — every substitution in order, starting from the inputs above. Starting figures: Visitors needed per arm, Variants including control, Daily eligible visitors, Share of traffic in test (%). Run to the end, the calendar time required resolves to 29.8 days — Plan 35 days to cover whole weekly cycles on the bands this tool uses.
- Eligible/day = 1748 × 49% = 856.52
- Days = 12741 × 2 ÷ 856.52 = 30
Weeks (minimum) — 4.3. This is the number experienced users quote when the headline alone would mislead.
Visitors total needed — 25,482.0. If your inputs change, this is usually the first companion figure to move.
Days at 100% traffic — 14.6. This is the number experienced users quote when the headline alone would mislead.
Keep this worked example open while you enter your own figures: matching the shape of the substitution is the fastest way to spot a unit or convention mistake.
The Test Duration corridor: your result across a realistic band
Single-point answers invite false confidence, so the same engine was run across a band around the input that matters most here. Each row is a full recalculation of Test Duration, not an interpolation.
| Daily eligible visitors setting | Calendar time required |
|---|---|
| 80 % of the example value | 37.2 days |
| 90 % of the example value | 33.1 days |
| example inputs | 29.8 days |
| 110 % of the example value | 27.0 days |
| 120 % of the example value | 24.8 days |
Across 5 settings of Daily eligible visitors, the result spans 24.8 days to 37.2 days. A decision that only works at one row of this table is a decision waiting for an input to move. Reproduce it in the form above by editing Daily eligible visitors alone; the substitution steps will follow your figures exactly.
The levers behind Test Duration, ranked by effect
This list was computed for this specific engine just now: each numeric input was nudged ±10 % while every other field held its example value, and the calendar time required was recalculated from scratch. For Test Duration the ranking is measured rather than guessed, and it belongs to these defaults: shift the starting point and the order can shift with it.
- Daily eligible visitors: ten percent up gives 27.0 days, ten percent down gives 33.1 days — ≈11.1 % of the calendar time required either way
- Nudge Share of traffic in test by ±10 % and Test Duration lands between 27.0 days and 33.1 days (sensitivity ≈11.1 %)
- Nudge Visitors needed per arm by ±10 % and Test Duration lands between 26.8 days and 32.7 days (sensitivity ≈10.0 %)
- Variants including control: ten percent up gives 32.7 days, ten percent down gives 26.8 days — ≈10.0 % of the calendar time required either way
Daily eligible visitors is the dominant lever here: ten percent either way moves the result by about 11.1 %, from 27.0 days to 33.1 days. Spend your verification effort there first, and Share of traffic in test is effectively tied with it (≈11.1 % for the same nudge), so verify the pair together. Everything below that can stay approximate, which is a licence to stop chasing data that would not change the decision.
Reading the result: bands, zones and thresholds
The value above only becomes useful the moment you know what it is being measured against. On the example inputs the band reads “Plan 35 days to cover whole weekly cycles”; your own figures place you on a different rung of the same ladder. Before treating the band as fact, note its width: ten percent either way on Daily eligible visitors already spans 27.0 days to 33.1 days. The practical reading rules: ask what would have to change to move you one band. If the answer is “a small, plausible input difference”, the band itself is not the finding — the uncertainty is.
Where Test Duration sits next to similar measures: this tool answers “how much is the Test Duration”, while the related calculators answer “what do I do about it”. Reading the result alone tends to over-weight a single snapshot; pairing it with the companion tools above turns the number into a decision.
Common mistakes with Test Duration (and the fix)
Novelty effects decay: the first-week variant win is often a dip in second week — duration is a bias control, not just an information clock. This calculator gives an estimate based on standard formulas; it is not professional financial, medical, legal or engineering advice. Verify anything you plan to act on with a qualified professional and your own records.
Stopping at the first plausible answer. If the result surprises you, the productive question is which input would have to be wrong for the surprise to disappear — then go check that input.
One mistake is specific to this engine: assuming every input matters equally. The computation above shows Daily eligible visitors dominating — a careful figure there beats false precision everywhere else.
The subtlest error is answering the wrong question precisely. Confirm that calendar time required is actually the quantity your decision needs — the arithmetic is flawless either way, which is what makes the mistake invisible.
Six things to confirm before acting on Test Duration
- Confirm the example values are plausible for your own situation before replacing them.
- Note the date and the inputs beside the number so the figure can be audited later.
- Check Daily eligible visitors before anything else: it is the measured dominant input, ≈11.1 % of Test Duration per ten percent.
- Re-run the calculation with a ±10 % stress on the two most sensitive inputs.
- Compare the result with one independent method or published benchmark.
- Confirm the answer against one independent method or published benchmark for Test Duration.
How to use the Test Duration tool properly
Using a calculator well sounds trivial, but the difference between a decision-grade figure and a throwaway one lives entirely in the routine. The routine for Test Duration takes a minute to learn and applies to every input above.
Step 1 — gather before you type. Test Duration depends on visitors needed per arm, variants including control, daily eligible visitors, share of traffic in test (%). Collect them from a source document — a statement, a report, an invoice, a log — rather than from memory, because recalled inputs are the single largest cause of wrong results. The input you reach for first is usually the one you measured longest ago.
Step 2 — compute the version you would not be embarrassed by. If a stranger audited your inputs, which set would you hand over? Enter that set, read the result, and treat everything else as upside. Re-running a number costs seconds; retracting a decision costs considerably more.
Step 3 — play with the inputs on purpose. Ten percent up, ten percent down, one field at a time. Within a few minutes you will know this calculation better than most people who quote its results. Suspiciously tidy answers deserve the same scrutiny as untidy ones.
Step 4 — ask what would have to be true. Take the result you want and work backwards through the inputs until you find the assumption that produces it; then decide honestly whether that assumption is defensible. If the answer changes your behaviour, it deserves a second run with different assumptions.
Step 5 — schedule the next run. In Business & Entrepreneurship the inputs drift quietly. Put a reminder a quarter out, re-enter the same fields, and read the change rather than the level. Half of a good calculation is knowing which input you would hate to be wrong about.
From calculation to decision: where Test Duration earns its keep
Numbers earn their keep in conversations, and Test Duration is no exception. In Business & Entrepreneurship discussions around Marketing & Growth, this figure decides whether an option stays on the table: it converts an opinionated debate into an arithmetic one, and arithmetic is the only referee both sides accept. If the answer changes your behaviour, it deserves a second run with different assumptions.
The audience for this page is people planning around a point or span in time. In professional Marketing & Growth practice the pattern is always the same — screen with Test Duration, then invest slow analysis only in whatever survives the screen. Repeating a calculation with the same numbers proves only that the arithmetic is reliable — which is worth knowing.
Nothing here is stored or transmitted, so the habit of checking is free: open the page, re-enter current figures, compare with the number you saved last time. Precision is a promise you make about your data; make sure your inputs can keep it.
Test Duration — frequently asked questions
What affects Test Duration the most?
Test Duration is driven above all by Daily eligible visitors. Perturbing only that field by ten percent either way produced 27.0 days against the 29.8 days baseline — a ≈11.1 % response, while Share of traffic in test manages ≈11.1 %.
Do share of traffic in test and daily eligible visitors matter equally?
On these inputs, yes: the two measured within a rounding error of each other — ≈11.1 % and ≈11.1 % of the calendar time required per ten-percent change. Treat them as one pair to verify together rather than ranking them.
What is a typical Test Duration?
With the example inputs on this page the result is 29.8 days, labelled “Plan 35 days to cover whole weekly cycles”. “Typical” varies with situation, which is why every result here ships with its verdict band and its sensitivity list: they turn one figure into a range you can locate yourself inside.
How do I calculate Test Duration by hand?
Three steps: write the formula (Days = (per-arm × arms) ÷ (daily × traffic split)), insert your values, and simplify. The worked example section shows exactly that chain for the default inputs; replicating it once on paper teaches you more about Test Duration than any number of calculator runs.
What happens to Test Duration if daily eligible visitors changes by 10 %?
On these inputs a ±10 % change in daily eligible visitors takes Test Duration to 27.0 days against the 29.8 days example — around 11.1 % of the headline. The same test on every other field is in the sensitivity section.
Is the Test Duration result of 29.8 days good or bad?
Neither, on its own — the label “Plan 35 days to cover whole weekly cycles” is the band this figure falls in for the example inputs, and your own inputs will place you elsewhere on the same ladder. Judge the number against your history and your alternatives, and remember that a ten-percent error in Daily eligible visitors alone moves it by ≈11.1 %.
What does 29.8 days tell me about the business?
It answers the narrow question mechanically and the broad question only in context: Test Duration is one dashboard light, and it pairs with unit economics and cash timing before any bet the business size.
Is Test Duration accurate?
The arithmetic is exact: Days = (per-arm × arms) ÷ (daily × traffic split) is evaluated with full floating-point precision and every substitution is printed in the worked example. What limits accuracy is input quality and the model’s assumptions, so treat the 29.8 days result as the correct answer to the question you typed — and check the assumptions section before acting on it.
Can I end early for a big loss?
Early stopping for harm is defensible with a pre-registered rule; stopping early on a win inflates false-positive rates badly.
Does ramp-up skew the start?
Yes — cache/CDN propagation and measurement settling eat the first day; exclude or pre-declare a burn-in window.
Can this tool see the numbers I type?
It cannot. There is no submission step: the calculation happens in your browser and the result disappears when you close the page. Treat the fields above as a scratchpad rather than a form.
What the labels on this page mean
- Weeks (minimum)
- 4.3 in the default Test Duration calculation — one of the secondary figures an experienced reader checks before trusting the primary number.
- Visitors total needed
- 25,482.0 for the Test Duration worked case; it sits next to the main result because it carries context the headline leaves out.
- Days at 100% traffic
- 14.6 for the Test Duration worked case; it sits next to the main result because it carries context the headline leaves out.
- Calendar time required
- The primary output of this tool: 29.8 days for the default inputs, computed exactly from Days = (per-arm × arms) ÷ (daily × traffic split).
- Worked example
- Every substitution in order, from the example inputs to 29.8 days — the audit trail for the headline figure.
- Verdict band
- The interpretation attached to a result (“Plan 35 days to cover whole weekly cycles” on these inputs), which turns a bare number into a position on a scale.
- Sensitivity (±10 %)
- How far the Test Duration moves when a single input is nudged ten percent either way; the ranked list on this page is computed live from this engine.
The provenance of this Test Duration calculation
The model is published arithmetic implemented exactly as written: Days = (per-arm × arms) ÷ (daily × traffic split). Source of record: Experimentation practice. Any other implementation of this model should return the same figure for the same inputs. If one does not, the difference is in its assumptions — which this page prints and that one probably does not.
This page is an estimation aid, not professional advice. The design rule is simple: two people entering identical figures must get identical answers. Nothing is smoothed, weighted or adjusted behind the scenes; where judgement enters, this page says so and names the input responsible.
Next steps after the calculation
Mark the computed date or span in your calendar with its assumptions attached; plans drift when the inputs do.
This page was written for people planning around a point or span in time, and the promise is that nothing above required trust. Bookmark the tool, re-run it whenever an input moves by more than a few percent, and keep the date with the number.