CRO Audit Services
A CRO audit is a fixed-scope diagnosis of why your funnel loses the visitors it loses. It combines analytics, recorded behaviour, customer language and a structured heuristic review of every step in the conversion path, and it ends in a prioritised list of findings with the build cost of each one written next to it. It is the sensible first purchase if you are not ready to commit to an ongoing programme, and it is the first phase of one if you are.
CRO strategy, design and development across Shopify, WordPress, Convert, Optimizely, VWO and Adobe Target.
Does this sound familiar?
These are the situations teams actually describe when they get in touch about this, not a generic list of pain points.
You know the number is bad and not why
The conversion rate is below where it should be and the internal debate has been running for months on nothing but opinion and the last thing somebody read.
The last audit was a slide deck of best practices
Forty generic recommendations that could have been written without opening your site, none of them evidenced, and none of them costed.
Nobody can tell which fix to do first
You have a list. What you do not have is a defensible order, so the cheapest item gets done and the expensive high-impact one never does.
You are about to spend on a redesign
A redesign built on assumptions can just as easily move the number down. Knowing what is currently working, and why, is the difference between a redesign and an expensive coin flip.
You are not sure the data can be trusted
Analytics says one thing, the platform says another, and nobody has audited the instrumentation in years. Every decision downstream of that inherits the problem.
What changes when this works
Stated as the position you end up in. No percentages: we do not publish outcome figures without the measurement conditions and the client’s agreement to it.
- A specific, evidenced answer to where and why your funnel leaks
- A findings list ordered so you can start on Monday and know you started in the right place
- The build cost of each finding, so the roadmap can be resourced rather than just admired
- A clear statement of whether your instrumentation can currently measure a change at all
- A decision, per finding, on whether it should be tested or simply fixed
- Enough evidence to argue for the budget the fixes need
What is included
Scope stated as specific outputs rather than as adjectives.
- GA4 and funnel analysis: entry points, step-by-step drop-off, and the segments that behave differently from the average
- An instrumentation review: what is tracked, what is double-counted, what is missing, and whether a result could be read today
- Heatmap and session-recording analysis across the revenue-critical templates
- Voice-of-customer input: on-site or post-purchase survey responses where they exist, plus existing sales and support conversations
- Heuristic and UX evaluation of every step from landing to confirmation, on real devices
- A technical review of the constraints: theme, apps, tag stack, page speed on the templates that matter
- Findings written individually, each with the evidence behind it, a severity and an estimated build effort
- A prioritised roadmap ordered on impact, confidence and effort
- A test-or-fix decision per finding, with the sample-size arithmetic where a test is proposed
- A walkthrough call to talk through the findings and what you should do first
How the work runs
- 1
Scope and access
We agree which funnels are in scope — usually the paid landing path, the product or service page, and the cart or form path — and you grant read access to analytics, tag manager and any recording tool. We tell you the exact list before you start.
- 2
Quantitative pass
Funnel shape, drop-off by step, device and channel splits, and an instrumentation check. This decides where the qualitative work is worth spending time.
- 3
Behavioural and customer pass
Recordings and heatmaps on the pages the numbers pointed at, plus whatever the customers have already said in surveys, reviews and support tickets.
- 4
Heuristic and technical review
A structured walk of every step in the path on real devices, against conversion and usability heuristics, cross-referenced with what the codebase will actually allow.
- 5
Write, prioritise and cost
Findings written up with their evidence, ordered, and costed. Anything we could not evidence is labelled as a hypothesis rather than presented as a fact.
- 6
Walkthrough and next steps
We take you through it live, argue the priorities with you, and agree what happens next — whether that is us building it, your team building it, or nothing yet.
What you receive
The artefacts that exist at the end, all of them yours to keep and to hand to somebody else.
- The audit document itself: findings, evidence, severity, build effort
- The prioritised roadmap as an editable file you keep
- The instrumentation review, listing what needs fixing before anything can be measured
- Annotated screenshots and recording clips for the findings that need to be seen rather than described
- A test-or-fix recommendation per finding, with expected run times where a test is proposed
- A recorded walkthrough call, so people who were not on it still get the reasoning
Who this is for
Ecommerce and lead-gen teams with unexplained flat conversion
Traffic is steady, the number is not moving, and the internal debate has run out of evidence.
Teams about to commission a redesign
You want to know what is currently working before somebody replaces it.
Businesses evaluating whether to start a CRO programme
You want to see the quality of the thinking on a fixed scope before committing to a retainer. That is a reasonable thing to want.
In-house teams who need evidence for a budget request
You already know roughly what is wrong. What you need is a costed, evidenced case somebody else will sign off.
Who this is not for
Saying this up front saves both of us a call. If you are on this list, the right next step is usually elsewhere on this site rather than nowhere.
- Teams who already have an audit and need it implemented — go straight to CRO web development or A/B test development
- Sites with almost no traffic and no customers yet. There is not enough behaviour to analyse, and the honest advice at that stage is usually about the offer, not the funnel
- Anyone wanting a one-page score out of 100. A number is not a finding and cannot be built
- Buyers who want the audit to conclude that the thing they have already decided to do is correct
Why us rather than the alternatives
Every one of these is a legitimate way to get the work done. Here is where each of them tends to break, so you can decide honestly.
Instead of an automated audit tool
A tool can tell you the page is slow and the button contrast is low. It cannot watch forty sessions and notice that people are abandoning at the delivery step because the estimate contradicts the promise on the product page.
Instead of a generic best-practice review
Every finding here is tied to something observed on your site, in your data or in your customers’ words. If we could not evidence it, it is labelled as a hypothesis rather than dressed up as a conclusion.
Instead of an audit from a team that does not build
Findings are costed because the people writing them build this kind of work every week. That is what makes the roadmap orderable rather than aspirational.
What the audit reviews, and with what
Named specifically, because “modern tooling” tells a buyer nothing.
- GA4 explorations, funnel and segment reports
- Google Tag Manager configuration and event integrity
- Session recordings and heatmaps (Microsoft Clarity, Hotjar, or your existing tool)
- On-site and post-purchase survey responses, where they exist
- Existing sales call notes, support tickets and product reviews for customer language
- Product, collection, cart, checkout, form and landing templates on real devices
- Core Web Vitals on the revenue-critical templates, measured on a throttled mobile profile
- The theme, app and tag stack, for what each finding would actually cost to change
How this gets checked
Every engagement carries a QA pass. It is written down so that “QA done” means something specific.
- Every finding names the evidence it came from, or is explicitly labelled a hypothesis
- Findings are checked against the live codebase before they are costed
- Sample-size arithmetic is run before any finding is proposed as an experiment
- The instrumentation review happens first, because findings drawn from broken tracking are worse than no findings
- Nothing is included because it is a common recommendation; it has to be true of your site
The full pass, including the post-launch checks, is described on our CRO and experiment QA service. It is also available on its own, on experiments somebody else built.
Ways to work together
The commercial shape is chosen after we know the scope, not before.
Dedicated partnership
Reserved capacity for a steady pipeline of work.
Flexible hours
Draw down specialist time as the work arrives.
Project engagement
A defined scope, owned end to end.
All three are described in full under engagement models.
Questions people ask before buying this
Related services
Experimentation platforms we build on
Further reading
Get a Conversion Audit
Tell us which funnel matters most and we will come back with the scope, the access we need and what the finished audit will contain.