What to A/B 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

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.

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

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

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 instead of stacking changes into one A/B test.

Give it enough traffic and time

• 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

• 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, not just the last step.

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.