A/B Testing Memory Requirement Calculator Examples
Worked examples show how participant volume, event payload size, experiment count and overhead change monthly A/B testing data capacity.
These examples use the monthly capacity formula to show how different experimentation programs can produce very different data footprints. They are planning illustrations, not measurements of a specific platform's storage or RAM use.
Small product experiment program
A product team expects 10,000 monthly participants, two active experiments and three stored events for each participant in each experiment.
Input Summary
Monthly test participants
10,000 visitors
Active experiments
2
Variants per experiment
2
Tracked events per participant
3
Event payload size
1 KB
Assignment record size
150 bytes
Variant configuration size
25 KB
Overhead allowance
25%
Calculation Breakdown
- 1Event records10,000 × 2 × 360,000 events
- 2Event data60,000 × 1 × 1,02461,440,000 bytes
- 3Assignment and configuration data(10,000 × 2 × 150) + (2 × 2 × 25 × 1,024)3,102,400 bytes
- 4Monthly capacity(61,440,000 + 3,102,400) × 1.25 ÷ 1,073,741,8240.08 GB
Result Summary
Monthly capacity
0.08 GB
A/B Testing Memory Requirement Calculator
Estimated monthly capacity is approximately 0.08 GB for 60,000 event records.
Growing experimentation program
A team has 100,000 monthly participants and stores four 1.5 KB events for each participant in each of three active experiments.
Input Summary
Monthly test participants
100,000 visitors
Active experiments
3
Variants per experiment
2
Tracked events per participant
4
Event payload size
1.5 KB
Assignment record size
200 bytes
Variant configuration size
50 KB
Overhead allowance
30%
Calculation Breakdown
- 1Event records100,000 × 3 × 41,200,000 events
- 2Event data1,200,000 × 1.5 × 1,0241,843,200,000 bytes
- 3Base data1,843,200,000 + 60,000,000 + 307,2001,903,507,200 bytes
- 4Monthly capacity1,903,507,200 × 1.30 ÷ 1,073,741,8242.30 GB
Result Summary
Monthly capacity
2.30 GB
A/B Testing Memory Requirement Calculator
Estimated monthly capacity is approximately 2.30 GB for 1.2 million event records.
High-volume program with lean events
A team has 1 million monthly participants in four active experiments, with two 0.75 KB events stored per participant per experiment.
Input Summary
Monthly test participants
1,000,000 visitors
Active experiments
4
Variants per experiment
3
Tracked events per participant
2
Event payload size
0.75 KB
Assignment record size
180 bytes
Variant configuration size
60 KB
Overhead allowance
35%
Calculation Breakdown
- 1Event records1,000,000 × 4 × 28,000,000 events
- 2Event data8,000,000 × 0.75 × 1,0246,144,000,000 bytes
- 3Assignment data1,000,000 × 4 × 180720,000,000 bytes
- 4Monthly capacity(6,144,000,000 + 720,000,000 + 737,280) × 1.35 ÷ 1,073,741,8248.63 GB
Result Summary
Monthly capacity
8.63 GB
A/B Testing Memory Requirement Calculator
Estimated monthly capacity is approximately 8.63 GB for 8 million event records.
Rich-event, multi-experiment program
A team expects 250,000 monthly participants, five active experiments and six 3 KB events per participant per experiment.
Input Summary
Monthly test participants
250,000 visitors
Active experiments
5
Variants per experiment
4
Tracked events per participant
6
Event payload size
3 KB
Assignment record size
300 bytes
Variant configuration size
100 KB
Overhead allowance
40%
Calculation Breakdown
- 1Event records250,000 × 5 × 67,500,000 events
- 2Event data7,500,000 × 3 × 1,02423,040,000,000 bytes
- 3Base data23,040,000,000 + 375,000,000 + 2,048,00023,417,048,000 bytes
- 4Monthly capacity23,417,048,000 × 1.40 ÷ 1,073,741,82430.53 GB
Result Summary
Monthly capacity
30.53 GB
A/B Testing Memory Requirement Calculator
Estimated monthly capacity is approximately 30.53 GB for 7.5 million event records.
How to Read Your Results
The monthly event-record output shows the estimated number of stored event records, not the number of unique visitors.
The base footprint is the calculated raw data total before the overhead allowance.
The final GB result includes the selected allowance and is most useful as an initial monthly capacity estimate.
Compare scenarios by changing one driver at a time, such as payload size or events per participant.
For multi-month retention planning, start with the monthly result and separately account for retention, growth, archives and copies.
Assumptions & Important Notes
- Each participant is included in every entered active experiment.
- Event payload sizes represent average stored sizes rather than raw request sizes.
- The examples use 1,024 bytes per KB and 1,073,741,824 bytes per GB.
- Overhead is represented as a single percentage and may not match every system component.
- Results estimate one month of data generation only.
Related Examples
Frequently Asked Questions
Why do the examples use event records rather than total website events?
The calculation focuses on events stored in connection with experiment participation. Site events outside the entered experiment exposure are not included unless represented in the inputs.
Which input most affects the monthly capacity result?
In many cases, participant volume, active experiments, events per participant and event payload size are the largest drivers because they multiply together.
Can I use these examples for a server RAM estimate?
Not directly. The examples estimate a monthly data footprint; live RAM depends on caching, query patterns, database engines and application architecture.
How can I estimate capacity for six months of retention?
Use the monthly result as a starting point, multiply by the retained months, then adjust separately for growth, compression, archival rules and extra copies.
Ready to calculate your own result?
Use the live calculator with your own inputs, timing, and preferences.