A hypothesis template is a fill-in-the-blank sentence that makes you state your evidence, the change, who sees it, what you expect to happen, and how you will measure it before an A/B test starts.
The simplest version reads: "Because we saw [evidence], we expect that [change] for [audience] will cause [effect], which we will measure with [primary metric]." Copy the template below, fill every field, and you have a test that can be judged honestly when it ends.
The structure follows Craig Sullivan's Hypothesis Kit, which pushed testing teams toward a "because, if, then" format with the measurement spelled out.
We have added a few fields that come up when results are reviewed later.
For the thinking behind a good hypothesis, see our guide to writing an A/B test hypothesis.
The A/B test hypothesis template
Copy this table into a doc, spreadsheet or ticket.
Each row is one field. The right-hand column is what a reviewer should be able to check.
| Field | What to write | Check before launch |
|---|---|---|
| Because we saw | The evidence: analytics, survey answers, session recordings, heatmaps, support tickets, or a past test | Is there a link to the data, not just an opinion? |
| We expect that | The one change you are making in the variant | Could a developer build it from this line alone? |
| For | The audience: all visitors, mobile only, new visitors, a traffic source | Does the test targeting match this exactly? |
| Will cause | The behavior change and the reason it should happen | Does the reason connect the evidence to the change? |
| Primary metric | The single metric that decides the test | Is it picked now, not after the results come in? |
| Guardrail metrics | Metrics that must not get worse (revenue per visitor, refunds, unsubscribes) | Are they tracked in the testing tool? |
| Minimum effect worth detecting | The smallest lift that would justify shipping | Is the sample size calculated from it? |
| Run length | Planned days and visitors per arm, in full weeks | Will you stop on this date, not on a good-looking day? |
| Decision rule | What you will do if it wins, loses, or is inconclusive | Is the inconclusive case written down too? |
The short version for a ticket title:
Because we saw [evidence], we expect that [change] for [audience] will cause [effect].
We will measure this with [primary metric] over [run length], and ship if [decision rule].
Hypothesis statement template: how to fill in each field
Because we saw
Start with something you observed, not something you believe.
Good inputs are exit or post-purchase survey answers, funnel drop-off in analytics, recordings of people struggling, and results from earlier tests.
"Our competitor does it" is a reason to look for evidence, not evidence.
We expect that [change] for [audience]
Name one change. If the variant changes the headline, the image and the button at once, the test can tell you the bundle won, but not why.
Say who sees it, because a mobile-only problem tested on all traffic dilutes the effect.
Will cause [effect]
Describe the behavior you expect and the mechanism.
"Fewer people will leave at the shipping step because they will know delivery is free" can be wrong in a useful way. "Conversions will go up" cannot.
Primary metric, guardrails and minimum effect
Pick one primary metric before launch, and add guardrail metrics so a higher click rate cannot hide lower revenue.
Then set the minimum detectable effect and turn it into visitors per arm with our sample size calculator.
Decision rule
Write what happens in all three outcomes. The statistical test itself checks your result against a null hypothesis of no difference.
Your business hypothesis is the claim you hope to support.
Keeping them separate stops people from treating "not significant" as "proven wrong."
Filled-in example: a free-shipping banner
Here is the template completed for a real test run by GrowthHit for an ecommerce store where almost every product already shipped free.
Exit surveys showed shoppers were still worried about shipping cost.
| Field | Filled in |
|---|---|
| Because we saw | Exit surveys naming shipping cost as a worry, even though nearly every product shipped free |
| We expect that | A sitewide sticky banner announcing FREE SHIPPING |
| For | All visitors, on all devices |
| Will cause | More completed purchases, because shoppers learn early that the cost they fear does not exist |
| Primary metric | Completed purchases |
| Run length | 15 days, 26,306 visitors per arm |
| Result | +8% completed purchases at 90% confidence |
The hypothesis held, but note the confidence level.
90% is a lower bar than the usual 95%, so a team using this template would record that in the decision rule before launch, not after.
The evidence-to-change link is what makes the result reusable: the lesson is "tell people about a benefit they already have," not "banners work."
Examples where the evidence was strong but the result was not
A good hypothesis does not guarantee a win.
It guarantees you learn something. Clean Commit ran a test on a Shopify store where post-purchase survey answers named delivery cost as a near deal-breaker.
The team made the free-shipping threshold more visible on product pages and saw +2.4% conversion rate and +5.5% revenue per visitor over 27 days, with a 74.6% probability to beat control.
That is not statistically significant, so it counts as inconclusive.
In another Clean Commit test, a ship-date message on every product page came in at -6.9% conversion rate across 21,816 visitors in 24 days, also not significant.
Writing "will cause more orders because buyers know when it arrives" in advance makes it clear the reasoning was not supported, and points to the next question: did the date reassure people, or remind them of a wait?
For more practice, see how a headline taken from customer feedback lifted newsletter sign-ups by 24.31% for Laura Roeder Social Media (12 days, 97% chance to beat original).
The "because we saw" field there is a customer's own words.
Clean CommitClean CommitCommon mistakes when using the template
- Filling "because" after the fact. If the evidence is found once the idea already exists, it is a justification. Start from the data.
- Bundling several changes. ClickLab's benefit-led redesign for WriteWork drew on 1,000+ survey responses and got +144% primary CTA clicks, but as a full redesign it cannot say which part mattered. That is a fine choice when you want a big move, as long as you know you are giving up the "why."
- A vague effect. "Improve engagement" has no direction or size, so any outcome can be called a success.
- Changing the metric later. Picking the metric that moved after the test ends is a common way to report a false win.
- No inconclusive plan. Many tests end without a clear result. Decide in advance whether you will ship, retest with more traffic, or drop the idea.
Where the template fits in your test program
Hypotheses written this way are easy to score in a prioritization framework, because the evidence field makes confidence visible.
After the test, copy the hypothesis into an A/B test report and store it in a learning repository, so the next team can see what was believed, what happened, and why.
Before writing your next hypothesis, search the LiftArchive test database for the element you plan to change.
Someone else's result is often the best "because we saw" you can find.
For the bigger picture, start with our A/B testing guide.