How do you do CRO when you don’t have enough traffic to A/B test?

A/B testing occupies an odd place in conversion optimisation. It is rightly treated as powerful evidence, but it is often spoken about as though every business has enough traffic, enough conversions and enough time to test every meaningful decision.

Most do not.

A service business with 500 relevant visits a month cannot sensibly split that traffic across a long queue of small interface ideas. A new landing page cannot provide historical evidence before the campaign begins. A B2B website with a long sales cycle may wait months for enough downstream outcomes to learn anything useful.

The wrong conclusion is “we cannot do CRO”. The better conclusion is that experimentation is one stage of CRO, not the whole discipline.

Use an evidence ladder

When traffic is scarce, the goal is not to manufacture statistical certainty. It is to reduce uncertainty using several appropriate sources.

1. Technical evidence: Does the journey work across relevant devices and states?
2. Heuristic evidence: Does it violate established usability, accessibility or behavioural principles?
3. Observed behaviour: What do session recordings, support conversations and sales objections repeatedly show?
4. Simulated journeys: What do defined customer perspectives misunderstand, question or fail to complete?
5. Human research: What do representative people explain in interviews or usability sessions?
6. Outcome data: Do analytics and experiments support the proposed effect at scale?

Not every change needs every rung. The commercial risk and cost of the decision should determine how much evidence you need.

Start with the decision, not the button

Weak CRO backlogs are often collections of interface preferences: change the colour, shorten the headline, move the testimonial. Strong backlogs describe a customer problem and the evidence behind it.

Instead of “make the CTA more prominent,” write: “First-time buyers found the CTA but delayed because they could not predict whether it opened self-service onboarding or a sales conversation.” The second statement tells you what information is missing, which audience is affected and what outcome to observe.

That is the role I see for PersonaQA. A simulated customer does not prove that real conversion will rise. It can expose a plausible mechanism worth validating.

What to do before traffic arrives

Before a page launches, you can still pressure-test the proposition:

• Can the intended customer explain what the product does and who it is for?
• Can they find the information needed to compare or decide?
• Are price, commitment and the next step predictable?
• Does proof appear where doubt is created?
• Can the journey be completed on mobile and with different interaction needs?
• Do several independent perspectives encounter the same barrier?

This will not tell you the future conversion rate. It can prevent avoidable ambiguity from being the first thing paid traffic discovers.

After launch, connect the evidence

Once traffic arrives, simulation should not compete with real behaviour. It should become easier to confirm, contradict or downgrade.

If simulated buyers repeatedly struggle to find delivery information, check whether recordings show people hunting through policy links. If a pricing change seems to create uncertainty, look at plan-selection and sales-question patterns. If the data disagrees, do not force the story. Mark the hypothesis as unsupported and move on.

At PersonaQA we designed integrations with analytics, search data and Microsoft Clarity around this principle: connected data should add context to a finding, not be used to make a causal claim it cannot support.

Prioritise by expected learning

With limited traffic, the cost of a bad test is not only a false result. It is the time spent waiting while stronger questions remain untested.

Prioritise changes where:

• the barrier appears across several customer perspectives;
• the affected journey has clear commercial value;
• the evidence names a plausible mechanism;
• the change is proportionate and reversible;
• the outcome can be observed after release.

Use qualitative and simulated evidence to improve the quality of the question. Reserve scarce experimental traffic for the questions where causal certainty is genuinely worth the cost.

CRO is the process, not the tool

CRO is not synonymous with A/B testing software. It is the disciplined process of finding barriers, forming explanations, making changes and checking whether outcomes improve.

If you have enough traffic for a well-designed experiment, use it. If you do not, use the strongest evidence available, state its limitations and keep learning. “We do not know yet” is a valid conclusion. “We cannot investigate” rarely is.

Methodology note: simulated journeys generate diagnostic hypotheses. They do not replace statistical testing or measure how all real customers will behave.