Quick definition: Baseline conversion rate is the estimated proportion of an eligible population that completes a defined conversion before a proposed change. It anchors A/B-test sample-size planning, effect-size interpretation, and forecasts, but it is not a fixed property of a product.
What is a baseline conversion rate?
A baseline conversion rate describes current observed performance for a precisely defined funnel outcome. If 420 of 10,000 eligible visitors purchase within seven days, the baseline purchase conversion rate is 4.2%. The word “baseline” does not mean a permanent benchmark. It means the reference rate used for a specific decision, population, attribution window, and date range.
Conversion must be defined before calculating its baseline. A newsletter site may define conversion as confirmed subscription; a marketplace may use completed paid order; a B2B product may use qualified account creation; an app may use completion of a meaningful activation step. Clicks, page views, and form starts can be useful diagnostics, but calling them conversion without a decision-relevant definition weakens the experiment.
The denominator is equally important. “Purchases divided by visitors” differs from purchases divided by eligible visitors, sessions, accounts, trial starts, or exposures. In an A/B test, the safest primary denominator is usually all units eligible and assigned before the treatment can affect their behavior. It includes people who never convert, which captures the full effect of offering the experience.
Formula and metric specification
The basic formula is:
baseline conversion rate = number of converted eligible units / number of eligible units
A complete metric name includes the event, unit, eligibility, and window: “seven-day paid-order conversion per eligible randomized visitor.” It should also state whether cancellations, refunds, duplicate orders, bots, internal users, and delayed conversions are excluded. A rate with a clean formula but an ambiguous population cannot be used reliably for planning.
| Baseline | Numerator | Denominator | Typical question |
|---|---|---|---|
| Session conversion | Sessions with purchase | Eligible sessions | Does this visit produce an order? |
| User conversion | Users who purchase | Eligible users | Does this person convert within the window? |
| Activation rate | Activated accounts | Eligible new accounts | Does onboarding create value? |
| Trial-to-paid rate | Paid subscribers | Eligible trial starts | Does a trial lead to payment? |
Rates are estimates with uncertainty. A baseline measured from 200 users is noisier than one measured from 200,000 comparable users. When conversions are rare, use sufficient history and check that the estimate represents the traffic the experiment will receive.
Using a baseline to plan an A/B test
Sample size for a binary outcome depends strongly on the baseline. To detect a given absolute change, a low baseline often requires more traffic because few units convert. For a given relative lift, the implied absolute difference also changes: a 10% lift from 2% is 0.2 percentage points, while a 10% lift from 20% is 2 points. Planning tools combine baseline rate, minimum detectable effect, alpha, power, allocation, and test direction to estimate required units.
Use a recent baseline from the same eligible population, platform, geography, and measurement window whenever possible. A sitewide quarterly rate can be a poor input for a mobile checkout experiment limited to new visitors from one country. If the experiment has a 14-day attribution window, a same-day dashboard rate understates the maturity of the outcome.
Pick the minimum effect based on a decision threshold, not what makes the test short. A checkout team might need at least +0.3 percentage points to cover engineering cost and operational risk. That threshold, together with the baseline, determines whether the test is feasible. Sample-size planning is more reliable than launching until a convenient number of users accumulates.
Baseline conversion rate in A/B testing
During a randomized test, the contemporaneous control rate becomes the principal reference for the treatment comparison. Historical baseline helps plan, but it should not be substituted for control at readout: campaigns, seasonality, product releases, and traffic mix can change performance. The usual estimate is:
absolute lift = treatment conversion rate − control conversion rate
Report the absolute difference in percentage points and, when useful, relative lift: (treatment − control) / control. A rise from 4.0% to 4.4% is +0.4 points and +10% relative. Both are correct; each gives a different sense of scale.
Randomization should make baseline characteristics comparable across variants in expectation. Check allocation and data quality, particularly when an unexpected control rate differs sharply from planning history. An unexplained sample-ratio mismatch, tracking regression, or eligibility change can make the observed rates untrustworthy.
Worked example: account activation
A product team plans to test an onboarding checklist. In the prior six weeks, 2,400 of 40,000 comparable new accounts completed a key action within seven days, giving a baseline activation rate of 6.0%. The team decides that a lift below 0.6 percentage points is not worth maintaining the checklist. It plans a two-sided test with 90% power and an analysis at the account level.
After calculating the required sample and running over full weekly cycles, control has 1,260 activations among 21,000 accounts, or 6.00%. Treatment has 1,407 among 21,000, or 6.70%. The estimate is +0.70 percentage points, a relative lift of 11.7%. A confidence interval of +0.21 to +1.19 points is more useful than the point estimate alone: it suggests the meaningful threshold is plausible but still conveys uncertainty.
The team checks that the checklist did not merely cause more clicks. It reviews seven-day retention, support contacts, and completion quality. It also confirms the denominator includes every assigned eligible account, not only accounts that opened onboarding. Restricting to openers would condition on behavior affected by treatment and can distort the causal estimate.
Assumptions and edge cases
Baseline rates drift. Pricing, holidays, acquisition channels, app versions, inventory, and competitor activity can all move conversion. Use a rolling history to understand variability, but avoid averaging incomparable periods. When the change affects eligibility itself, define the experiment’s entry criteria before assignment; do not use a post-treatment population as the baseline denominator.
Conversions can be delayed or censored. A 30-day trial cannot have a fully observed 30-day paid-conversion baseline on accounts that started yesterday. Either wait for maturation, use a shorter validated proxy, or clearly label early reads as incomplete. Missing identity links and cross-device behavior can also undercount conversions, especially if the variant changes login or account creation.
Do not use a favorable historical baseline as the control group. Only concurrent randomized control data supports the causal comparison. History is for planning and context, not proof that the treatment caused a difference.
Common mistakes
- Leaving conversion undefined: a click, lead, completed order, and retained subscriber are not interchangeable.
- Using mismatched history: sitewide, old, or differently attributed rates can mis-size a test.
- Ignoring zeros: denominators must include eligible units that did not convert.
- Reporting relative lift alone: percentage points show practical magnitude.
- Reading immature outcomes: delayed conversion and refunds can reverse an early conclusion.
Frequently asked questions
How much historical data should a baseline use?
Use enough recent data to be stable while matching the planned population and relevant business cycle. Several full weeks are often preferable to a few days, but product changes may make older data irrelevant.
Can the control rate differ from the planning baseline?
Yes. Concurrent control is the correct readout reference. Investigate large differences because they may reflect traffic changes, seasonality, or measurement problems.
Should baseline conversion be session- or user-based?
Choose the unit that matches the treatment and decision. Keep it consistent with randomization or use an analysis appropriate for repeated sessions.
What is a minimum detectable effect?
It is the effect size a test is designed to detect with chosen power and error rate. It should be based on practical value, not desired runtime.
Can I use a proxy conversion for faster results?
Yes only if it is validated against the decision outcome and documented as a proxy. Protect against optimizing a fast signal that does not produce durable value.
Summary
Baseline conversion rate is the current estimated rate of a clearly defined conversion among a clearly defined eligible population. It supports realistic sample-size planning and contextual interpretation. In an A/B test, compare treatment with concurrent control, report absolute and relative differences, and verify that the rate’s denominator, window, and measurement remain stable.
Sources
- NIST/SEMATECH e-Handbook: Sample-size determination
- OpenIntro Statistics
- Kohavi, Tang, and Xu: Trustworthy Online Controlled Experiments