How I Audit an Ecommerce Store: My 7-Layer Ecommerce Audit Framework
This is the ecommerce audit framework I actually use, written out in full. Not a summary of it, and not a teaser that stops before the useful part. If you want to run it yourself, everything you need is below.
I publish it because the method is not the hard part. Applying it to a store you have never seen, sizing what you find, and being willing to tell someone their problem is not worth fixing is the hard part.
The short answer
Seven layers, worked in a fixed order, because an unexamined upstream layer makes every downstream number lie.
Then each finding gets evidence, a euro estimate with its assumption visible, and an effort figure. Ranked by impact against effort, they become a 30, 60 and 90 day sequence your team can work through without me.
Why generic website reviews fall short
Most store reviews are a list of what the reviewer happened to notice, in the order they noticed it. That produces two failures.
The first is misattribution. A store whose category pages hide its best products will show a poor product page conversion rate, and a reviewer starting at the product page will spend the engagement fixing a page that was never broken.
The second is that nothing is comparable. Fifty observations with no cost attached cannot be ranked, and a list that cannot be ranked will be worked from the top, which means it will be worked in the order the reviewer noticed things. A fixed order and a common unit of measurement solve both.
The seven layers
Worked top to bottom. Each one can invalidate the readings of every layer beneath it, which is why the order is not negotiable.
Business & strategy
Margin by product and channel, contribution after fulfilment and ad spend, pricing structure, and whether the commercial model supports the growth being asked of it. A store selling its bestseller below contribution has a problem no checkout fix reaches.
Acquisition
Where traffic comes from, what it costs, and whether it is qualified. Conversion split by source before anything else, because one badly targeted campaign can make an entire storefront look broken.
UX & navigation
Whether visitors can reach what they came for. Category structure in customer language, filters that match how people decide, and internal search that tolerates plurals and misspellings.
Product experience
Whether the page answers every question standing between the buyer and the button, and how far they must travel for each answer. Delivery timing is the most commonly missing and among the most valuable to add.
Conversion
Cart and checkout: where costs surface, forced accounts, field count, error handling, payment methods per market. Usually the densest concentration of recoverable revenue in the whole audit.
Technical & analytics
Real-device performance on throttled connections, Core Web Vitals, script and app overhead, and whether the tracking reconciles with actual orders. If it does not, every number above is fiction and this layer gets fixed first.
Retention
Repeat purchase rate, lifecycle email and SMS, post-purchase experience. The layer most often skipped and frequently the most expensive omission: a store with weak repeat rate buys every customer twice.
How evidence is collected
Two passes over the same store, because they surface different things.
As a buyer. Real handset, mobile data rather than office wifi, real purchase attempts in every market you sell to, including a deliberately failed card to see what survives an error. This finds the friction you have gone blind to after two years of looking at your own store.
As an operator. Analytics open alongside the commercial data. This finds what a buyer would never notice: a line sold below contribution, a channel whose real cost hides behind last-click attribution, tracking that has quietly double-counted since a plugin update.
The reconciliation check comes first. Last month’s order count and revenue from the platform admin, compared against analytics. A few percent apart is normal. Fifteen percent apart means the audit would be run on fiction, and that becomes the first finding regardless of what else exists.
How an observation becomes a finding
An observation is “checkout is long”. A finding carries evidence, a number, and an assumption you are free to argue with. Every item in a report I deliver has this shape.
Delivery cost is not shown on the product page or in the cart. The first time a customer sees it is after entering their address, three steps into checkout.
Of 12,240 sessions that started checkout, 5,040 completed, a 58.8% drop. Session recordings show the largest single exit is the shipping step, and it is markedly worse on mobile.
Approximately −€4,200 per month. Assumes recovery of one third of mobile abandonments at current average order value. The assumption is stated so you can change it.
Surface a delivery estimate on the product page and a firm cost in the cart, before checkout begins.
Low. Theme-level change, roughly one developer day. No replatforming or app purchase required.
Note the assumption sitting in the open. A defensible range you can adjust is more useful than an impressive figure you cannot interrogate. Anything I cannot size honestly gets marked as unsized rather than padded to make the report look fuller.
How findings get ranked
Impact alone produces a wish list. Impact against effort produces a sequence, and the sequence is the actual deliverable.
The interesting quadrant is the top right. A replatform may genuinely be high impact, but it belongs in a plan with a budget and a timeline, not in the same list as a change that takes a developer a day. Separating those two is most of what makes a roadmap executable.
The bottom right matters too, because it gives you permission to say no. A full visual redesign is expensive and rarely moves the number by itself. Naming it as low priority in writing is often the most valuable line in the report.
How it becomes a 30, 60, 90 day roadmap
| Window | What goes in it | What you should see |
|---|---|---|
| First 30 days | Everything high impact and low effort. Cost visibility, delivery information, checkout friction, anything blocking a purchase. | Movement in the specific step metrics named in each finding |
| Days 31 to 60 | High impact, moderate effort. Performance work, search, category structure, lifecycle basics. | Improvement in the funnel stage above the one you fixed first |
| Days 61 to 90 | Structural items that needed planning: catalogue restructure, market expansion, platform decisions. | A decision made with evidence rather than a project started on instinct |
Each item carries the metric to re-measure, so in ninety days you can tell whether it worked rather than debating it. If nothing in a document can be verified, nobody can be held to it, including me.
What the client receives
- A recorded walkthrough of the store on mobile and desktop, so you watch the friction rather than read about it
- Every finding in the format above: problem, evidence, euro impact with assumption, recommendation, effort, priority
- The impact against effort ranking, so the argument in your next planning meeting is about evidence rather than seniority
- A 30, 60, 90 day plan written so your developers or agency can ticket it directly, without translation
- A performance and Core Web Vitals benchmark you can re-run yourself to verify the fixes worked
- A walkthrough call with you and whoever will do the work
Everything is handed over. Nothing is withheld to create a dependency, and no part of the analysis lives in a tool you would lose access to.
In the audit used as the worked example throughout this site, five findings of this kind totalled €118,800 a year in recoverable revenue. A three-day teardown starts at €400, and the fee comes off a full audit booked within 30 days.
Run it yourself if you would rather
The framework above is the whole method. Nothing is held back, and a capable operator can work it on their own store.
Two layers reward a deeper read on their own: layer six has a full treatment in the ecommerce analytics audit, and layer seven in the ecommerce retention strategy. What the framework produces at the end is an ecommerce growth roadmap.
Three things stay difficult alone: sizing each finding in euros, testing every market properly, and seeing past assumptions you built into the store yourself. If those are worth outsourcing, that is what you are buying. If they are not, take the framework and use it.
Start with the thirty-minute DIY version, work the 50-point checklist for the full journey, then go deeper on the two surfaces that decide most sales: the product page and checkout.