CRO with low traffic: what still holds up
At 2,000 visitors a month you cannot test your way to an answer, but finding what is broken never needed your traffic. The split, with the arithmetic.
"I don't have enough traffic for any of this to mean anything." It is the fairest objection in the pile, and half of it is right. At 2,000 visitors a month no test you run will settle anything. Finding what is broken never needed your traffic.
Does CRO with low traffic actually tell you anything?
Half of it does. Finding problems on a page does not use your traffic, because the evidence is the page itself. Choosing between two versions, and pricing what a fix is worth, both run on your numbers. Your numbers are thin. Those are three different jobs with three different requirements.
Which half of an audit needs your traffic?
Detection does not. Adjudication and pricing do. A reviewer reading your pricing page can see the plan names sitting above the feature list with no comparison between them, at 200 visitors a month or 200,000. Traffic buys the right to say which of two fixes wins, and what either is worth.
So the answer is not "wait until you grow". Do the part that needs no volume, and read the rest as a shortlist rather than a forecast.
The testing half really is out of reach. Seeing a 20% relative lift on a 2% rate at 80% power takes about 21,500 visitors per version, 43,000 in total, which is 21 months at 2,000 a month. Worked through in A/B testing on low traffic.
How certain is your own conversion rate at 2,000 visitors?
Less certain than your dashboard suggests. A rate measured on a small sample carries a wide band around it, and you can calculate yours in one line. At 2% on 2,000 visitors that band runs from about 1.4% to 2.6%, so the true rate could be nearly double the low end.
standard error = square root of ( rate × (1 - rate) / visitors )
- 2.0% the rate your dashboard reports, 40 sales from 2,000 visits
- 1.4% to 2.6% the 95% band around that same figure
- 27 to 52 the monthly sales that band allows at the same traffic
At an 80 euro order value those 40 sales are 3,200 euros a month, and the band allows 2,224 to 4,176. Every revenue estimate built on that baseline inherits the spread, ours included.
Not sure where your own band sits? Revslip reads the page, not your sample size.
What does the research say about judging a page instead of testing it?
Two serious sources point opposite ways, and the disagreement is the useful part. Trained reviewers find far more problems than watching users does. Controlled experiments stay the only way to settle whether a change helped. Both hold, because detecting a problem and adjudicating a fix are different measurements.
In a Springer study by Maguire and Isherwood, 32 participants split evenly across two methods evaluated an online shop and an airline booking site. Heuristic inspection surfaced 166 unique problems. User testing surfaced 36.
The counterweight sits in the same paper. On Nielsen's severity scale the problems user testing found averaged 2.02, against 1.71 for inspection. Inspection casts the wider net and ranks less reliably. Which tells you where the weak link is, and it is not detection.
Then the experimenters' side. In Seven Rules of Thumb for Web Site Experimenters, Kohavi, Deng, Longbotham and Xu show the sample a test needs is set by the metric, not only by your traffic. Revenue per user took 114,000 users per version to spot a 4.4% change. Sessions per user took 4,700 to spot 5.4%. The difference is skewness: a few large orders drag revenue around, while a session either happened or it did not. Their calming detail: successful changes at that scale typically moved key metrics 0.1% to 1.0%.
What should you fix first when the money figures are shaky?
Rank by how certain the problem is and how little the fix costs, not by the biggest number attached to it. At low volume the estimate is the least reliable column in the report. Problem severity and hours to fix are both knowable today, which makes them the better sort order.
- Certain and cheap. A button that says Submit, proof sitting below the claim it supports, a pricing page with no comparison. This week.
- Certain and expensive. A checkout that needs rebuilding. Schedule it, and do not let the estimate pick the date.
- Uncertain and cheap. Try it. Being wrong costs an afternoon.
- Uncertain and expensive. The only pile that genuinely needs a test. Park it.
Across the 134 businesses Revslip has audited, the top three items by effort against impact were rarely the ones carrying the largest modelled figure. That sample is biased: sites get audited by owners who already suspect something is wrong. Even a four-page site returns a list, and the conversion leak index explains how to rank it.
If you want the shortlist rather than the arithmetic, run an audit on your URL.
What can you still measure at this size?
Clicks, not purchases. A tagged button collects events far faster than a checkout collects orders, which is the practical version of the skewness point above. You will not reach significance on revenue, so stop trying. You can see whether people are reaching the thing you changed.
Revslip tracks click-through rate on elements you tag, comparing one variant against another on views, clicks and the rate between them. That is a click measurement, not a revenue one, and it runs no significance test for you. Treat it as evidence that attention moved, then watch sales over a longer window to see whether money followed.
Give any change two weeks before you read it, which the Kohavi paper recommends too, because the first days carry novelty. Then compare those fourteen days against the fourteen before, and write down what you expected before you look.
When is waiting for more traffic the right call?
When you are already above the testing line and choosing between two decent versions of a page. At 40,000 visitors a month an experimentation platform beats any inspection at deciding which headline wins, so buy that instead. Inspection is for when you cannot afford to wait 21 months.
Where our own number gets shakiest Revslip returns a conservative monthly range by business model, and at 2,000 visitors that range sits on a baseline carrying a band of its own. Widen it yourself before it goes near a plan, and sort the report by certainty instead.
Two other gaps. Revslip runs no session recordings and no heatmaps, so if your question is what one visitor did on one page, buy Microsoft Clarity, which is free. It runs no moderated usability testing either, and the Maguire severity result is why that matters. Five real people, watched for twenty minutes, is the cheapest correction to any inspection, ours included.
Questions founders ask when the traffic is small
Two come up more than the rest: whether it is too early to look at the page at all, and whether traffic should come first. Neither answer depends on your volume, which is the pattern running through the whole question.
Is it too early to bother with any of this?
No, and the arithmetic cuts the other way. A page that loses eight in ten visitors loses them at 500 a month and at 50,000. Fixing it early means you are not paying to push traffic through a broken page later. Start with what you can check yourself.
Should I get more traffic first?
Only if the page already converts at a rate you would be happy to scale. Otherwise you are buying visitors for a page that cannot hold them. Compare the cost of the next thousand visitors against the cost of the fix. At these volumes the fix usually wins.