Gera Tools

A/B Test Hypothesis Generator

Testable hypotheses for conversion optimization

Generates A/B test hypothesis statements in the If/Then/Because format for common conversion optimization scenarios. A practical starting point for CRO practitioners and product managers planning experiments. It runs free in your browser on Gera Tools, with nothing uploaded.

Last updated Source: Gera Tools

What is the If/Then/Because format?

It is the standard CRO hypothesis structure: If we make a specific change, then a measurable metric will move, because of a stated reason about user behaviour. It forces every test to name a change, an outcome, and a rationale.

A weak experiment starts with “let’s try a green button”; a strong one starts with a hypothesis you can prove wrong. This tool assembles A/B test hypotheses in the industry-standard If/Then/Because structure so every test you plan names a change, a measurable outcome, and a reason rooted in user behaviour.

The If/Then/Because structure and why it works

The format forces three disciplines that most ad-hoc test ideas skip:

  • If — names exactly one change, at a specific element, in observable terms. “If we add a testimonial from a named customer beneath the pricing table” is a hypothesis; “if we improve the page” is not.
  • Then — commits to a primary metric and a direction. Choosing the metric before the test prevents outcome-shopping, where you test one metric and report whichever one moved.
  • Because — states the behavioural mechanism. This is where the learning lives. A good Because clause predicts why the change will work, which lets you build generalizable knowledge rather than a catalogue of unexplained wins.

How it works

Each hypothesis is built from three slots. The If clause names a concrete change to a real funnel element (headline, CTA copy, form length, social proof, page speed). The Then clause names a measurable outcome and a direction, such as increase signup completion rate or reduce checkout abandonment. The Because clause states a behavioural rationale, for example because reducing fields lowers cognitive load. The generator draws each slot from a focus-matched pool, so a checkout hypothesis pulls checkout-relevant changes and metrics rather than random ones.

Examples by funnel stage

Landing page:

If we add a 3-sentence customer testimonial above the fold,
then trial signups will increase,
because social proof reduces scepticism in first-time visitors.

Checkout:

If we display a trust badge beside the payment form,
then checkout completion rate will increase,
because payment anxiety is a common abandonment trigger at this step.

Signup form:

If we shorten the signup form from 6 fields to 3,
then signup completion rate will increase,
because reducing the number of required fields lowers friction and cognitive load.

Prioritising which tests to run first

Not every hypothesis is worth running. Before committing a test to a sprint, score it on two axes: expected impact (how much could this move the metric?) and implementation effort. Run high-impact, low-effort tests first. A hypothesis that requires a full redesign to test but only moves a secondary metric belongs later in the backlog than a copy change that addresses a known user concern.

Practical notes

  • Test one change per hypothesis. If you alter the headline and the button colour together, a win tells you nothing about which one worked.
  • Always attach a real baseline and a target. “Increase conversion” becomes testable as “increase from 4.2% to at least 5.0%”.
  • Prioritise hypotheses by expected impact and ease, not by how clever the idea sounds. The boring form-shortening test often beats the redesign.
  • Use this tool to build a backlog quickly, then review as a team to rank by priority before assigning to a test calendar.