A/B Testing & Experimentation
A/B Testing and Experimentation
Plan and run experiments that compare two experiences, measure real behaviour and replace opinion with evidence. No rigged demos, no invented win rates, just a fair question and a readable answer.
Interactive demo · Experiment Flight Deck
Watch an experiment earn its answer
Choose the question first. The traffic, counters and readout stay quiet until you press Play demo, exactly how a careful test should begin.
1 · Choose the experiment question
If the main action is impossible to miss, more visitors will add the bottle to their bag.
Consider shipping only if the variant improves add-to-bag rate without hurting checkout starts.
Ready when you are. Press Play demo to send the first visitors through.
00:00Waiting to start.
The gap appears only after visitors arrive.
A result is read after the agreed sample and guardrails are checked.
Run log
- SetupBrief agreed, split set to 50 / 50, traffic still at zero.
Illustrative demo with fixed, made-up data. A real experiment is sized for your traffic, measured with validated events and read honestly, including when the variant does not win.
Why it matters
Most website arguments are untestable opinions
The redesign debate, the hero banner debate, the button colour debate. Experiments settle them with visitor behaviour instead of seniority.
Two experienced people can look at the same page and disagree completely about what visitors want. That disagreement is fine. Acting on it without evidence is the expensive part.
A/B testing turns the disagreement into a question with a defined metric: if we show half the visitors a different experience, does behaviour change enough to matter? The process forces clarity before launch, because you cannot interpret a result you did not plan for.
And results are read carefully: a variant with a higher number in an underpowered test has not proven anything. Sample size, segmentation and novelty effects are discussed before conclusions are drawn.
What you get
What an experimentation engagement produces
Everything needed to run a defensible test: hypothesis, design, measurement and decision framework.
- 01
Test backlog
Prioritised hypotheses drawn from audit findings, analytics and customer questions.
- 02
Experiment design
Metric, hypothesis, variants, audience split and success criteria in one document.
- 03
Implementation QA
Checks that the variant renders correctly, events fire once and splits are random.
- 04
Monitoring
Guardrail metrics watched during the run so tests do not quietly break something else.
- 05
Read-out
What was tested, what the data supports, what it does not and what to do next.
- 06
Rollout plan
If a variant earns confidence: how to ship it, how to keep measuring afterwards.
Framework
Anatomy of a useful hypothesis
Three illustrative examples of the format. Real hypotheses are written against your own findings.
H1 · Hierarchy
Because visitors cannot find the primary action, promoting the main CTA above supporting content will increase checkout starts, measured as begin_checkout sessions per product view.
H2 · Reassurance
Because delivery cost appears too late, showing delivery timing and returns policy before the add-to-cart action will reduce abandonment on product pages, measured as add-to-cart rate.
H3 · Forms
Because the enquiry form asks for unnecessary detail, removing two optional fields will increase completed submissions, measured as form completions per form view.
Implementation approach
The experiment lifecycle
- STEP 01
Question
Agree what decision the experiment will inform. If there is no decision attached, there is no test to run.
- STEP 02
Design
Write the hypothesis, choose the primary metric, set guardrails and size the sample against your traffic.
- STEP 03
Build and validate
Implement variants, verify rendering, confirm events fire correctly and check the traffic split behaves.
- STEP 04
Run
Let the test reach its planned sample while watching guardrail metrics. No peeking-driven early stops.
- STEP 05
Decide
Read the result against the original decision: ship, iterate or discard. The read-out documents the reasoning either way.
Scope
What experimentation includes (and what it does not)
- Includes test strategy, experiment design, measurement validation and read-outs.
- Includes working inside your existing testing platform, or setting one up if required.
- Design and development of variant pages are scoped separately unless agreed otherwise.
- We do not publish guaranteed win rates: no honest provider can promise what your visitors will do.
- Illustrative metrics on this website are demo data, never CROLANE experiment results.
Traffic too thin for a reliable split test? The scope will say so and recommend a different method instead of selling you a test that cannot answer the question.
How do you decide what to test first?
By how much the change could matter, how likely it is to change behaviour, and how cheap it is to ship. We write the hypothesis, the metric and the decision rule before anything is built.
How long does an experiment need to run?
It depends on traffic and on how big a difference you want to detect. Rather than a fixed number of days, we size the test for your traffic volume so the read out is not a coin flip. If traffic is too low for a clean A/B test, we will say so and suggest alternatives.
What if the variant loses?
A loss is still a result: it tells you what your visitors responded to and prevents a change that would have wasted engineering time. Read-outs report both outcomes honestly.
Do you handle the tool setup as well?
If testing is not yet in place, the experiment setup and event validation can be part of the scope. If you already have a platform, we work inside it and document the configuration.
Start with a/b testing & experimentation
Tell us where the journey loses people.
Send a short note about the business problem behind this service. We will reply with honest thoughts on fit, scope and what starting would involve.