A/B Test Setup
When to Use
Use this skill when you need when the user wants to plan, design, or implement an A/B test or experiment, or build a growth experimentation program. Also use when the user mentions "A/B test," "split test," "experiment," "test this change," "variant copy," "multivariate test," "hypothesis," "should I test this,"...
You are an expert in experimentation and A/B testing. Your goal is to help design tests that produce statistically valid, actionable results.
Initial Assessment
Check for product marketing context first:
If .agents/product-marketing.md exists (or .claude/product-marketing.md, or the legacy product-marketing-context.md filename, in older setups), read it before asking questions. Use that context and only ask for information not already covered or specific to this task.
Before designing a test, understand:
- Test Context - What are you trying to improve? What change are you considering?
- Current State - Baseline conversion rate? Current traffic volume?
- Constraints - Technical complexity? Timeline? Tools available?
Core Principles
1. Start with a Hypothesis
- Not just "let's see what happens"
- Specific prediction of outcome
- Based on reasoning or data
2. Test One Thing
- Single variable per test
- Otherwise you don't know what worked
3. Statistical Rigor
- Pre-determine sample size
- Don't peek and stop early
- Commit to the methodology
4. Measure What Matters
- Primary metric tied to business value
- Secondary metrics for context
- Guardrail metrics to prevent harm
Hypothesis Framework
Structure
Because [observation/data],
we believe [change]
will cause [expected outcome]
for [audience].
We'll know this is true when [metrics].
Example
Weak: "Changing the button color might increase clicks."
Strong: "Because users report difficulty finding the CTA (per heatmaps and feedback), we believe making the button larger and using contrasting color will increase CTA clicks by 15%+ for new visitors. We'll measure click-through rate from page view to signup start."
Test Types
| Type |
Description |
Traffic Needed |
| A/B |
Two versions, single change |
Moderate |
| A/B/n |
Multiple variants |
Higher |
| MVT |
Multiple changes in combinations |
Very high |
| Split URL |
Different URLs for variants |
Moderate |
Sample Size
Quick Reference
| Baseline |
10% Lift |
20% Lift |
50% Lift |
| 1% |
150k/variant |
39k/variant |
6k/variant |
| 3% |
47k/variant |
12k/variant |
2k/variant |
| 5% |
27k/variant |
7k/variant |
1.2k/variant |
| 10% |
12k/variant |
3k/variant |
550/variant |
Calculators:
For detailed sample size tables and duration calculations: See references/sample-size-guide.md
Metrics Selection
Primary Metric
- Single metric that matters most
- Directly tied to hypothesis
- What you'll use to call the test
Secondary Metrics
- Support primary metric interpretation
- Explain why/how the change worked
Guardrail Metrics
- Things that shouldn't get worse
- Stop test if significantly negative
Example: Pricing Page Test
- Primary: Plan selection rate
- Secondary: Time on page, plan distribution
- Guardrail: Support tickets, refund rate
Designing Variants
What to Vary
| Category |
Examples |
| Headlines/Copy |
Message angle, value prop, specificity, tone |
| Visual Design |
Layout, color, images, hierarchy |
| CTA |
Button copy, size, placement, number |
| Content |
Information included, order, amount, social proof |
Best Practices
- Single, meaningful change
- Bold enough to make a difference
- True to the hypothesis
Traffic Allocation
| Approach |
Split |
When to Use |
| Standard |
50/50 |
Default for A/B |
| Conservative |
90/10, 80/20 |
Limit risk of bad variant |
| Ramping |
Start small, increase |
Technical risk mitigation |
Considerations:
- Consistency: Users see same variant on return
- Balanced exposure across time of day/week
Implementation
Client-Side
- JavaScript modifies page after load
- Quick to implement, can cause flicker
- Tools: PostHog, Optimizely, VWO
Server-Side
- Variant determined before render
- No flicker, requires dev work
- Tools: PostHog, LaunchDarkly, Split
Running the Test
Pre-Launch Checklist
During the Test
DO:
- Monitor for technical issues
- Check segment quality
- Document external factors
**Avoi
1---2name: ab-testing3description: When the user wants to plan, design, or implement an A/B test or experiment, or build a growth experimentation program.4---567# A/B Test Setup8## When to Use910Use this skill when you need when the user wants to plan, design, or implement an A/B test or experiment, or build a growth experimentation program. Also use when the user mentions "A/B test," "split test," "experiment," "test this change," "variant copy," "multivariate test," "hypothesis," "should I test this,"...111213You are an expert in experimentation and A/B testing. Your goal is to help design tests that produce statistically valid, actionable results.1415## Initial Assessment1617**Check for product marketing context first:**18If `.agents/product-marketing.md` exists (or `.claude/product-marketing.md`, or the legacy `product-marketing-context.md` filename, in older setups), read it before asking questions. Use that context and only ask for information not already covered or specific to this task.1920Before designing a test, understand:21221. **Test Context** - What are you trying to improve? What change are you considering?232. **Current State** - Baseline conversion rate? Current traffic volume?243. **Constraints** - Technical complexity? Timeline? Tools available?2526---2728## Core Principles2930### 1. Start with a Hypothesis31- Not just "let's see what happens"32- Specific prediction of outcome33- Based on reasoning or data3435### 2. Test One Thing36- Single variable per test37- Otherwise you don't know what worked3839### 3. Statistical Rigor40- Pre-determine sample size41- Don't peek and stop early42- Commit to the methodology4344### 4. Measure What Matters45- Primary metric tied to business value46- Secondary metrics for context47- Guardrail metrics to prevent harm4849---5051## Hypothesis Framework5253### Structure5455```56Because [observation/data],57we believe [change]58will cause [expected outcome]59for [audience].60We'll know this is true when [metrics].61```6263### Example6465**Weak**: "Changing the button color might increase clicks."6667**Strong**: "Because users report difficulty finding the CTA (per heatmaps and feedback), we believe making the button larger and using contrasting color will increase CTA clicks by 15%+ for new visitors. We'll measure click-through rate from page view to signup start."6869---7071## Test Types7273| Type | Description | Traffic Needed |74|------|-------------|----------------|75| A/B | Two versions, single change | Moderate |76| A/B/n | Multiple variants | Higher |77| MVT | Multiple changes in combinations | Very high |78| Split URL | Different URLs for variants | Moderate |7980---8182## Sample Size8384### Quick Reference8586| Baseline | 10% Lift | 20% Lift | 50% Lift |87|----------|----------|----------|----------|88| 1% | 150k/variant | 39k/variant | 6k/variant |89| 3% | 47k/variant | 12k/variant | 2k/variant |90| 5% | 27k/variant | 7k/variant | 1.2k/variant |91| 10% | 12k/variant | 3k/variant | 550/variant |9293**Calculators:**94- [Evan Miller's](https://www.evanmiller.org/ab-testing/sample-size.html)95- [Optimizely's](https://www.optimizely.com/sample-size-calculator/)9697**For detailed sample size tables and duration calculations**: See [references/sample-size-guide.md](references/sample-size-guide.md)9899---100101## Metrics Selection102103### Primary Metric104- Single metric that matters most105- Directly tied to hypothesis106- What you'll use to call the test107108### Secondary Metrics109- Support primary metric interpretation110- Explain why/how the change worked111112### Guardrail Metrics113- Things that shouldn't get worse114- Stop test if significantly negative115116### Example: Pricing Page Test117- **Primary**: Plan selection rate118- **Secondary**: Time on page, plan distribution119- **Guardrail**: Support tickets, refund rate120121---122123## Designing Variants124125### What to Vary126127| Category | Examples |128|----------|----------|129| Headlines/Copy | Message angle, value prop, specificity, tone |130| Visual Design | Layout, color, images, hierarchy |131| CTA | Button copy, size, placement, number |132| Content | Information included, order, amount, social proof |133134### Best Practices135- Single, meaningful change136- Bold enough to make a difference137- True to the hypothesis138139---140141## Traffic Allocation142143| Approach | Split | When to Use |144|----------|-------|-------------|145| Standard | 50/50 | Default for A/B |146| Conservative | 90/10, 80/20 | Limit risk of bad variant |147| Ramping | Start small, increase | Technical risk mitigation |148149**Considerations:**150- Consistency: Users see same variant on return151- Balanced exposure across time of day/week152153---154155## Implementation156157### Client-Side158- JavaScript modifies page after load159- Quick to implement, can cause flicker160- Tools: PostHog, Optimizely, VWO161162### Server-Side163- Variant determined before render164- No flicker, requires dev work165- Tools: PostHog, LaunchDarkly, Split166167---168169## Running the Test170171### Pre-Launch Checklist172- [ ] Hypothesis documented173- [ ] Primary metric defined174- [ ] Sample size calculated175- [ ] Variants implemented correctly176- [ ] Tracking verified177- [ ] QA completed on all variants178179### During the Test180181**DO:**182- Monitor for technical issues183- Check segment quality184- Document external factors185186**Avoi