How to run a CRO audit: tracking, then the drop-off and its cause

A conversion rate optimization (CRO) audit examines where and why a site loses visitors, in a fixed order. It starts by proving the tracking is right, then finds the drop-off and looks for its cause in page reviews and user research. What you get from a CRO audit is a ranked list of fixes and test hypotheses, each tied to its evidence.

The order matters because every step reads the numbers of the step before it. If the purchase tag fails on one payment path, the funnel shows a bigger loss at that step than the real one. A test built on that loss is then measured with the same broken tag.

What conversion rate optimization is, its process and its tools are covered in the CRO guide. The examples here come from an online store. On a lead generation site you compare form submissions with the records in your customer relationship management (CRM) system instead of purchases with orders.

The five steps of a CRO audit each take the output of the previous one as their input. Each step has its own question and its own kind of evidence:

1. Tracking: are the numbers real? The evidence is a match between your order records and GA4, plus a test purchase. The output is a list of tracking errors to fix.
2. Step data: where is the drop-off? The evidence is funnel and path exploration with device and source breakdowns. The output is a list of steps and segments to review.
3. Page review: what on the page could get in the way? The evidence is an independent heuristic evaluation by several people. The output is a list of candidate problems with severity ratings.
4. Qualitative research: why do users stop? The evidence is session recordings, usability tests and surveys. The output is candidate causes based on observed behavior.
5. Hypotheses and priorities: what comes first? The evidence is everything the first four steps found. The output is a list of fixes, tests and open questions.

The first two steps count behavior but don't show its cause. Steps three and four suggest a cause but can't say how common the problem is. So before you turn a finding into a hypothesis, look for evidence of both kinds.

The tracking check tests whether the purchases GA4 counts match the orders in your order system. Compare with the right metric. As of November 2026, Google's ecommerce metrics page says Ecommerce purchases counts the purchase event only. Transactions also counts other events that carry a value, refunds among them, so Ecommerce purchases is the one to compare with orders.

Order numbers give the clearest answer. Google suggests the order confirmation number as the transaction ID and counts two purchases with the same ID as one. Export order numbers from your order system and the transaction IDs for the same period from GA4's Transaction ID dimension, then match the two lists.

Group the unmatched orders by device and payment method. A loss concentrated on one path points to where the candidate cause is.

The same Google page describes two opposite errors. If your tag sends the same ID for different orders, GA4 undercounts purchases. And every purchase sent with an empty transaction ID is treated as a duplicate of the others.

Review your key events in this step too. Google defines a key event as an event that measures an action particularly important to your business. If add to cart is also marked as a key event, key event counts in your reports include that step along with purchases.

A test purchase in DebugView

A test purchase confirms the candidate the matching points to. According to Google's DebugView page, you turn on debug mode for your own device with Tag Assistant or preview mode. Run the test on the path that looks broken, with the same device type and payment method. Accept Analytics cookies in the consent banner, because DebugView doesn't show events from users who haven't consented when consent mode is in place.

In DebugView, check first whether the purchase event arrives, then check its parameters. Google's page on fixing missing revenue data lists currency, transaction_id, value and items as required on the purchase event. It also says the value must not contain a currency symbol. If the event never arrives, check whether the user reaches the confirmation page where the tag runs.

Payment pages, domains and internal traffic

If checkout finishes on another domain, two settings need checking. Google's cross-domain measurement page says that without it, each domain a user visits creates new cookies with new IDs. The same person can then be counted as two users. You verify the setup by checking that the destination URL carries the _gl parameter.

When users come back from a third-party payment page, that domain can show up as a traffic source. Google gives this as the first example on its unwanted referrals page. The error doesn't lose purchases, but it can credit the session that holds the purchase to the payment provider. That distorts your channel breakdown.

Test traffic from your team or agency also gets into the numbers. Once an internal traffic filter is active, its effect is permanent and excluded data is never processed. Run the filter in its Testing state first and look at which events it catches.

Consent mode, thresholds and sampling

Users GA4 can't see explain part of the gap to your order records. Google's page on behavioral modeling for consent mode says a site with a consent banner will be missing data for users who decline. Modeling fills that gap with estimates only when the property meets its eligibility criteria.

So don't expect a complete match. What you're looking for is a path that departs from the loss the other paths share.

Two more limits apply when you drill into small segments. Google says data thresholds may apply to reports and explorations that include demographic data, and they're set by the system. Data may also be withheld in a narrow date range with low user or event counts.

Data sampling may apply when the events behind an exploration exceed your property's quota. If either one shows up, don't read the segment figure as an exact count.

Fix any tracking error you find before you move on, or write down which reports it affects. The gap between GA4 and Google Ads conversions is a separate question, covered in the post on why GA4 and Google Ads conversions don't match.

Step data shows which step and which user group the loss concentrates in, once you trust the tracking. In GA4 the tool for this is funnel exploration. In a closed funnel users must enter at the first step, while an open funnel lets them enter at any step. The funnel counts users, and a user enters it only once in the date range, so these figures aren't sessions or orders.

One detail of the device breakdown changes how you read it. Google says that with a breakdown dimension, users are attributed to the first value that applies to them. Someone who starts checkout on mobile and finishes on desktop appears under mobile in every step. On a site where many users switch devices, keep this in mind when you compare mobile with desktop.

Break the same funnel down by traffic source, by new and returning users and by landing page type. Rank the drop-offs by the number of users lost, not by rate. A high drop-off rate in a small segment can affect fewer users than a moderate rate in a large one. The funnel analysis calculator works out the progression and drop-off at each step.

Path exploration finds the loops a funnel doesn't show. Among its uses, Google lists uncovering looping behavior that may mean users are stuck. Users who move back and forth between cart and product page could be one such loop. The output of this step is a list of places: which step, which segment and how many users.

A heuristic evaluation reviews the pages step data points to against usability principles. Nielsen Norman Group's guide to heuristic evaluation advises against leaving it to one person. Ideally three to five people evaluate the same interface independently. Evaluators shouldn't see each other's notes until they've finished their own.

Step data sets the scope. NN/g suggests narrowing it to one task, one section, one user group or one device type. If the step data points to mobile checkout, the review stays with that task.

An evaluator new to the product goes through the task once just to learn the system. The second pass is for noting what breaks a principle.

A broken principle isn't automatically a problem to fix. NN/g writes that a design choice that violates a heuristic doesn't necessarily need fixing. The same guide says heuristic evaluation can't replace user research, so every note from this step stays a candidate problem.

Once the notes are merged, rate each problem. Jakob Nielsen's 1994 article on severity ratings ties severity to three factors. They are how often a problem occurs, how hard it is to overcome and whether it keeps coming back. The scale runs from 0 to 4.

Nielsen doesn't trust a single evaluator's rating and finds the mean of three evaluators good enough for many practical purposes. Collect the ratings after the review, once every evaluator can see the full list of problems.

On ecommerce sites you can add domain-specific guidelines to the general principles. Baymard Institute's article on conversion audits recommends covering the desktop and mobile versions of the site. It also recommends evaluating the site against a distinct set of usability and conversion guidelines. Page speed belongs in the review too, but it has its own measurement, covered in the post on landing page speed.

Qualitative research tests the candidates from the page review against real user behavior. NN/g sorts research methods by the difference between what people say and what they do, and notes the two are often quite different. A survey shows what people say, while session recordings and usability tests show what they do. Treat a survey answer as half the evidence until you find matching behavior in the recordings.

Rather than watching recordings at random, filter them to the segment your step data pointed to. Microsoft Clarity's semantic metrics page marks a dead click when a user clicks an element and gets no feedback in a reasonable time. A rage click is flagged when someone clicks the same small area several times in rapid succession.

Clarity says a dead click can point to a broken element, a slow request or a misleading design. The same page also tags JavaScript errors that occur after a click. If such an error happens every time, it's a fix, not a test.

Check the masking setting before you turn recordings on. Clarity's masking page says the content of input boxes is masked in every mode. As of November 2026, the default mode is Balanced. Mask any other element whose content shouldn't be stored as well.

A usability test lets you ask about the cause of what you saw in recordings. NN/g's usability testing guide says participants are often asked to think out loud while they work through tasks. Take the task from your step data, such as "pick a product on your phone and complete checkout."

When NN/g compares qualitative and quantitative testing, it calls qualitative data a direct assessment of usability and quantitative data an indirect one. In practice, when a few recordings or test sessions show a struggle, go back to step data to see how common it is.

A hypothesis turns an audit finding into a testable sentence and keeps the evidence attached. It has four parts: what you saw in step data and qualitative research, the single change, the expected effect and the metric that decides. Take this observation: "some mobile users who start checkout stop at the account screen." Recordings also show them going back from that screen. The hypothesis then reads "a guest checkout option may raise order completion among mobile users who start checkout."

The guest checkout scenario in the A/B test library sets out the evidence that makes such a hypothesis worth testing. It also lists what to keep fixed and which metrics to watch alongside the main one. Compare your own finding with the conditions under the scenario's "When to run this test" heading.

Set up the test so it can measure the effect of the change. Assign users at random when they become eligible, here when they reach checkout, and compare them by the group they were assigned to. Follow both groups for the same length of time. The control group keeps seeing the current checkout.

Before the test starts, write down what counts as a win. Also pick a guardrail metric, such as the cancellation and return rate, and set the limit at which it stops the test.

The sample size calculator tells you how many users you need. If the finding is mobile only, decide before launch that the test runs on mobile only. The post on A/B test segmentation explains the risk of splitting results into segments afterward. Record an unclear result as unclear, not as "no effect."

Prioritizing decides which findings get fixed, which get tested and which need more research. Tracking errors go to the top, because until they're fixed the numbers behind every other finding can't be trusted. The type of finding settles most of the decision:

The first two rows don't need a test, because both the problem and the fix are known. After the fix, compare the step data with the previous period and note other changes, such as seasonality or campaigns. The third row is what tests are for, and the fourth isn't a hypothesis yet.

Compare the remaining findings on the same criteria: the number of users who reach the step, the type of evidence and the effort. For each finding, write down the users or orders it affects, the gap visible in today's numbers and the gain from fixing it. The gain stays unknown until you test, and you shouldn't compare one finding's optimistic estimate with another's pessimistic one.

The prioritization frameworks that reduce this ranking to a single score are compared in the CRO guide.

A hypothetical store starts its audit with four weeks of data. In GA4's closed funnel, 38.5% of mobile users who start checkout appear to buy, against 58.8% on desktop. Mobile checkout goes straight to the top of the list. The example assumes each user places at most one order in the period and completes it on the device where checkout started.

The matching in the tracking step shows the loss concentrates on one payment path. GA4 has 98% of desktop orders and of mobile orders paid by card on the site. For mobile orders that go through an external payment page, it has only 21%:

The figures are hypothetical and the match is rounded to one decimal place. Of the 400 orders through the external payment page, 316 are missing from GA4. The candidate cause is users who don't return to the confirmation page after paying, or a tag that doesn't fire there. That's an inference, and a test purchase on that path confirms or rules it out.

Hypothetical example: when the assumption changes

Nobody knows yet how many of the external path's orders GA4 will see once it's fixed, and that assumption drives the decision. If it matches like the other paths at 98%, GA4 shows 1,078 mobile purchasers. As the assumption goes down, the mobile checkout gap opens up again:

The number of users who start checkout is the same in every row: 2,000 on mobile and 1,500 on desktop. Desktop completion is 58.8%.

Under all three assumptions, more than half of the gap GA4 shows comes from tracking, leaving a gap of 4.9 to 8.5 points. Mobile checkout still trails desktop, but its priority has to be compared again with the other findings on the corrected numbers.

Hypothetical example: the three figures

The affected amount is the 400 orders on the external payment path, which is 20% of all orders. The visible gap is 20.3 points in GA4, and after the fix it shrinks to a few points depending on the assumption.

The gain from the fix is the third figure, and nobody knows it yet. Fixing the tag doesn't bring a single extra order. It fixes the report, and the gain from closing the remaining gap can only be measured with a test.

If the tracking step had been skipped, the first test idea might have been to push the external payment option down on mobile. Measured with the broken tag, that test would produce a false winner. Suppose all 400 buyers on the external path paid by card instead. GA4 would record them at the card path's match rate, 392 rather than 84.

GA4 would then show 308 more purchases without a single extra order. The test's "winner" label would show nothing but a tracking error moving from one path to another.

The first day of the audit goes to matching your order records with GA4. That check sets the numbers for every other step, so a short list is enough:

1. Export the last 28 days of order numbers from your order system, with device and payment method.
2. Export the transaction IDs for the same period from GA4 and match the two lists on order number.
3. Group the unmatched orders by payment path and run a test purchase on any path that departs from the others.
4. If one path departs, fix the tag first. If none does, move on to step data.

After fixing a path that departed, run the same match again for the following period. Carry out the rest of the audit on those new numbers.