How many A/B tests per month your traffic supports

This calculator is about capacity, not a single test. If you want to know how long ONE test will take, use the A/B test duration calculator. If you want the sample each test needs, use the sample size calculator. Here the question is a roadmap one: how many ideas you can validate per month and per year with the traffic you have.

How to use it

1. Enter the visitors per month on the flow you test and your current conversion rate.
2. Pick the minimum detectable effect: the smallest gain that would still change your decision, relative (%) or absolute (points).
3. Say how many variations a typical test has (2 = A/B; 3 = A/B/C, counting the control).
4. Leave the minimum duration at 14 days (one full weekly cycle) or adjust it to your reality.
5. Read the capacity: tests per month, tests per year and one test's runtime. The line below tells you what is limiting you, traffic or the duration floor.

How it works: the math behind it

The calculator chains the sample-size math with your traffic reality, all running in your browser:

The sample per variation comes from the two-proportion normal approximation (95% confidence, 80% power, two-sided), the same one behind our sample size calculator. The maximum between traffic and floor makes sure no test runs less than a weekly cycle, even with traffic to spare.

Worked example (reproduces the default result)

With the values that come prefilled: 100,000 visitors/month, 5% conversion, +10% relative MDE, 2 variations and a 14-day floor.

• Sample per variation: 31,234 visitors (5% base detecting +10% relative, 95%/80%).
• Test total sample: 31,234 × 2 = 62,468.
• Daily traffic: 100,000 / 30 = 3,333/day.
• Traffic-bound days: 62,468 / 3,333 = 18.7, rounded up to 19 days.
• Days per test: maximum(19, 14) = 19 (traffic wins, it is above the floor).
• Tests per month: 30 / 19 = 1.6. Tests per year: 1.6 × 12 ≈ 19.

That is exactly what the tool shows above when you open the page: about 1.6 tests per month, 19 per year and 19 days per test, limited by traffic.

How to read it, and where it misleads

Capacity is the realistic ceiling of your program, not a target to hit at any cost. It serves two honest decisions: sizing the roadmap (19 tests fit in the year, so prioritize the 19 best hypotheses) and spotting the bottleneck (if traffic is the limit, more variations or a smaller MDE only make it worse; if the calendar is the limit, you have room for bolder ideas).

Limits to keep in mind: the math assumes stable traffic, a binary metric (converted or not) and tests run one at a time on the same flow. It does not model simultaneous tests on different pages (which add capacity), strong seasonality, or the analysis and development time between tests (in practice, leave slack). If your base rate is very low or traffic is small, first confirm each test can win with the significance calculator and read what is A/B testing.

Best practices to speed up without cheating

Test velocity is not running anything faster, it is validating more good hypotheses per year. A few rules raise capacity without inflating the false positive.

• Test on your highest-traffic pages first. That is where the sample fills fast and where the gain is worth most.
• Prefer few variations per test. A/B finishes before A/B/C/D and fits more in the calendar.
• Chase the smallest MDE that would still change your decision, but be honest: an optimistic MDE finishes fast and only fools you.
• Do not stop the test when you see early significance (peeking). Fix the runtime and respect the duration floor.
• Run tests on different flows at the same time when they do not overlap: each flow has its own capacity.

Frequently asked questions

How many A/B tests can I run per month?

It depends on how much sample each test needs and how much traffic you have. Each test consumes a sample (which grows when your base rate is low, the target effect is small, or there are more variations); your daily traffic sets how many days that sample takes to fill. Divide the days in the month by one test's runtime and you get the capacity. With 100k visitors/month, 5% conversion and a +10% relative MDE, that is about 1.6 tests per month.

Why is my test velocity so low?

Almost always it is too little traffic or too small a target effect. Detecting +2% relative costs a huge sample; detecting +10% costs far less. If the capacity disappoints, raise the MDE (chase bigger wins), focus tests on your highest-traffic pages, or concentrate traffic into fewer variations. Testing on a low-traffic site demands more aggressive choices.

Do more variations reduce how many tests I can run?

Yes. The sample per variation stays the same, but the test total is that sample times the number of variations. An A/B/C test (3 variations) consumes 50% more traffic than an A/B, so each test takes longer and fewer fit in a month. It is the trade-off between testing many ideas at once and running more tests across the year.

Why is there a minimum duration per test?

To capture at least one full weekly cycle: behavior differs between weekdays and weekends. Even if your traffic fills the sample in 3 days, stopping before two weeks exposes the result to short-cycle seasonality noise. The default 14-day floor is the market convention; the calculator uses the larger of the traffic-bound runtime and that floor.

How is this different from the A/B test duration calculator?

The duration calculator answers how long ONE test will take. This one answers how many tests fit in your month and your year, that is, your program's capacity. Use the duration tool to plan a specific test and this one to plan the roadmap: how many ideas you can validate per quarter with the traffic you have.

Keep going

Knowing the capacity, plan each test with the A/B test duration calculator and confirm the winners with the A/B test significance calculator. For the business context, see the complete CRO guide. New to it? Start with what is A/B testing.