Everything that makes a testing program actually work: how to diagnose your funnel, what research to run before you touch anything, how to form hypotheses that are worth testing, how to run experiments without fooling yourself, and how to measure results that hold up. No opinion as a substitute for data. No guesses dressed up as strategy.
CRO is probably the most misrepresented discipline in digital marketing. It gets sold as button colour tests and "best practice" checklists, and it gets bought by teams that want a quick win without the work. What it actually is: a structured process of understanding why users behave the way they do, forming testable bets about what would change that behaviour, running those bets in a way that produces reliable evidence, and then compounding the winners month after month. That process is not quick, but the returns on doing it well dwarf nearly any other use of your marketing budget.
Conversion rate optimization is the practice of increasing the percentage of visitors who take a defined action: signing up, purchasing, starting a trial, booking a demo. It operates on traffic you already have, which makes it fundamentally different from acquisition: you are not paying for more visitors, you are getting more value from the visitors you already pay for.
What CRO is not: changing a button from green to orange and calling it a test. Running a headline variant for four days and declaring a winner. Implementing "best practices" from another company's case study without verifying they apply to your context. These are all extremely common, and they all produce noise that gets mistaken for learning.
Real CRO is a research discipline. It starts with a question: why are users behaving this way? It answers that question with data before proposing any change. And it validates every proposed change in a controlled experiment before shipping it to everyone. The research phase is not optional overhead. It is the thing that makes the experiments worth running.
The core principle. Every change to a live product is a claim: "this will work better than what we have." CRO is the discipline of deciding which claims are worth testing, designing tests that can actually tell you if the claim is true, and acting on what the data says rather than what you hoped it would say.
The right starting point for any CRO engagement is an audit that answers one specific question: where is conversion leaking right now, and what is each leak worth in revenue per month? Everything else flows from that.
The audit covers four layers, and the output of all four is the same: a prioritised list of conversion problems, each one with a revenue cost attached and a hypothesis about what would fix it.
Every item in the audit output has the data behind it and the revenue estimate attached. "Checkout step 2 is losing 68 percent of users who reached step 1, which at your current traffic and average order value costs approximately 38 conversions per month at current rates." That level of specificity is what makes it possible to decide which leaks to fix first and what a fix is worth investing in.
Quantitative research tells you what is happening and how much it matters. It cannot tell you why, but it can tell you exactly where to look.
A conversion funnel is the sequence of steps between a user's arrival and the completion of your goal. In analytics, you set up this sequence as a defined path and measure how many users progress from each step to the next. The drop-off rates at each transition are your starting material: the bigger the drop and the more traffic that hits that step, the more valuable a fix is worth.
Most teams look at funnel drop-offs in aggregate. That is a start, but it hides enormous signal. The next step is segmentation: breaking down the funnel by traffic source, device type, user cohort, geography, and behaviour. A checkout funnel that converts at 40 percent on desktop and 18 percent on mobile is not one problem, it is two different problems, and solving the mobile version alone might be a larger revenue gain than any desktop optimisation.
Cohort analysis groups users by a shared characteristic at the time of their first visit: the week they arrived, the campaign that brought them, the first feature they used. Comparing cohort conversion rates over time tells you whether a change you made actually improved things, or whether a shift in traffic mix made it look that way.
Behavioural segmentation goes further. Users who read more than three pages convert at a different rate than users who bounce after one. Users who use the search bar convert differently from users who navigate by category. These segments exist in your analytics data, and identifying the highest-converting segment is often the fastest way to find what to test: build more of the experience that the converting segment gets.
| Research layer | Key tool | What it answers |
|---|---|---|
| Funnel drop-off | GA4 or Mixpanel funnels | Where do users stop progressing, and how often? |
| Segment comparison | Custom dimensions, cohort explorer | Which users convert and what makes them different? |
| Page-level engagement | Scroll depth, time on page, events | Are users engaging with the content near conversion CTAs? |
| Revenue impact | Revenue per session, ARPU by funnel stage | What is each percentage point of conversion lift worth? |
| Error and rage-click data | Error logging, Hotjar rage click reports | Where are users experiencing friction or frustration? |
Quantitative data tells you where the problem is. Qualitative data tells you why it exists. Both are necessary. Running experiments without qualitative research means you are guessing at the cause of the problem, which means your hypotheses are guesses too.
Session recordings capture individual user journeys through your site. Watching a sample of sessions on a high-drop-off page is one of the highest-value hours you can spend in CRO. You see exactly where users pause, what they re-read, what they try to click that is not clickable, and where they leave. Patterns that appear across multiple recordings are your strongest signal: if thirty out of fifty users you watch all pause at the same point in a form and then close the tab, you have a specific, testable hypothesis.
Heatmaps aggregate mouse movement, scroll behaviour, and click data across hundreds or thousands of sessions and show you a visual distribution. Scroll heatmaps show how far down a page most users actually read before leaving. Click maps show which elements attract attention and which are ignored. A CTA buried below the point at which 70 percent of users have already left the page is a finding that requires no further explanation: it needs to move up.
A single, well-placed survey question can surface the dominant objection holding back conversion. On a pricing page: "What, if anything, is stopping you from signing up today?" On a checkout abandonment page: "We noticed you did not complete your order. Is there anything we can help with?" The responses are often blunt and specific in a way that no quantitative data can match. You learn whether users have a pricing objection, a trust concern, a missing feature, or a plain usability problem, and you learn it in their own words, which is also the language your next test's copy should speak.
Moderated or unmoderated user testing sessions put real people through your flow and capture what they say and do while they try to complete a task. Five sessions with people who match your actual buyer profile will surface more actionable friction than a month of analytics analysis, because users say aloud what they are confused about, what they expected to find that was not there, and what made them hesitate. Remote unmoderated testing tools make this practical and affordable even at early stages.
A hypothesis is not a change. It is a prediction: if we change X, then Y will happen, because Z is the reason users are behaving the way they currently behave. The "because Z" part is the most important element, and it is the part most testing programs skip.
A weak hypothesis: "Changing the CTA button from grey to blue will increase clicks."
A strong hypothesis: "Users are not clicking the primary CTA because it does not stand out against the page background. Session recordings show eyes moving past it without fixating. Making it higher-contrast blue will increase its visual prominence and lift CTA click rate by at least 15 percent relative."
The difference is that the strong version is grounded in a specific observation, proposes a specific mechanism of change, and names a specific outcome with a specific magnitude. If the test does not lift CTA clicks by at least 15 percent, you have not just failed to find a winner, you have evidence that your diagnosis was wrong, which is just as valuable.
Good hypotheses come from the research: from the session recordings where you saw users miss the CTA, from the click maps showing low engagement with it, from the survey responses where users said they were not sure what to do next. When you have a strong evidence base for the hypothesis, the test result, whether positive or negative, teaches you something real about your users.
At any given time you will have more hypotheses than you have capacity to test. Prioritisation frameworks exist to order them by expected value, so you run the highest-leverage tests first rather than the easiest ones.
Two frameworks are widely used and both work. The choice between them is less important than the discipline of applying either one consistently.
| Framework | Dimensions scored (1 to 10) | Best for |
|---|---|---|
| ICE | Impact, Confidence, Ease | Teams that want a fast, opinionated score with minimal overhead |
| PIE | Potential, Importance, Ease | Teams that want to weight the traffic value of the page being tested |
Impact / Potential asks: if this test wins, how much will it move the needle? A test on your highest-traffic landing page has more impact potential than the same test on a low-traffic page, even if the expected lift is the same.
Confidence asks: how strong is the evidence base for this hypothesis? A hypothesis grounded in three independent qualitative signals (session replay, survey, user test) has higher confidence than one that came from a hunch.
Ease asks: how much effort does this test require to design and implement? A copy change requires a few hours. A checkout flow restructure might require two engineering sprints. High ease should not override low impact, but when impact and confidence are equal, ease is a reasonable tiebreaker.
Score each hypothesis on all three dimensions, average the scores, and sort by the result. Run the tests in order, and update the scores as you learn. A test that wins changes the confidence score for related hypotheses. A test that loses should prompt you to revisit the evidence base.
The discipline. Prioritisation only works if you commit to the order before you know the results. Teams that skip low-scoring tests because "we already know it will not work" or bump high-scoring tests because they are "too risky" are substituting opinion for process. Use the framework, run the tests, and update based on what you learn.
An experiment has four components: a control (what currently exists), one or more variants (what you are testing), a success metric (the number that defines a winner), and a stopping rule (when you will stop and call a result). All four must be defined before the test launches. Deciding any of them after you have started looking at results is how you fool yourself into shipping a loser.
A/B testing (also called split testing) sends half your traffic to the control and half to the variant. It is the right choice for most tests: simple to implement, simple to analyse, simple to explain. Multivariate testing tests multiple changes simultaneously and requires far more traffic to reach significance for each combination. It is almost never the right choice for teams below a certain traffic threshold, and most teams are below that threshold.
The most common mistake in A/B testing is stopping a test too early. To size a test correctly, you need three inputs before it launches: your baseline conversion rate (what the control currently converts at), the minimum detectable effect (the smallest lift that would be worth shipping), and the statistical power you want (typically 80 percent, meaning an 80 percent chance of detecting the effect if it exists at 95 percent confidence).
With those three inputs, a sample size calculator gives you the number of visitors per variant you need before you can call a result. That number is often larger than teams expect. A page converting at 2 percent, testing for a 20 percent relative lift, needs roughly 5,000 to 7,000 visitors per variant. At 2,000 visitors per day split evenly, that is a three to four week test. Calling a result at day five is not an early result, it is a false one.
Set the required sample size before the test launches, hit it before looking at results, and call the test only when both the sample size and the statistical significance threshold have been met. Not before.
Statistical significance is not optional and it is not a formality. It is the mechanism that separates a real result from random variation, and the reason it exists is that random variation looks like a real result with alarming frequency in small samples.
The standard threshold is p < 0.05: a less than 5 percent probability that the observed difference would appear by chance if there were no real effect. At 95 percent confidence, you are accepting a 5 percent chance of a false positive. That sounds small, but if you run twenty tests per year and call every one at p < 0.05, you can expect to ship one false winner from chance alone.
Peeking is checking the results before your target sample size is reached and making a decision based on what you see. It inflates your false positive rate significantly. A test that looks like a winner at day three with a small sample will revert to noise at day twenty with a proper sample roughly half the time. The fix is simple: calculate the required sample size before the test, commit to not looking until it is reached, and look exactly once.
A novelty effect occurs when a change performs well initially because it is new, then reverts once users adapt to it. Pages with high return-visitor traffic are especially vulnerable. If a test shows a large, fast lift that flattens quickly, run it for a second period before calling it. If the lift holds, it is real. If it does not, you caught a novelty effect before shipping it.
The more metrics you measure in a single test, the higher the probability that one of them will show a spurious result. Define one primary success metric before the test launches. Track secondary metrics for context, but make the go/no-go decision on the primary metric alone.
A landing page has one job: turn a visitor into the next step in your funnel. Every element on it should serve that job or be removed. The most common failure mode is pages that try to do too much: explain the full product, establish the company history, address every possible objection, and convert the visitor, all on one scroll.
The visitor arrived from somewhere. They clicked an ad with a specific promise, or a search result with a specific snippet, or a social post with a specific hook. The landing page headline should match that promise as closely as possible. Message mismatch is the single most common cause of high bounce rates on paid traffic: the ad said one thing, the page says something else, and the visitor concludes they are in the wrong place.
Most visitors decide within three seconds whether to stay. The hero section decides it. A strong hero has a headline that states a specific outcome the visitor wants (not a feature you offer), a subheadline that supports it with one clarifying detail, and a CTA that tells them exactly what happens next. The hero should be visible without scrolling on both desktop and mobile. If it requires scrolling to see the primary CTA, that is a test to run immediately.
Trust signals reduce the perceived risk of taking an action. They include testimonials from real people with specific outcomes attributed, logos of recognisable customers or partners, security badges near high-anxiety fields like payment inputs, and review counts with star ratings from external platforms. Their placement matters as much as their presence: a trust signal that appears below the fold after the visitor has already left does not help.
Forms are the conversion point for a large share of digital funnels, and they are also one of the highest-friction experiences in most products. The research consistently shows that reducing the number of required fields increases completion rate, but the effect size depends on which fields you remove, not just how many.
The question to ask about every field in a form is: do we actually need this information before we can deliver value to this user? If the answer is no, or if you can collect it later in the relationship, remove it or defer it. A company name field on a free trial signup form is almost never necessary at that stage. Removing it typically lifts completion without any downstream impact on qualification.
Form labels that are ambiguous ("Name" when you want first and last separately, or "Phone" when country code matters) create confusion that manifests as abandonment. Error messages that say "Invalid input" without explaining what was wrong create frustration that does the same. Session recordings will show you exactly where in a form users pause, backspace, or give up. Every pause is evidence of an ambiguity or friction point. Fix them specifically, then retest.
Multi-step forms with a visible progress indicator convert better than ones without, particularly on mobile where the full length of a form is hidden by the viewport. The indicator should show total steps and current position. It should not count up from zero: "Step 1 of 4" is better than "0% complete" because it anchors the user at the beginning rather than reminding them how far they have to go.
Checkout is the highest-stakes surface in e-commerce and the most studied. The average cart abandonment rate across industries runs between 65 and 75 percent. That is not a design problem unique to any one site, it is a category characteristic driven by the fact that most people who add to cart are not yet ready to buy. The CRO opportunity is recovering the fraction of those people who were close to ready but encountered friction.
The most common checkout friction points are: mandatory account creation before purchase, long forms that ask for information not yet needed, payment methods missing for the visitor's preference, security anxiety near the card input, unclear total cost at the point of entry, and slow or confusing address autocomplete. Each of these is testable and each has a documented impact on completion rates.
Guest checkout is a particularly consistent winner. Requiring account creation before allowing purchase reduces checkout completion by 15 to 35 percent in most studies. The account can be offered after the transaction is complete, at a moment when the user is already committed and has a reason to want it.
A pricing page is one of the most important pages in a SaaS funnel and one of the most neglected from a testing perspective. The most impactful variables are: the number of tiers shown (three is a strong default; more introduces choice paralysis), which tier is highlighted as recommended, how the value of each tier is expressed (outcomes, not features), whether an annual discount is surfaced prominently, and whether a free trial or freemium option removes the need to decide on price at all.
Pricing page tests often produce large effect sizes because the page sits at high intent. A visitor on your pricing page is evaluating a purchase decision, not browsing. Changes that help them make that decision confidently move conversion meaningfully.
The mobile conversion gap is one of the most persistent and underexploited opportunities in digital marketing. Most sites see mobile traffic at 55 to 70 percent of total visits, but mobile conversion rates that are 40 to 60 percent below desktop for the same funnel. The gap is not because mobile users are less ready to buy. It is because the mobile experience is usually worse.
Mobile-specific friction points include: touch targets smaller than 44 pixels that are easy to miss, forms that trigger the wrong keyboard type for the input (numeric keyboard not appearing for phone number fields), horizontal scrolling or content cutoff caused by unresponsive layouts, and page load times that are acceptable on WiFi but unusable on a 4G connection in a fringe signal area.
The practical approach is to audit the mobile funnel separately from desktop. Map the mobile drop-offs, watch mobile-specific session recordings, and run mobile-specific tests rather than assuming desktop winners will transfer. They often do not, because the experience is different enough that the same change can have opposite effects on the two surfaces.
Personalisation means showing different experiences to different users based on what you know about them: their traffic source, their geography, their past behaviour, their account status, or their position in the funnel. Done well, it produces large conversion lifts because the experience becomes more relevant to each user. Done badly, it produces complexity without lift and makes your analytics nearly impossible to interpret.
Start with the clearest signal you have. New vs returning visitors is the simplest split and often the most impactful: a first-time visitor needs a different message than someone who has already seen your product twice. Traffic source is almost as simple: a visitor from a branded search has different intent than a visitor from a top-of-funnel content piece. These splits are easy to implement and easy to measure.
Move to more sophisticated personalisation only after you have a clear read on the simpler signals, because the more variables you introduce, the larger the sample sizes required to measure each one cleanly, and the harder it becomes to know which change is driving a result.
The output of a CRO program is not just an uplift in conversion rate. It is a compounding sequence of evidence-backed changes that together move revenue. The metrics that matter for judging whether the program is working:
| Metric | What it tells you | Watch for |
|---|---|---|
| Conversion rate by funnel stage | Where users progress and where they stop | Stage-specific changes that do not move the overall rate |
| Revenue per visitor | The combined effect of conversion rate and average order value | Tests that lift conversion but reduce AOV |
| Win rate | What percentage of tests find a positive result | Win rates above 40% may indicate confirmation bias in hypothesis selection |
| Test velocity | How many tests reach significance per month | Falling velocity often means traffic split across too many concurrent tests |
| Cumulative conversion lift | The compounded effect of all shipped winners to date | Reversion in A/A tests after winners ship indicates interaction effects |
Revenue per visitor is the most honest metric for a CRO program because it captures the full effect of a change. A test that increases the number of free trial signups but reduces the percentage who convert to paid might show a conversion rate win that masks a revenue loss. Tracking revenue per visitor ensures you see both effects together.
Win rate is worth watching for a different reason. A program with a 70 percent win rate is probably not testing bold enough hypotheses. Interesting, well-grounded hypotheses should win roughly 30 to 40 percent of the time. If every test wins, you are either running very safe tests (small expected effect, almost certainly a winner) or measuring something too loosely to detect null results. Both are problems.
Test velocity and concurrency. Running too many simultaneous tests on the same traffic pool dilutes each test's sample size and extends the time to reach significance. A general rule: run no more than one test per primary conversion surface at a time, and size tests before launching so you can predict when they will finish. A program that runs four tests in parallel and calls them all after three weeks is running four underpowered tests, not four valid ones.
A short, honest list of the patterns we see most often in programs that are not moving the needle, and what to do instead:
A CRO program is not a project, it is a rhythm. The research phase never fully ends because users change, the product changes, traffic mix changes, and what was true six months ago may no longer be true today. The engagement is structured to reflect that.
The first month is primarily research and audit: funnel mapping, session replay analysis, heatmaps, and survey setup. The output is a prioritised hypothesis backlog with revenue estimates for each item and a proposed test schedule for the first two months. No tests launch until the research is done.
From month two onward, the engagement runs in cycles. Each cycle opens with a backlog review: which tests completed, what the results were, what new evidence arrived, and how the hypothesis ranking should update. Tests that won ship. Tests that lost generate a retrospective: was the hypothesis wrong, was the research wrong, or was the test underpowered? The answer determines what to do next.
Reporting runs monthly at minimum and weekly during active test periods. The report covers: tests in flight (current sample size, days remaining), tests completed in the period (result, revenue impact, decision), and the backlog for the next cycle (ordered by ICE score, with the reasoning behind the top three). You see everything. There is no black box.
See the CRO services page for the specific tiers and how the scope is set after the free audit.
How quickly will we see results? Simple landing page changes can lift conversion within two to three weeks once a test reaches significance. More complex funnel changes take longer because you need enough traffic to measure the effect reliably. A realistic horizon for meaningful, compounding gains is two to four months of consistent testing.
How much traffic do we need to run A/B tests? It depends on your current conversion rate and the size of lift you are testing for. A page converting at 2 percent and targeting a 20 percent relative lift needs roughly 5,000 to 7,000 visitors per variant. We calculate the required sample size before every test launches and will tell you plainly if a surface does not have enough volume to test reliably.
What A/B testing tools do you use? We work with whatever your team already uses: VWO, Optimizely, Google Optimize alternatives, Convert, AB Tasty, or custom split-testing built into your stack. We do not mandate a specific tool. We do mandate that the tool supports the statistical method (frequentist or Bayesian, with pre-defined stopping rules) before we use it for a paid engagement.
Do you work with our developers? Yes. For most tests we write a precise implementation specification that your developers can apply without a follow-up meeting. For simpler changes, we can implement directly using JavaScript in your testing tool without touching your codebase. We choose the path that gets to a live test fastest.
How do you handle statistical significance? We pre-define significance thresholds and sample sizes before each test launches. We do not look at results until the pre-defined sample is reached. We use a 95 percent confidence threshold for go/no-go decisions. For tests with multiple variants, we apply a Bonferroni correction to account for the increased false-positive probability.
That is the full methodology. When you want it applied to your funnel, the next step is a free conversion audit: your real funnel mapped, each leak quantified in revenue, and a prioritised hypothesis backlog delivered in about a week, with no obligation.
A free audit on your real funnel. Every leak quantified in revenue. A fixed scope to fix what the numbers justify.
Get a free conversion audit