The CRO ProcessResearch, rank, test, learn

Why most CRO programmes stall#

Conversion programmes rarely die from failed tests. They die from running out of good ideas. Teams start with a backlog of obvious fixes, test them, and then drift into testing whatever someone saw on another site. Win rates fall, stakeholders lose interest and the programme quietly stops.

The cure is a process in which research, not opinion, feeds the backlog. When every hypothesis traces back to an observed visitor problem, the supply of ideas renews itself, and even losing tests teach something about customers.

A test without a hypothesis is a coin toss with a dashboard.

The loop in five stages#

Stage 1: Research from two directions#

Start with numbers to find where the problem is. Map the main conversion paths in analytics and look at drop-off by step, device, traffic source and new versus returning visitors. Pages with high traffic and high exit at a decisive step are your candidates. Funnel analysis gives the method.

Then use qualitative methods to find why. On-page surveys asking 'what nearly stopped you?', customer interviews, usability tests with five or so representative users, support tickets, sales-call notes and session recordings. Look for patterns that recur across sources. A complaint that appears in support tickets and in recordings is worth more than one that appears in a single survey.

Stage 2: Write hypotheses that can fail#

A useful hypothesis has three parts: the evidence, the change and the expected effect. 'Because recordings show mobile visitors scrolling past the delivery information and surveys mention surprise shipping costs, showing delivery cost on the product page will increase checkout starts among mobile visitors.'

This format forces discipline. If you cannot write the 'because' clause, you have an opinion, not a hypothesis. If you cannot name the metric, you cannot judge the result. And because the hypothesis names a customer problem, a losing test still tells you something: perhaps shipping cost was not the barrier after all.

Stage 3: Prioritise honestly#

Scoring frameworks such as PIE and ICE exist to stop the loudest voice choosing the next test. Their exact formulas matter less than using one consistently. Whatever you use, weight evidence heavily. An idea supported by three independent research sources should beat a clever idea supported by none.

Stage 4: Test, ship or simply fix#

Not every item needs an experiment. Sort the prioritised list into three bins. Fix: clear defects such as broken fields, missing information, slow pages. Test: changes with uncertain outcomes on pages with enough traffic. Ship and monitor: changes you are confident in, on pages without enough traffic to test, compared before and after with care.

Your testing capacity is finite and worth calculating. Each A/B test needs a minimum sample per variant, which depends on your baseline rate and the smallest effect you care about. Divide the traffic available by that requirement and you know how many tests a page can carry per month. Many teams discover they can run far fewer tests than they planned, which is precisely why prioritisation matters.

Stage 5: Learn and record#

The most neglected asset in CRO is the test log. Record every hypothesis, the evidence behind it, screenshots of variants, dates, sample sizes, results and, above all, the interpretation. Over a year this becomes a map of what your customers respond to, and it prevents the familiar waste of re-running a test someone ran two years ago.

Share results in plain language with the wider business. A finding such as 'visitors need to see delivery cost before they commit' is useful to merchandising, customer service and paid media, not only to the web team.

One loop, worked through#

Illustration, not a case study. A services firm notices in analytics that its contact page has healthy traffic but a weak completion rate on mobile. That is the 'where'. Session recordings show visitors scrolling up and down the form repeatedly; a one-question survey on the page reveals that people are unsure what happens after they submit and whether they will be called immediately.

The hypothesis follows: because visitors are uncertain about next steps, adding a short 'what happens next' panel beside the form and letting them choose a preferred contact method will increase completed enquiries on mobile, without reducing lead quality. It scores well on evidence (two sources), reach (all mobile contact traffic) and effort (a small build).

Traffic is modest, so the team checks capacity and finds that a test would take several weeks. They run it anyway because the page is commercially important. Whatever the outcome, the learning is recorded: either uncertainty about next steps was a real barrier, or it was not, and the next research round should look elsewhere, perhaps at the number of fields or the form design itself.

Process failures to watch for#

• Research once, test forever. Customer concerns change with seasons, pricing and competition. Refresh research at least quarterly.
• Testing on low-intent pages. It is easier to get tests approved on blog pages, but the commercial effect is usually larger on product, pricing and checkout steps.
• Calling winners on clicks. A variant that raises clicks on a button but not completed actions has moved the problem one step down the funnel.
• No one owns implementation. Winning variants left running inside a testing tool for months add fragility and slow pages. Build winners properly into the site.

Cadence and governance#

A workable rhythm is a short weekly stand-up on running tests, a fortnightly or monthly prioritisation session, and a quarterly research refresh. Make one person accountable for the backlog and protect developer time. CRO that depends on borrowing engineering hours between other projects tends to run one test a quarter.

Published by Fabulous.Media, a network of specialist marketing agencies. Updated 9 October 2026. Platform features change often; check current official documentation before acting on platform-specific detail.