The CRO Audit to Run Before You Plan Any Test

Most CRO audit checklists start at the top of the funnel and work down: traffic, landing page, form, confirmation. That ordering assumes the people arriving are able to complete the action and simply need to be persuaded. On several programs I have run, that assumption was the single most expensive thing in the roadmap — because the biggest blocker to conversion sat entirely outside the funnel we were optimizing, and no landing-page test could have touched it.

So the audit I run first is not a page audit. It is an eligibility audit.

An eligibility audit is the step that quantifies what share of your addressable audience can actually complete the action before you spend a single test cell trying to persuade them to.

This article is the checklist version of that step, written from the diagnostic angle: the mistakes that make a CRO audit produce a confident, well-formatted, useless test roadmap — and what to do instead.

What a CRO audit is actually for

A CRO audit has one job: to tell you where the constraint is. Not where the friction is — friction is everywhere, always, on every page — but which constraint, if relieved, moves the outcome metric.

The failure mode is that most audit templates can only see one class of constraint. They inventory page-level problems, because pages are what the auditor can look at. Load time, headline clarity, form field count, CTA contrast, trust signals, mobile layout. Every finding is real. Every finding is also downstream of a question the template never asked: of the people who did not convert, how many were ever able to?

If the answer is "most of them were able to, they just chose not to," you have a persuasion problem and the page audit is the right tool. If the answer is "a large share could not have completed this regardless of the page," you have a targeting and expectation-setting problem, and every page test you run will resolve inconclusive while you slowly conclude that "the traffic is bad."

Both of those roads lead to a test roadmap. Only one of them leads to a test roadmap that can work. This is the same diagnostic discipline behind why A/B tests fail before they start — the fatal decisions are made in the planning stage, not the analysis stage.

Mistake 1: Auditing the funnel instead of the audience

The first mistake is scope. The funnel you can see in analytics starts at a page view. The decision the user is making started earlier, and often ended earlier too.

On a program I worked on for a hardware-dependent savings offer at a large energy retailer, we ran research across the enrollment audience — a survey of more than two hundred users spanning four brands in the same category. The top reason people had not enrolled was not the landing page, the form, or the incentive copy. It was that they did not own the equipment the program required. They were not unpersuaded. They were ineligible.

Read that back against a standard audit template. Not one line item on a page-level checklist can move "does not own the required hardware." You could have run a full year of enrollment-flow tests — headline, hero, form length, social proof, button copy — and the ceiling would not have moved, because the ceiling was not in the flow.

The fix is a scope change, not a new tactic: before you audit any page, define the addressable audience as people who can complete the action, and find out how big it is relative to the traffic you are sending.

Mistake 2: Treating "did not convert" as one population

The second mistake follows directly. Analytics gives you a single non-converter bucket, and the bucket is a lie. It contains at least four populations, and they need completely different interventions:

• Ineligible. Cannot complete the action — missing hardware, wrong region, wrong plan, wrong account type. No amount of persuasion applies.
• Eligible but uncertain of it. Could complete the action, but cannot tell from your page whether they qualify. This is a comprehension and expectation-setting problem.
• Eligible and clear, but unconvinced of the value. The offer was understood and rejected. This is a genuine persuasion problem — and often an incentive-framing problem rather than an incentive-size one.
• Eligible, clear, convinced, and blocked by the flow. This is the only population a conventional CRO page audit is designed to serve.

In the same research, the second and third-order blockers were compatibility confusion and low perceived value of the incentive. Both are pre-funnel. Both are also cheaper to fix than the eligibility gap itself — and notably, uncertain value multiplied by uncertain eligibility rounds to no, which is why programs that fix only one of the two often see nothing move.

The practical version of this: any audit finding that does not name which of the four populations it serves is not yet a finding. It is an observation.

What does an eligibility audit actually look like?

It is four questions, and it usually takes less time than building one test.

1. What is the hard prerequisite? Write down every condition that must be true for a user to complete the action. Equipment, account status, geography, plan type, credit, contract timing. Be literal. Teams routinely discover during this step that nobody had written the full list down anywhere.

2. What share of your traffic meets it? This is a data question first — join against whatever system knows the truth — and a research question second, when the system does not know. A short survey against the non-converting audience will give you the rough split faster than an instrumentation project will.

3. What share of the eligible audience *knows* they are eligible? This is the gap that masquerades as a persuasion problem. If people who qualify cannot tell they qualify, your page is failing at classification, not at selling.

4. Which of the three levers is the binding constraint? Eligibility expansion, expectation setting, or flow optimization. Rank them by the size of the population each one unlocks, not by how easy they are to test.

Only after step four does a test plan make sense. The pre-test feasibility check then tells you whether the population you identified is even large enough to detect an effect in — which is the second place good roadmaps die.

Mistake 3: Skipping straight to expectation-setting copy

Once a team accepts that eligibility is the issue, the reflex is to fix it with copy: add a qualifier line, add an eligibility checker, add a "you may not qualify if…" block. Sometimes that is right. But shipping it before you know the split is how you trade one unmeasurable problem for another.

If a large majority of your traffic is ineligible, clearer eligibility copy will reduce your conversion rate on the page and improve the quality of everything downstream. That is a good trade — and it will look like a losing test to anyone reading only the primary metric. You need to have decided in advance that qualified-lead rate or downstream completion is the metric of record, or the test will be killed for succeeding.

If a large majority of your traffic is eligible and merely confused, the same change should lift the primary metric outright, and it becomes one of the highest-leverage copy tests you will run all quarter.

Same intervention. Opposite predicted direction. The eligibility split is what tells you which world you are in, and running the test without it means you cannot interpret the result either way. That is the interpretation trap in when not to A/B test: some questions are diagnosis questions, and a test is the wrong instrument for them.

How do you know when the flow really is the problem?

Flow optimization earns its place at the top of the roadmap when three things are true:

• The eligible population is large enough to power a test at your traffic and baseline.
• Eligible users can determine that they qualify without contacting anyone.
• Drop-off concentrates at a specific step rather than distributing evenly across the flow.

That third condition is worth dwelling on. Evenly distributed drop-off across every step is the signature of a motivation or eligibility problem wearing a flow-problem costume — people are leaving because the thing is not for them, and they leave at whatever step they happen to be on when they realize it. Concentrated drop-off at one step is a real flow problem and usually a fixable one.

Session replay is the fastest way to tell the two apart, and it is chronically underused for this specific diagnosis. Watching where hesitation clusters — and what users do immediately before abandoning — separates "I cannot do this" from "I do not want to do this" in an afternoon. The broader case for that is in qualitative analysis of quantitative tests.

What the experiment record shows

The evidence pattern here is consistent across programs, and it is worth stating in the form the data actually supports rather than a tidier form it does not.

In the research described above, the top three barriers to enrollment were all pre-funnel: missing prerequisite hardware, compatibility confusion, and low perceived incentive value. None of the three was addressable by an enrollment-flow test. That is a finding about where the constraint lives, not a percentage claim — and the useful version of it is structural.

In the broader test record, the pattern shows up as an outcome distribution. Programs that test flow mechanics against a poorly qualified audience produce a portfolio dominated by inconclusive results — the majority-inconclusive pattern that shows up whenever tests are run against a population that cannot respond to the change. Where changes were matched to a correctly diagnosed constraint, the winners cluster in the mid-single-digit to low-double-digit percentage range, which is what a real effect on a correctly scoped population tends to look like. The experiment library makes that distribution browsable, and the inconclusive and losing tests are the more instructive half — a losing or flat result on a well-designed test is usually the audit finding you refused to run.

The mechanism generalizes past this one category. A mobile checkout CTA test is a legitimate flow test precisely because everyone reaching that step is already qualified — eligibility was resolved upstream. The further from the point of purchase you move, the more of your non-converting population is made up of people who were never going to be able to say yes, and the less a flow test can tell you.

The checklist

Run this before the roadmap, not after:

1. Write the literal list of prerequisites for completing the action.
2. Quantify what share of current traffic meets them — from data if possible, from a short survey if not.
3. Quantify what share of eligible users can tell they are eligible from the page alone.
4. Split non-converters into the four populations: ineligible, uncertain, unconvinced, blocked.
5. Rank the three levers — eligibility expansion, expectation setting, flow optimization — by population size unlocked.
6. For any test aimed at expectation setting, pre-register the metric of record and the predicted direction, including the case where the primary metric falls.
7. Check drop-off shape: concentrated at a step, or even across steps.
8. Only now build the test plan — and run it through a feasibility check before committing a cell.

Steps 1 through 5 are the part almost nobody does. They are also the part that determines whether steps 6 through 8 produce anything.

Key Takeaways

• A CRO audit exists to locate the constraint, and page-level templates can only see one class of constraint.
• Research on a hardware-dependent enrollment program found the top three barriers were all pre-funnel — eligibility, compatibility confusion, and perceived incentive value — none addressable by a flow test.
• The "did not convert" bucket contains four distinct populations that need four different interventions; a finding that does not name its population is only an observation.
• Eligibility-clarifying copy can correctly lower your primary metric, so decide the metric of record before you ship it.
• Evenly distributed drop-off signals a motivation or eligibility problem; concentrated drop-off signals a real flow problem.
• Rank levers by the size of the population they unlock, not by how easy they are to test.

FAQ

How is an eligibility audit different from a standard CRO audit?

A standard CRO audit inventories problems on the pages users see. An eligibility audit asks a prior question: what share of the audience arriving at those pages is capable of completing the action at all. The first assumes a persuasion problem and looks for friction; the second tests whether persuasion is the relevant lever before you spend test cells on it.

How long should an eligibility audit take?

Less time than building one test. If the prerequisite data lives in a system you already have, it is a query and an afternoon. If it does not, a short survey against the non-converting audience gives you a usable split in a week or two — still far cheaper than a quarter of inconclusive flow tests.

What if I can't get eligibility data at all?

Then treat the split as an explicit unknown in your test plan rather than an implicit assumption. Add a qualifying question to the flow, or use a proxy — support contact reasons, sales disqualification codes, session replay of abandonment — and note in the hypothesis that the effect size estimate is unreliable until the split is known. Documenting the unknown is what makes the eventual result interpretable, which is the same logic behind a hypothesis intake standard.

Doesn't this just mean the traffic is bad?

Not usually. "Bad traffic" is the conclusion teams reach when they have run out of page ideas, and it ends the investigation. Eligibility framing continues it: if a defined share of the audience cannot complete the action, that is a targeting spec, an expansion opportunity, or an expectation-setting brief — three concrete workstreams rather than one shrug.

Where does prioritization scoring fit in?

After the audit, never before. Scoring frameworks rank ideas against each other, but they cannot tell you that an entire category of idea is aimed at the wrong constraint — they will happily rank ten flow tests in a program whose ceiling is eligibility. That blind spot is covered in more depth in why prioritization frameworks fail at predicting test impact.