A participant target is not yet a review date
A/B Test Duration and Traffic: Plan the Full Horizon
The full timeline has three parts: enough people in both arms, the chosen minimum enrollment period, and time for the last outcomes to mature.
Build the sample and calendar together in the A/B Test Sample Size & Duration Planner. Traffic is your supplied scenario, not a live audience lookup or a forecast.
Separate the sample requirement from the enrollment clock
How long should an A/B test run? Begin by separating the statistical question from the scheduling question. Baseline, useful effect, confidence, power, and allocation determine approximate participant targets under this model. Daily eligible traffic then determines how quickly each arm could reach its target. A chosen minimum period can keep enrollment open longer, and outcome maturity postpones review after enrollment ends. Dividing total sample by a traffic number addresses only part of that chain. It cannot tell you whether the traffic counts the right people, whether both arms fill, or whether recently enrolled outcomes are ready to classify.
Consider a fictional equipment library comparing two membership-page invitations. Eligible newcomers are independently assigned once to A or B by a separate experiment system. Success means a completed membership application within seven days. The organizers supply a 10 percent baseline and choose a two-percentage-point improvement, targeting 12 percent. They plan 95 percent confidence, 80 percent power, and only 25 percent of eligible traffic in B. No particular social platform is required for this example. A platform selection in the planner is a context label and does not provide traffic, assignment, or a different calendar algorithm.
This is a fixed-horizon planning exercise, not a rule to watch results until a significant difference appears. Before launch, specify how participant targets, minimum time, and outcome windows determine the final analysis population and review. The calculator helps expose feasibility but does not write or enforce that protocol. If your design uses repeated participants, shared household decisions, clustered assignment, sequential stopping, or an average such as revenue, the timeline may need a different sample method first. More days do not make an unsuitable independent-person binary calculation appropriate. Establish the experiment’s unit and outcome before polishing its calendar.
Measure combined newly eligible people per calendar day
Daily traffic means new eligible independent people entering the experiment across A and B combined. In the equipment-library scenario, a person returning three times after assignment remains one participant, and an existing member excluded by the entry rule does not become an eligible newcomer merely by loading the page. Raw sessions, page views, impressions, and form interactions can therefore overstate usable recruitment. Establish the denominator using the same eligibility and identity conventions intended for the test. The planner does not deduplicate analytics records or infer the proportion of visitors who qualify. It takes the supplied daily count as a scenario assumption.
The model assumes that count arrives every calendar day. If the team expects 1,000 eligible people on weekdays and almost none on weekends, entering 1,000 does not create a weekday-only schedule. A rough everyday average may be useful for an initial scenario if its basis is stated, but the tool does not model a detailed arrival curve, seasonal spikes, launch bursts, or advertising spend. Compare plausible traffic levels before committing to a deadline. The output is best read as the schedule implied by those assumptions, not as a confidence interval for the date when enough participants will arrive.
Blank daily traffic and zero daily traffic both leave duration unavailable while preserving a valid sample estimate. That distinction matters when the team knows the useful effect but has not secured recruitment. An unavailable timeline is not a zero-day experiment, and the start date alone cannot supply the missing traffic. Conversely, entering a very large count may make the arithmetic fast without making the recruitment credible. Keep the traffic source, deduplication approach, exclusions, and planning period in the brief so another owner can see why the assumed daily count was chosen and whether it still applies before launch.
Calculate time for each arm rather than only the total
Let D be combined eligible people per day and b the fraction assigned to B. Expected daily recruitment is D multiplied by one minus b for A and D multiplied by b for B. Divide each arm’s required people by its own daily recruitment, take the larger result, and round upward to a whole day. This identifies the arm that takes longer to reach its requirement. The calculation is ceil(max(nA / (D * (1 − b)), nB / (D * b))). Using total sample divided by combined traffic can hide the arm-level constraint, especially when actual delivery departs from the planned split.
The real core gives the membership example 7,556 people in A and 2,519 in B, totaling 10,075. Approximate achieved power is 80.0059 percent. At 1,000 combined eligible people daily and 25 percent assigned to B, the assumed daily arrivals are 750 A and 250 B. A needs about 10.0747 days and B about 10.076 days before whole-day rounding. The larger value rounds to 11 traffic days. The tiny difference reflects integer arm targets rather than a meaningful prediction that one group always finishes later. Both targets still need to be respected in the external enrollment records.
Changing allocation is not simply moving the same fixed total between groups. The sample requirement must be recalculated because the power of the comparison depends on both arm sizes. At a 50/50 allocation with the same baseline, effect, confidence, and power, the core requires 3,841 people per arm, 7,682 total, and eight traffic days at 1,000 combined daily. That is a different sample plan, not permission to rebalance the original experiment midway through collection. An unequal split may serve a legitimate operational preference, but its recruitment cost and implementation need to be evaluated before assignment starts.
Apply minimum enrollment without pretending it guarantees coverage
The library chooses a 14-day minimum enrollment period. Enrollment days are the larger of traffic days and minimum days, so the 11-day traffic estimate becomes 14 enrollment days. At the assumed daily rate, the full period could enroll more people than the sample target. That is compatible with a minimum-duration rule. Define beforehand how all eligible participants enrolled during the agreed period enter the analysis. Do not select an especially favorable subset or stop early once the smaller target is reached. The sample estimate is a minimum requirement under the model, not a mandate to discard additional properly enrolled participants.
A minimum period can be chosen to cover an operational cycle, but the calculator does not prove that the chosen days capture every relevant audience pattern. Fourteen calendar days may include two weekends; it does not guarantee representative recruitment, stable demand, or absence of a holiday effect. The minimum is an input chosen by the experiment owner, not an automatically optimized statistical recommendation. Explain the reason for it in the plan. If the business cycle is longer or recruitment is highly concentrated, a short minimum should not be used as evidence that the result generalizes to periods that were barely observed.
More traffic does not always move the final enrollment date. At 2,000 eligible people daily with the same 25 percent B allocation, the core estimates six traffic days, yet the 14-day minimum still controls enrollment. The participant targets remain 7,556 and 2,519 because traffic affects scheduling rather than statistical sample size. Buying additional attention solely to make the review earlier would not help while the minimum remains binding. Shortening the minimum is a separate design decision with its own rationale, not an automatic consequence of a faster recruitment scenario or a reason to inspect early outcomes for a convenient stopping point.
Three clocks, one complete schedule
Calculate enrollment and the mature review date
Enter combined eligible traffic and the intended split, then compare sample accumulation with minimum days before adding the outcome tail.
Add maturity after enrollment and read dates inclusively
The membership outcome allows seven days for an application after assignment, so the plan adds seven maturity days after enrollment. With 14 enrollment days, total duration is 21 days. Starting on 2026-11-11, the inclusive enrollment period ends on 2026-11-24: the start day is day one, not day zero followed by 14 further enrollment days. Adding seven maturity days produces a review date of 2026-12-01. This avoids a common off-by-one mistake. The review date is a calendar date for the scenario, not a timestamp specifying the exact hour when every final participant’s window closes.
The extra seven days do not add seven days of required recruitment to the sample. They give the last enrolled people their stated opportunity to complete the outcome. If the team continues enrolling people during that tail and includes them in the same analysis, those newer people need their own full windows; the original review schedule no longer describes that population. Close enrollment according to the prewritten protocol and keep outcome collection running as needed. The planner does not enforce either action or check completion. Waiting until the displayed date is not proof that every record has matured or that missing outcomes can safely be treated as failures.
Keep an attribution lookback, processing delay, and outcome opportunity distinct. A reporting platform may credit activity under one window while an application can take seven days to complete and a data pipeline takes additional time to reconcile. Choose a maturity allowance that reflects the declared experiment outcome and the practical review process, then document any further operational timing outside this simple model. Zero maturity days is valid only as an input describing the intended plan; it does not establish instant observation. The tool uses calendar-day arithmetic and does not model time zones, business hours, or the distribution of individual conversion delays.
Stress-test the schedule against slower recruitment and smaller lift
Reduce the membership scenario to 200 combined eligible people daily without changing the statistical inputs. A receives an assumed 150 daily and B receives 50. The same sample targets now need 51 traffic days, which exceed the 14-day minimum. Enrollment is therefore 51 days and total duration is 58 days after the seven-day maturity allowance. From a November 11, 2026 start, enrollment ends on December 31 and review falls on January 7, 2027. The calendar can legitimately cross a year boundary. That does not mean the tool has adjusted for holiday recruitment or predicted stable demand through those weeks.
A smaller effect can be even more important than a traffic change. At half the original two-point lift, the target is 11 percent instead of 12 percent. With the original 25 percent B split, the core requires 29,250 people in A and 9,750 in B, totaling 39,000. At 1,000 combined daily, enrollment takes 39 days and the complete horizon takes 46 days. Starting November 11 gives a December 19 enrollment end and December 26 review. This row asks what it would take to detect the smaller alternative; it does not predict that the eventual observed difference will equal one percentage point.
Use these comparisons to decide which constraint is actually binding. If minimum days control, more traffic may only increase enrollment above the target. If traffic days control, a credible recruitment increase can shorten the scenario, but changing the eligible population may also invalidate the baseline. If a smaller useful effect drives a much larger sample, selecting a larger effect for convenience changes the decision sensitivity. Keep the original question visible while negotiating timing. An honest outcome can be that the proposed experiment will not inform the current deadline, even though the arithmetic is valid and the team could still collect descriptive observations.
Handle delays and interrupted runs without moving the goalposts
Actual recruitment will rarely land exactly on the scenario’s daily average. Monitor enrollment counts and implementation health without repeatedly testing for a favorable outcome. Before launch, decide what happens if the required arms are not filled by the intended date, a technical interruption occurs, or a material campaign condition changes. Revising a schedule for an operational reason is different from stopping or extending because the observed effect is attractive. This planner does not provide the sequential inference needed for outcome-dependent stopping. Record deviations and consult the appropriate analysis approach rather than assuming the original power statement remains unchanged after every alteration.
Uneven delivery also requires attention at the arm level. A combined total above 10,075 does not establish that the intended 7,556 A and 2,519 B requirements were met if the actual split drifted. Extra observations in one arm do not automatically replace missing observations in the other. The tool’s duration estimate assumes the requested allocation throughout; it does not optimize an adaptive assignment strategy or import observed daily enrollment. Keep actual counts and assignment checks in the experiment system. If the implemented design differs materially from the plan, document that difference before interpreting the final result or claiming the planned power was achieved.
Very long or extreme scenarios can exceed the tool’s supported calendar range even when integer day counts remain meaningful. In that case, calendar fields are unavailable rather than overflowing into a misleading date. Similarly, an effect scenario with an impossible target or a sample above the per-arm cap is not a zero-duration shortcut. Read statuses before comparing timelines and avoid copying unavailable values as zero into a schedule. A valid main plan can coexist with an unavailable sensitivity row. These boundaries keep the report honest about what was calculated; they do not establish that a theoretically valid multi-year experiment would remain operationally stable.
Publish a schedule brief with explicit owners and assumptions
The library’s handoff should name the 10-to-12 percent rate contrast, 25 percent B allocation, 1,000-person everyday traffic assumption, 14-day minimum, and seven-day outcome window. Include both arm targets and the November 24 enrollment end alongside the December 1 review date. Identify who closes enrollment, checks assignment integrity, and reconciles mature applications. A review date without those owners is only arithmetic on a calendar. Keep the experiment’s actual participant records outside this planner and use the final counts with an appropriate results method once the agreed collection conditions are satisfied. The plan itself contains assumptions, not observed evidence.
Save project keeps the editable JSON so another owner can reproduce or revise the schedule. Copy results and report CSV are useful for a planning handoff, but CSV is not a raw-data input template or the reopening format. The full PDF includes supplied context plus project JSON and report CSV attachments, so notes and private campaign labels can travel with the report. Check all exported material before distribution. After any setting changes, rebuild the result before sharing it again. A saved file is deliberate local preservation, not autosave, a traffic monitor, or a promise that the browser will remember the experiment later.
Once the horizon is feasible, organize surrounding account work independently from experimental assignment. SMTasker supports account-workspace operations, with optional Skye assistance and permission-controlled MCP access where configured; those tools do not supply eligible recruitment, schedule the statistical stopping rule, or certify outcome maturity. Use them for an approved operational task while the experiment owner retains the protocol and evidence. The practical value of this duration plan is a shared agreement about what must happen before review. It can prevent a rushed decision just as usefully as it can confirm that a well-defined test fits the available calendar.
Questions about A/B Test Duration and Traffic
Why not divide total sample by daily traffic and stop there?
The model checks each arm at its own allocation, rounds the slower requirement upward, applies the chosen minimum enrollment period, and then adds outcome maturity. The combined quotient does not express all those conditions.
Does doubling traffic always halve the full duration?
No. In the membership example, doubling daily eligible traffic from 1,000 to 2,000 reduces traffic days from 11 to six, but the 14-day minimum and seven-day maturity allowance keep total duration at 21 days.
What happens when daily traffic is blank or zero?
A valid sample estimate can still be shown, but duration and calendar dates are unavailable. Neither value means a zero-day experiment or supplies a recruitment forecast.
Continue with another planning guide
Plan your two-arm binary-outcome test in the A/B Test Sample Size & Duration Planner, or choose another guide below. Find more practical resources in all free tools.
A feasible horizon needs an operational owner
Organize supported account work around the plan
Explore SMTasker for approved account-workspace routines while keeping recruitment, assignment, enrollment closure, and statistical review under the experiment protocol.