Conversion Rate Optimisation (CRO): A Practical Guide

Conversion rate optimisation (CRO) is the systematic practice of increasing the share of visitors who take a valuable action on your website, by finding out why they don't and fixing it. That is the whole idea. Everything else in this guide is method: how to find the real reasons, how to decide what to fix first, how to know whether a change worked, and how to keep doing it without fooling yourself.

This is a general guide. The principles apply to an online shop and to a B2B software company alike, but we spend extra time on the situation most guides skip: sites with modest traffic, long sales cycles and conversions of very unequal value. Whether you spell it conversion rate optimisation or conversion rate optimization, the discipline is the same.

What Conversion Rate Optimisation Actually Is

A conversion is any action you want a visitor to take: a purchase, a demo request, a trial sign-up, a newsletter subscription. The conversion rate is the share of visitors (or sessions) that complete it:

Conversion rate = conversions / visitors × 100

Example: a landing page receives 18,400 sessions in a month and produces 460 sign-ups. 460 / 18,400 = 0.025, so the conversion rate is 2.5%. If a change lifts that to 3.0% on the same traffic, you get 552 sign-ups: 92 more per month without buying a single extra click. That is a 20% relative lift, or a 0.5 percentage-point absolute lift. Always say which one you mean; mixing them up is the most common reporting error in CRO. You can run your own numbers in the conversion rate calculator.

Two decisions hide inside that formula. First, the denominator: sessions inflate the base for sites with lots of returning visitors, users understate it if your tracking cannot de-duplicate across devices. Pick one and keep it. Second, the numerator: which conversion counts.

Macro and micro conversions

• Macro conversions are the actions the business exists for: an order, a demo request, a paid plan.
• Micro conversions are steps that lead there: adding to basket, starting a form, viewing pricing, watching a product video, clicking a CTA.

Micro conversions matter for two reasons. They locate the leak (visitors view pricing but never click "Get started"), and they occur far more often than macro conversions, which makes them testable on sites where the macro conversion is too rare to measure. More on that in the low-traffic section.

What CRO is not

• It is not button-colour testing. Cosmetic tests rarely move anything because they don't address why people hesitate. Good CRO changes what the visitor understands, believes or has to do.
• It is not only A/B testing. Testing is the validation step. Most of the value comes from research that tells you what to change. Many improvements (a broken form on Safari, a missing price) should simply be fixed, not tested.
• It is not a bag of best practices. "Add urgency" or "shorten the form" may help or hurt depending on your audience. A practice is a hypothesis until your own data supports it.
• It is not traffic acquisition. CRO works on what happens after the visit starts. It makes every acquisition channel more efficient, but it does not replace one.

The CRO Process, Step by Step

Every credible CRO programme runs some version of the same loop. The names vary; the order does not.

1. Research: find where and why visitors fail to convert.
2. Hypotheses: turn each finding into a testable statement.
3. Prioritisation: rank hypotheses so scarce traffic and dev time go to the best bets.
4. Testing: run a controlled experiment (or, where that is impossible, the next-best method).
5. Analysis: read the result honestly, including segments and guardrails.
6. Roll-out and learning: ship winners, record every result, feed learnings back into research.

1. Research: where and why

Research has two halves. Quantitative data tells you where the problem is. Qualitative data tells you why. You need both: a funnel report shows that 70% of visitors abandon the pricing page, but it cannot tell you they left because the enterprise tier says "Contact us" with no price range.

Start with analytics to pick the two or three pages that matter most (high traffic, close to revenue, steep drop-off), then spend the qualitative effort only there. A research sprint of two to three weeks typically yields more test ideas than you can run in six months.

Before you trust any of it, check the plumbing. Confirm that conversion events fire once per conversion, that the funnel steps are tracked on every device, and that internal traffic is filtered. A surprising share of "conversion problems" turn out to be measurement problems.

2. Hypotheses: make each idea falsifiable

A hypothesis links an observation to a change and a measurable outcome. Use this template:

"Because we observed [X], we believe changing [Y] for [Z audience] will cause [W], measured by [M]."

Example: "Because we observed in session recordings and an exit survey that mobile visitors on the pricing page can't tell which plan includes SSO, we believe adding a feature comparison toggle above the plan cards for mobile visitors will cause more plan selections, measured by clicks on any 'Choose plan' button per pricing-page visitor."

The template does three jobs. It forces evidence (no "because the CEO likes it"). It names the audience, so you test where the problem lives. And it fixes the primary metric before the test starts, which prevents choosing a flattering metric afterwards. A copyable version lives in our A/B test plan template.

3. Prioritisation: PIE, ICE or PXL

You will always have more ideas than capacity. Three scoring frameworks dominate:

• PIE (Potential, Importance, Ease), popularised by WiderFunnel: score each 1-10 and average. "Importance" is about how valuable the page's traffic is.
• ICE (Impact, Confidence, Ease), from growth marketing: score each 1-10 and average. "Confidence" is how strong your evidence is.
• PXL, from CXL: a checklist of mostly yes/no questions with fixed points, such as whether the change is above the fold, whether it is noticeable within five seconds, whether it adds or removes an element, whether it runs on a high-traffic page, and whether it addresses a problem found in user testing, qualitative feedback or analytics. Ease is scored by estimated effort. CXL designed it to remove the guesswork PIE and ICE leave in "impact".

Example (illustrative scores for one backlog, PXL simplified to seven questions):

All three frameworks agree that A goes first and D goes last. They disagree about C: PIE rates it close to B's league because "potential" is generous, while ICE and PXL punish the lack of evidence. That disagreement is the point of choosing a framework deliberately.

Our view: use ICE for a small team that needs to rank 20 ideas in an afternoon. Switch to PXL once more than one person scores ideas, because yes/no questions produce consistent scores across people and stop the loudest voice inflating "impact". PIE is useful when you are deciding which page to work on, less so for individual ideas. Whatever you pick, weight evidence heavily: the main predictor of a winning test is a hypothesis grounded in research.

4. Testing

Build the variant, QA it on every major browser and device, and run a controlled experiment where traffic allows (see the statistics section below). Write down, before launch: the primary metric, guardrail metrics, the sample size, the planned duration and the stopping rule. If you can't fill those five in, you are not ready to launch.

5. Analysis

When the planned sample is reached, check data quality first (sample ratio, tracking), then the primary metric, then guardrails, then pre-registered segments such as device or new versus returning. Treat segment findings you did not plan for as new hypotheses, not conclusions: slice any test enough ways and something will look significant by chance.

6. Roll-out and learning

Ship winners properly (in the codebase, not left running at 100% inside the testing tool for months). Record every test in a log: hypothesis, screenshots, numbers, decision, and what it taught you about your visitors. A losing test that disproves a widely held belief is often worth more than a small win, but only if someone writes it down.

Testing Statistics, Done Right

You don't need to be a statistician to run valid tests, but you do need to respect five ideas. The best single reference is Kohavi, Tang and Xu, Trustworthy Online Controlled Experiments (2020).

Sample size: decide it before you start

The number of visitors you need depends on your baseline conversion rate, the smallest effect you care to detect (the minimum detectable effect, MDE), your significance level (alpha) and your statistical power. For a two-sided test comparing two proportions:

n per variant = [ z_1-α/2 × √(2 p̄(1-p̄)) + z_1-β × √(p₁(1-p₁) + p₂(1-p₂)) ]² / (p₂ - p₁)²

Worked example: baseline p₁ = 3%, MDE = 20% relative, so p₂ = 3.6%. Alpha = 0.05 (two-sided), so z = 1.96. Power = 0.8, so z ≈ 0.8416. The pooled rate p̄ = 3.3%.

1. First term: 1.96 × √(2 × 0.033 × 0.967) = 1.96 × √0.06382 = 1.96 × 0.2526 = 0.4951
2. Second term: 0.8416 × √(0.03 × 0.97 + 0.036 × 0.964) = 0.8416 × √(0.02910 + 0.03470) = 0.8416 × 0.2526 = 0.2126
3. Numerator: (0.4951 + 0.2126)² = 0.7077² = 0.5009
4. Denominator: (0.036 - 0.03)² = 0.006² = 0.000036
5. n = 0.5009 / 0.000036 ≈ 13,900 visitors per variant, about 27,800 in total.

That matches what Evan Miller's sample size calculator returns for the same inputs, and you can check your own scenario in our A/B test calculator. Note how brutal the maths is: halve the MDE to 10% and you need roughly four times the traffic. Our post on A/B test sample size has lookup tables for common baselines.

Duration: sample size divided by traffic, in full weeks

Test duration = total sample needed / weekly eligible visitors, rounded up to whole weeks.

Example: the page above gets 7,000 eligible visitors a week. 27,800 / 7,000 = 3.97, so run it for 4 full weeks. Full weeks matter because weekday and weekend visitors behave differently; stopping on a Wednesday over-represents part of the week. As a rule of thumb, run at least one full business cycle and avoid tests longer than six to eight weeks, after which cookie deletion and seasonal changes start to pollute the sample.

Don't peek (or use a method designed for it)

Checking a standard fixed-horizon test daily and stopping the moment it hits p < 0.05 dramatically inflates false positives, as Evan Miller shows in How Not To Run an A/B Test. Either commit to the planned sample size and only read the result at the end, or use a tool whose statistics are built for continuous monitoring (sequential testing). Looking at a dashboard is fine; acting on it early is the problem.

Check for sample ratio mismatch

If you split traffic 50/50 and get 10,000 visitors in control and 9,400 in the variant, something is broken: a redirect losing users, a bot filter hitting one arm, a variant that crashes on some browsers. A chi-square test on the visitor counts flags this. Kohavi and colleagues treat sample ratio mismatch as one of the most important trust checks; when it fails, don't interpret the result, find the bug.

Novelty effects, one primary metric, and guardrails

• Novelty and primacy effects: returning visitors may click a new element because it is new, or ignore it because they are used to the old layout. Compare week one with later weeks; if the effect fades, be sceptical.
• One primary metric: declared up front, ideally the closest metric to revenue you can measure with enough volume. Ten "primary" metrics guarantee a false winner somewhere.
• Guardrail metrics: things that must not get worse, such as revenue per visitor, lead quality, refund rate, page load time. A variant that lifts sign-ups by 10% while cutting average order value by 15% is not a winner.

And test one coherent change per variant unless you have a lot of traffic. Our comparison of A/B testing vs multivariate testing explains when the multivariate route is worth its traffic cost (rarely, below six figures of monthly visitors).

CRO for Low-Traffic and B2B Websites

Most CRO advice was written by people optimising high-volume consumer sites. B2B sites, and small consumer sites, face three structural problems:

1. Low traffic. The worked example above needs about 27,800 visitors for one test. A page with 5,000 visitors a month would take five to six months, by which time the market, the ads and the page itself have changed.
2. Long sales cycles. A test can count form fills in weeks, but whether those leads became pipeline takes months. The variant that wins on demo requests in February can lose on revenue by June if it attracted poor-fit companies.
3. Unequal conversion value. One demo request may come from a company that could become your largest customer; another from a student. Conversion rate treats them as equal, and revenue-weighted metrics are much noisier, so they need even more data.

None of this means "don't do CRO". It means changing the method.

What to test first

When you can run only a handful of tests a year, run the ones with large expected effects on pages close to revenue. A sensible order:

1. Headlines and value proposition on your highest-traffic commercial pages: outcome-led versus feature-led, audience-specific versus generic, problem-led versus solution-led.
2. The offer and CTA: not the button text alone, but what you offer (demo, product tour, assessment, pricing call) and where it appears.
3. Forms: fields, qualifying questions, single versus multi-step. Measure lead quality, not just completion.
4. Layout and page structure last: most expensive to build, smallest and slowest to measure on average.

Make bigger swings

Required sample size scales with the inverse square of the effect. Detecting a 40% lift needs roughly a quarter of the traffic of a 20% lift. Small tweaks are untestable on low traffic; bold, research-backed changes (a completely different headline argument, a different offer) are. They also teach you more about your buyers, whereas small tweaks only teach you about the page.

Test upstream micro conversions

If demo requests are too rare, choose a primary metric higher up the funnel that is plausibly connected to them: clicks to the demo page, form starts, pricing-page visits from the homepage. A metric that occurs ten times as often makes tests roughly ten times faster to power. The trade-off is that you must still watch the macro conversion as a guardrail, because a micro conversion can rise while real conversions stay flat.

Accept decision-appropriate confidence

Not every decision needs 95% confidence. For easily reversible copy changes, a lower threshold (or a Bayesian "probability to be best" read) is a reasonable trade between speed and certainty. For structural changes that are expensive to undo, such as a pricing page redesign, hold out for strong evidence. Decide the threshold before the test, not after you see the numbers.

Sequential and before/after tests, with caveats

When a split test is impossible (target-account experiences with a few dozen visits, a site-wide navigation change), a before/after comparison is better than nothing, but be honest about its weakness: seasonality, campaigns, sales activity and market news all change at the same time as your page. Reduce the risk by comparing equal periods, checking a control metric that your change shouldn't affect (if it moved too, the shift is probably external), and repeating the switch (on, off, on) where you can.

Lean on qualitative research

With low traffic, five customer interviews and twenty sales-call recordings are worth more than an underpowered test. Use qualitative work to make changes you are fairly sure about, and save testing for the genuinely uncertain, high-stakes decisions.

Measure pipeline, not form fills

Example: variant A produces 20 leads of which 25% become opportunities (5 opportunities). Variant B produces 30 leads of which 10% become opportunities (3). B "won" on conversion rate and lost on the metric that matters. Connect your testing tool or analytics to the CRM so each lead carries its variant, and revisit results when opportunity data matures. Also check segment results: a flat aggregate can hide a winner for enterprise visitors and a loser for small companies cancelling each other out. For B2B-specific CRO tactics such as qualifying forms, enterprise social proof and buying-committee content, see our deeper guide to B2B conversion rate optimisation.

Running a CRO Audit

A CRO audit is the research step compressed into a one-off review, useful when you inherit a site or need a prioritised plan fast. The short version:

1. Check measurement: conversion events, funnel steps, cross-domain tracking, filtered internal traffic.
2. Map the funnel by device and channel, and find the two steps with the largest absolute loss.
3. Review those pages heuristically: clarity of the offer in five seconds, relevance to the traffic source, friction (fields, steps, load time), anxiety (trust, price, privacy) and distraction.
4. Gather qualitative evidence on the same pages: recordings, a short survey, a few user tests.
5. Log findings as either "just fix" (bugs, broken flows), "investigate" or "test", each with a hypothesis and a priority score.

Our CRO audit checklist lists every check, and the CRO audit walkthrough shows how to turn findings into a roadmap.

Where to Focus, by Page Type

Two external benchmarks are worth knowing. Baymard Institute, averaging 50 studies, puts documented online cart abandonment at about 70%; among shoppers who abandoned for reasons other than "just browsing", extra costs (40%) and forced account creation (18%) rank high, and Baymard estimates an ideal checkout needs only 7-8 form fields against a US average of about 15. For forms in general, the Nielsen Norman Group's form usability recommendations (keep forms short, single column, explain requirements up front, specific error messages) are a solid checklist. B2B forms are a partial exception to "shorter is always better", because qualifying fields protect sales time; our guide to lead capture form design covers how to match form length to intent, and B2B landing page optimisation goes deeper on campaign pages.

Personalisation as a CRO Lever

A classic A/B test asks "which version is best for everyone?" Sometimes the honest answer is "neither": an enterprise buyer and a five-person startup want different proof, different language and a different next step, and the average result hides that. Personalisation means serving different experiences to defined segments, then measuring each against a control for that segment.

It beats one-size testing when three conditions hold: your audience splits into segments with genuinely different needs (by industry, company size, funnel stage or traffic source), you can reliably recognise those segments on arrival, and you have content that actually differs for each. If any of those is missing, personalisation adds complexity without lift. It also divides your traffic, so it is no shortcut around the sample size maths; start with one or two large segments and one page. If you want to structure the segments first, the segmentation strategy guide walks through it, and our segmentation features show how Markettailor serves segment-specific variants with a holdout control.

Common CRO Mistakes (and Fixes)

1. Testing without research. Ideas from brainstorms win less often than ideas from evidence. Fix: every test cites the observation behind it.
2. Stopping tests early. Early leads are mostly noise and peeking inflates false positives. Fix: fix sample size and duration in advance.
3. Underpowered tests. A test that can only detect a 50% lift will call most real improvements "no difference". Fix: calculate the MDE you can detect before launching and only run tests that can plausibly reach it.
4. Optimising the wrong metric. More leads, worse pipeline. Fix: primary metric as close to revenue as volume allows, plus quality guardrails.
5. Calling losses failures. Teams quietly drop losing tests and lose the learning. Fix: log every result and what it disproved.
6. Ignoring segments, or over-reading them. Both happen. Fix: pre-register two or three segments (device, new versus returning, company size) and treat the rest as hypotheses.
7. Copying competitors or "best practice" lists. You see their page, not their results. Fix: use them as hypothesis sources, never as answers.
8. Skipping QA. A variant that breaks on one browser produces a false loser and a sample ratio mismatch. Fix: test every variant on major browsers and devices before launch.
9. Treating CRO as a project. One audit, five fixes, done. Fix: a standing cadence with an owner, a backlog and a log.
10. Not fixing obvious bugs because "we should test it". Fix: broken things get fixed; uncertain things get tested.

CRO Tools by Job

Choose tools by the job they do, and buy the testing tool last: most teams need better research before they need more testing capacity.

• Analytics: funnels, segments and events. Google Analytics 4, Adobe Analytics, or product analytics such as Mixpanel and Amplitude.
• Behaviour analysis: heatmaps and session recordings. Microsoft Clarity, Hotjar, Contentsquare.
• Testing and personalisation: client-side or server-side experimentation. Optimizely, VWO, AB Tasty, or feature-flag platforms for server-side tests.
• Surveys and user research: on-page polls and moderated or unmoderated user tests. Hotjar surveys, Typeform, UserTesting, Maze.

For a fuller comparison by traffic level and budget, see our roundup of conversion rate optimisation tools.

Building a CRO Programme

CRO compounds only when it runs as a programme rather than a series of one-off fixes. The minimum structure:

• An owner with time ring-fenced for it, plus access to design and development capacity. Without dev time, the backlog becomes a wish list.
• A cadence: a research sprint each quarter, a fortnightly prioritisation review, and a monthly readout of results to stakeholders.
• A test log that anyone can search: hypothesis, audience, screenshots, sample, result, decision, learning. After a year it is the most valuable CRO asset you own.
• A realistic throughput target. A high-traffic consumer site can run several tests a month in parallel on different pages. A B2B site with 10,000 monthly visitors may manage one or two a month, combined with research-driven fixes.

Set expectations about win rates up front. In Online Experimentation at Microsoft (Kohavi et al., 2009), the authors report that only about one-third of ideas improved the metrics they were designed to improve, with roughly a third flat and a third negative. Microsoft's ideas were not bad; good ideas are simply hard to predict. If your programme "wins" 80% of its tests, the likelier explanation is lax statistics, not exceptional ideas. Judge a CRO programme by validated cumulative impact and by the quality of what it has learned, not by its win rate.

Frequently Asked Questions

What is a good conversion rate?

There is no universal good number, because conversion rate depends on what you count, your traffic mix, price point and buying cycle. A free newsletter sign-up and a six-figure enterprise demo request cannot share a benchmark. The useful comparison is against your own baseline for the same page, traffic source and device. Aim to improve that steadily, and judge success by revenue or pipeline per visitor rather than the rate alone.

How long should an A/B test run?

Run it until it reaches the sample size you calculated before launch, rounded up to full weeks so every weekday is represented equally. Divide the total visitors needed by your weekly eligible traffic. For most sites that means two to six weeks. If the maths says several months, test a bigger change or a higher-volume metric instead of running an endless test.

What is the difference between CRO and SEO?

SEO increases how many qualified visitors reach your site from organic search. CRO increases the share of those visitors, from any channel, who take a valuable action. They support each other: pages that answer the searcher's intent clearly tend to both rank and convert better. Conflicts are rare, but avoid CRO changes that hide or strip out content search engines and visitors need.

Is CRO worth it for low-traffic sites?

Yes, but the method changes. With limited traffic, lean on qualitative research such as customer interviews, session recordings and user tests, fix obvious problems directly, and reserve A/B tests for bold, high-stakes changes measured on frequent upstream metrics. Even with no testing at all, a research-driven audit of your two or three most important pages usually finds friction worth fixing.

What does a CRO specialist do?

A CRO specialist runs the optimisation loop: analysing funnels, conducting user research, writing hypotheses, prioritising and designing experiments, checking their statistical validity and turning results into recommendations. The role blends analytics, UX research, copywriting judgement and enough statistics to avoid false winners. If you are considering the career, our overview of conversion rate optimisation jobs covers roles, skills and how to get started.