The Shopify CRO Audit Playbook: 5 Steps I Run on Every Store Before Writing a Single Line of Code
The exact five-step audit sequence I run before touching a theme — from click-loss reconciliation through to fulfilment-truth review — and why the order matters more than the tactics.
Most CRO audits fail at step one, not because the auditor is bad but because the sequence is wrong. Teams start with heatmaps because heatmaps are fun. They start with a theme redesign because redesigns are the deliverable everyone wants to see. Both are the wrong door.
Here is the sequence I run on every store before writing a single line of code.
Step 1 — Reconcile Clicks Against Arrivals
Before anything else: how many clicks did the ad platform bill you for, and how many people actually arrived?
Pull Meta outbound clicks from Ads Manager. Pull landing page views from GA4. Compare the two numbers over the same 30-day window.
| Gap | What it means | Where to look |
|---|---|---|
| Under 8% | Healthy | Nothing — move on |
| 8–15% | Guarded | Tracking drift, minor attribution loss |
| 15–30% | Elevated | Real loss plus measurement gap |
| Over 30% | Critical | The money is leaving before the page renders |
This single comparison determines whether your first project is a performance project or an analytics project, and getting that wrong means you spend six weeks optimising the wrong layer.
Why order matters: if you rebuild a theme for a store whose real problem is a broken CAPI dedupe, you will deliver a beautiful, fast, perfectly instrumented site that still reports the same revenue — and you will look like you failed.
Step 2 — Establish the Field-Data Baseline
Lab data is a laboratory. Field data is your customers.
Open CrUX for your top 20 URLs, not just the homepage. Look at p75, not the average — p75 is the experience of your worst-performing quartile, which is where the revenue loss lives.
Then check the three Core Web Vitals at field level:
- LCP — is the hero image the LCP element, and is it preloaded?
- INP — what is the longest interaction? A review widget, a size selector, a variant picker?
- CLS — does anything push content down after first paint? Usually a late-loading banner, a cookie bar, or a font swap.
Record the baseline. Write it down. This is the number you will be held to, and it is the only defensible way to claim a lift later.
Step 3 — Map the Leakage, Not the Pages
Most audits list every page. That is a list, not a diagnosis.
Build a leakage map instead: for each stage of the funnel, what is the drop rate, and what is the single most likely mechanical cause?
Ad click → Landing view (loss: click-loss audit)
Landing → Add to cart (loss: offer clarity, price shock, ATC visibility)
ATC → Checkout (loss: cart drawer friction, forced account creation)
Checkout → Purchase (loss: shipping threshold surprise, payment friction)
Purchase → Repeat (loss: no post-purchase flow, no replenishment prompt)
One number per stage, one hypothesis per stage. That is the whole audit. Everything else is commentary.
Step 4 — Check the Promise Chain
This is the step almost every technical audit skips, and it is the one that determines whether a high-ticket brand grows or churns.
Walk the full promise chain for your top three SKUs:
- The ad promise — what does the creative claim?
- The landing promise — does the first screen confirm or contradict it?
- The PDP promise — do the images, copy and spec support the ad?
- The cart promise — any surprise in price, shipping or duties?
- The parcel promise — does the box match the expectation?
Any break in this chain is a refund request waiting to happen, and at $99+ a refund request costs you far more than the order value once you count shipping, payment fees and the support time.
Step 5 — Rank by Revenue Impact Against Effort
Now, and only now, you write recommendations.
Score every candidate fix on two axes:
- Revenue impact — if this is fixed, how much monthly revenue moves?
- Effort — engineering hours, plus risk, plus how long it takes to verify
Anything that is high-impact and low-effort ships in week one. That is usually three to five changes, and it is typically 60% of the available upside.
Anything high-impact and high-effort goes on the roadmap with an explicit date and an explicit owner. If it does not have both, it is not a recommendation, it is a wish.
What the Deliverable Should Look Like
A 50-slide deck is not an audit. It is a way of avoiding accountability.
A useful audit deliverable is:
- One page of numbers — the baseline, in a table
- One ranked list — every fix, scored by impact and effort
- One page per top-three item — the specific change, with the code or the instruction, and the measurement plan
- A 90-day sequence — what ships in week 1, month 1, month 3
That is it. If the deliverable is longer than the work it describes, you have written a brochure.
The Question Nobody Asks
Before you deliver, ask the client one question: “If we do everything in this report and nothing changes, what will you have learned?”
If the answer is “we will know exactly where the leak is”, the audit was worth it. If the answer is “we will have a document”, it was not — and you should have sold them a sprint instead, because a sprint ships fixes instead of describing them.
Run the free Click-Loss Auditor to get your Step 1 number in under a minute, or the Ad ROI & Latency Calculator to price the latency side of the same problem.
Specializing in sub-100ms Jamstack platforms, zero-JS Islands architectures, and cloud cost optimization on Cloudflare Edge.