# What to A/B test (/docs/guides/what-to-test)



A/B testing is most useful when you test the right things, for the right reasons. This guide helps you decide what to test without needing to write any code.

## Start with a hypothesis [#start-with-a-hypothesis]

A good test starts with a sentence you can prove or disprove:

> *"If we **change X**, then **metric Y** will improve, because **reason Z**."*

For example: *"If we make the call-to-action say 'Start free trial' instead of 'Sign up', more visitors will start a trial, because it sets clearer expectations."*

If you can't fill in that sentence, you're not ready to test yet; you're guessing. Decide your **conversion event** (the goal) before you build anything; see [Events](/docs/guides/events).

## Ideas for what to test [#ideas-for-what-to-test]

You can test almost any visible change. The highest-impact areas are usually:

* **Calls to action**: button copy, colour, size, and placement.
* **Headlines & copy**: the first thing visitors read; often the biggest lever.
* **Forms**: number of fields, layout, single-page vs multi-step.
* **Layout & hierarchy**: what's shown first, what's above the fold.
* **Social proof**: reviews, logos, ratings, "X people bought this".
* **Pricing presentation**: how plans are framed (not necessarily the price itself).
* **Images & media**: hero images, product shots, video vs static.
* **Navigation**: menu labels, ordering, how many options.
* **Timing**: when a popup or prompt appears.

## Prioritise with impact vs. effort [#prioritise-with-impact-vs-effort]

You'll have more ideas than traffic to test them. A simple way to rank them is **impact × confidence ÷ effort**:

* **Impact**: how much could this move the goal metric?
* **Confidence**: how sure are you it'll help (evidence, past data, research)?
* **Effort**: how hard is it to build and ship?

Run the high-impact, low-effort ideas first. Pages with the most traffic and the clearest goal are the best place to start, because they reach a result fastest.

## Test one change at a time [#test-one-change-at-a-time]

Change one thing per test so you know *what* caused the result. If you want to test several independent elements at once (e.g. headline **and** image **and** button), use a [multi-variant test](/docs/guides/multi-variant-tests) instead of stacking changes into one A/B test.

## Give it enough traffic and time [#give-it-enough-traffic-and-time]

<Callout type="warn">
  Don't stop a test the moment one variant looks ahead. Early numbers swing
  wildly on small samples and "peeking" leads to wrong calls.
</Callout>

* Let the test run until it has gathered enough visitors and conversions to be **statistically significant** (Improve surfaces this on the test Monitor).
* Run for **full weeks** where possible, so weekday/weekend behaviour evens out.
* Lower-traffic pages need to run longer to reach a reliable result.

## Common pitfalls [#common-pitfalls]

* **No clear hypothesis**: testing for the sake of it.
* **Changing too much at once**: you can't tell what worked.
* **Stopping too early**: calling a winner before the result is significant.
* **Too little traffic**: the test can't reach a conclusion in a reasonable time.
* **Ignoring the funnel**: a variant can win on clicks but lose on the final goal. Track the [full funnel](/docs/guides/events#conversions-and-the-funnel), not just the last step.

## After the test [#after-the-test]

* **Winner?** Roll the change out to everyone, then look for the next idea.
* **No difference?** That's still a result: it tells you that change doesn't matter to your visitors, so spend effort elsewhere.
* **Lost?** Even better learning: you avoided shipping something that would have hurt.

Keep a running list of what you tested and learned. Over time that record is as valuable as the wins.