CRO audit with a backlog sorted by what is testable

At 8,000 eligible sessions a month against a 2.4 per cent baseline, the smallest effect a four-week test can detect is around 35 per cent relative. Almost nothing you want to change moves a number that far. So the sorting question this audit answers is not what to test first; it is which findings can ever be tested on your site and which have to be shipped on judgement and never measured. Programmes usually fail because nobody did that sort, and a year later the backlog holds forty items that were never going to reach significance. How the audit runs: Three weeks. Tracking validation comes first and everything downstream waits on it; in roughly one audit in four we find a conversion event that double-fires, drops on a redirect or attributes to the wrong session, and until that is fixed the funnel numbers are fiction. Then the funnel is read from event-level warehouse data rather than from a montage of session recordings. Field-level form analytics where a form carries the conversion. Field performance on the templates that carry the traffic, taken from CrUX rather than a lab score, because a lab score is a claim about a machine in a datacentre. Two of us run the heuristic pass independently and the disagreements stay in the document instead of being averaged into a consensus nobody holds. The backlog: Twelve to eighteen hypotheses. Each carries eligible monthly traffic, baseline rate, the detectable effect at four and at eight weeks, the unit of analysis, and a route: run it as a test, ship it and monitor guardrails, or discard it with the reason. The document also lists what we examined and dismissed, so your next agency does not re-sell you the same idea in a nicer deck. No ICE scores: An impact guess from one to ten multiplied by a confidence guess from one to ten yields a unitless number that no one can argue with, which is exactly why the format is popular. Our sort key is expected value in euros where the inputs exist to estimate it, and a written statement of uncertainty where they do not. You are welcome to disagree with an estimate; that is the point of showing it. What is not in scope: We do not deliver a hundred recommendations, and a shop that does is billing for volume. No wireframes or visual design; the backlog states the change and the mechanism, your designers own the execution. No user research beyond eight to twelve moderated sessions if you commission them, and no persona work. We do not run the tests inside this engagement, and you are free to take the backlog to another team without penalty. That independence is the reason the discard list is honest. This is not for you if: The site is being replatformed within two quarters; audit the new one and save the fee. You need a deck for a board meeting rather than a working document for the people who will build. You want a scoring spreadsheet you can maintain internally, which is a legitimate thing to want and not what this is. Your site takes under about 5,000 sessions a month on the templates in question, in which case almost the entire backlog routes to ship-on-judgement and you do not need three weeks of our time to hear it. How it closes: A working session with the people who will implement, not a presentation. Sponsor, product and engineering in the room, and we leave once the first three items have owners and dates. English or Dutch.