/experiment-design

name: experiment-design
description: Framework for running single-variable cold email experiments. Defines experiment types (list-only, copy-only, combined), confidence weighting, minimum sample sizes, and success criteria. Use when the user wants to improve a campaign, test a new list vs old one, or compare copy variants. Prevents the #1 learning-loop mistake — changing list + copy + offer at once and losing all signal.

Experiment Design

If you change your list, your copy, and your offer at the same time, you learn nothing. This skill forces you to isolate one variable per experiment so you actually learn what's working.

Why this exists

Most cold email operators run "throw-everything" experiments. Campaign 1 gets a new list, new copy, and a new offer. It works better. They declare victory. But they can't tell you WHY — was it the list? The copy? The offer?

Then campaign 2 changes all three again. Regression. Nobody knows why.

This skill is the antidote: plan each experiment around ONE variable, keep everything else constant, and confidence-weight the results.

The three experiment types

A. List-only experiment

• **What varies:** the list (targeting criteria)
• **What stays fixed:** copy, offer, sending infrastructure, sequence timing
• **What you learn:** whether this segment is a better fit than the baseline
• **Confidence on learnings:** HIGH on targeting, LOW on copy (because copy wasn't tested)

B. Copy-only experiment

• **What varies:** the copy (subject, body, sequence, or A/B variant)
• **What stays fixed:** list, offer, infrastructure
• **What you learn:** whether this copy resonates with this audience
• **Confidence on learnings:** HIGH on copy, LOW on targeting

C. Combined experiment (use sparingly)

• **What varies:** list AND copy (and sometimes offer)
• **What stays fixed:** only infrastructure
• **When to use:** launching a whole new campaign for a new ICP. You can't isolate because everything is new.
• **Confidence on learnings:** MEDIUM on everything. Use as hypothesis-generation, not conclusion.

The Framework

Step 1: Name your hypothesis

Every experiment starts with a one-sentence hypothesis:

> "Targeting Heads of Marketing at 50-200 person B2B SaaS companies will get a higher positive reply rate than our current VP Sales baseline, because [reason]."

Or:

> "Leading with a question about their recent product launch will get a higher reply rate than our current benefit-focused opener, because [reason]."

If you can't write the hypothesis in one sentence, you don't understand the experiment yet. Go back.

Step 2: Identify the single variable

Write down exactly what changes and what stays the same.

Variable: Target job title
Change: "VP Sales" → "Head of Marketing"

Constants:
- Industry filter: unchanged
- Headcount: unchanged
- Geography: unchanged
- Copy: unchanged (same 4-step sequence)
- Offer: unchanged (same lead magnet)
- Sending infrastructure: unchanged (same 20 domains, 40 inboxes)
- Send schedule: unchanged

If ANY constant is actually changing, stop. Either lock it down, or reclassify as a combined experiment.

Baseline sanity check — the 1% rule

Before running any experiment, confirm your baseline is healthy: **overall reply rate ≥1% after 200+ sends.** If your baseline is below 1% after 200 sends, the problem isn't your experiment — your infrastructure or copy is already broken. Run `/email-deliverability-audit` first.

Running an experiment on a broken baseline is wasted effort: you'll learn that "both arms are bad," not "which arm wins."

Step 3: Calculate minimum sample size

The smaller your effect, the more leads you need. Use these rough rules for cold email:

| Current baseline | Expected lift | Minimum sends per arm | |---|---|---| | 1% positive reply rate | 2x (1% → 2%) | ~500 | | 1% positive reply rate | 1.5x (1% → 1.5%) | ~2,000 | | 1% positive reply rate | 1.2x (1% → 1.2%) | ~10,000 | | 2% positive reply rate | 2x (2% → 4%) | ~250 | | 2% positive reply rate | 1.5x (2% → 3%) | ~1,000 |

Rule of thumb: **if your test has fewer than 500 sends per arm, you can't tell signal from noise.**

For most beginners, 2,000 sends per arm is the right default.

Step 4: Build the success criteria up front

Before launching, write:

Success = positive reply rate > X% (our current baseline is Y%)
Failure = positive reply rate < Z%
Inconclusive = between X and Z
Required sample: at least N sends per arm, reported after day 21 of sequence

Decide now — not after seeing the data. This prevents "oh we learned something else instead" rationalization.

Step 5: Launch both arms simultaneously

Same day, same sending infrastructure split, same sequence. If your control arm sends Monday and your variant arm sends Thursday, day-of-week effects will confound the test.

Best practice in Smartlead/Instantly: create two campaigns, assign each half of your inboxes, launch at the exact same time, same schedule.

Step 6: Measure at day 21

Wait until the full sequence (typically Day 0, 3, 7, 11 + reply grace period) has finished for ALL leads. Measuring earlier biases toward the first email's reply rate.

Pull metrics via `/positive-reply-scoring` skill:

• Total sent (per arm)
• Total replies (per arm)
• Positive replies (per arm, classified by Claude)
• Positive reply rate = positive replies / total sent

Secondary metrics (report but don't optimize for):

• Overall reply rate (positive replies / total sent is primary, but this shows raw engagement)
• Open rate (if available)
• Bounce rate (sanity check — if one arm bounces more, your list is bad, not your copy)

Step 7: Weight the learnings

Use this framework when reporting:

Experiment: <name>
Type: List-only | Copy-only | Combined
Variable: <what changed>

Result: <winner name> at <positive reply rate>% vs <baseline>%
Confidence: HIGH | MEDIUM | LOW (based on experiment type + sample size)

Learnings (by confidence):
  HIGH confid