Conversion rate optimisation audit: what to check before you run a single test

A broken funnel report sends you after the wrong problem. Check the numbers before you trust them.

• Define your conversion rate. Say what sits under the line. Shops usually mean orders divided by sessions. Google Ads divides conversions by ad interactions. Write down which one your report uses.
• Check the funnel steps. GA4 has a funnel exploration report that builds steps from events or dimension values you choose³. Google's ecommerce documentation lists begin_checkout, add_shipping_info, add_payment_info and purchase as the events for measuring a purchase funnel⁴. Confirm each fires once, in order, on the right page.
• Check your key events. In GA4, a key event is an event you mark as important to the business. Make sure the ones you rely on are the ones you mean.
• Compare with the shop. Orders in analytics should be in the same range as orders in the shop back end. A large gap means tracking, not customers, is the first thing to fix.

If a step drops to nearly nothing, suspect a tag before you suspect shoppers.

A sitewide conversion rate averages very different visitors. Split before you judge.

• By source. Email, brand search, paid social and cold prospecting behave differently. A drop in the average may be a change in the mix, not a change in the site.
• By device. Mobile and desktop shoppers face different pages. A weak mobile result is a site finding. A weak result from one campaign is a traffic finding.
• New vs returning. People who already know the shop behave differently from first-time visitors. Keep them apart.

Some traffic will never convert, because the ad promised something the page does not offer. Fix that in the ad account, not in the checkout.

Walk the path as a customer on a phone. Then read the funnel against what you saw.

• Product pages. Can a visitor answer price, delivery, returns and size without scrolling for them? Are the photos enough to buy from?
• Cart. What shows here that was not on the product page: shipping costs, delivery dates, discount code fields? If carts are abandoned, look for surprises here first. Cart abandonment is carts created minus completed orders, divided by carts created.
• Checkout. How many fields, how many payment options, how many forced steps? Do error messages say what is wrong?

Record each issue with the page, the device and the evidence. "The form felt long" is a note. "The form lost visitors at the address step, mostly on mobile" is a finding.

A slow page can lose a shopper before the offer loads. Look at how the pages perform for real visitors, on real phones.

Core Web Vitals are Google's page experience metrics, covering loading, responsiveness and visual stability. Check them with field data first, then use lab tools to find the cause. Field data tells you whether there is a problem. Lab tools tell you where.

Then use the phone yourself. Tap targets, pop-ups that cover the page, sticky bars that hide the buy button. No tool replaces ten minutes of trying to buy something.

Usability research finds problems. It does not measure how big they are. Nielsen Norman Group argues that a small number of participants is enough to find problems in a qualitative study, and not enough to measure them in a quantitative one⁵. The same researchers list exceptions where they recommend more participants, such as card sorting and eyetracking⁶. Treat any single number of participants as a rule of thumb, not a law.

In practice:

• Use a few sessions to find what confuses people. Then fix the obvious and run more.
• Use analytics, surveys or a controlled test when you need to know how common a problem is.
• Do not read a quote from one participant as a trend.

A list. Each row should have:

1. The problem and where it shows up (page, device, source).
2. The evidence behind it: data, session notes or both.
3. A hypothesis: "if we change X, Y will improve because Z".
4. A rough view of effort and how much revenue sits behind the page.
5. Whether it needs a test, or just a fix.

Many items on that list will not need a test. A broken button is not a hypothesis. Fix it.

For ZFD: We run CRO audits and implement the changes, so the list does not stay a list. Audits are free. We do not promise a result.