A month-by-month plan for your first 90 days of conversion rate optimisation: what to research, how to rank ideas, how to run fair tests and what to do with low traffic.
Conversion rate optimisation (CRO) means raising the share of your visitors who do what you want: buy, enquire or book a call. Many businesses take it to mean running a few A/B tests, in which two versions of a page are shown to comparable visitors to see which performs better. The tests produce the odd winner, nobody records why it won, and after a few months the effort quietly stops.
A CRO programme works differently: it is a research-led routine in which every change starts from evidence and every test teaches you something that shapes the next one. To build one in 90 days, spend the first month on research, the second turning findings into ranked ideas and fixing what is plainly broken, and the third running your first tests with a log that records what each one taught you.
The payoff builds up over time, and it comes without extra ad spend. As an illustration, a shop with 40,000 visits a month and a 2% conversion rate makes 800 sales; at 2.4% it makes 960 from the same traffic. Below is what each month should involve, what it should produce, and what to do if your traffic is too low for classic tests.
The first month should produce no tests. It should produce a short research report that explains where visitors drop out and why. Without it you end up testing generic best-practice ideas, which rarely address the specific reasons your customers hesitate.
Start by agreeing one main goal, such as completed orders, booked calls or qualified enquiries, and record the current conversion rate at each step towards it. Without that baseline you cannot tell later whether anything worked. Then gather evidence from several directions.
Recording and survey tools must respect your cookie consent, and they should be set to hide what people type into forms, so you do not collect personal data you do not need. Configure them through your consent banner before you start.
Fix, rather than test, anything plainly broken. A form that fails in one browser, a checkout that hides delivery costs until the last step, or a page that takes eight seconds to load on a phone should be repaired straight away. Testing a known fault only delays the fix.
A good hypothesis links a change to evidence: 'We believe that changing [element] for [audience] will improve [metric], because [research finding].' For example, 'We believe that showing delivery costs on product pages for mobile visitors will increase checkout starts, because interviewees mentioned surprise delivery costs and recordings show people scrolling to the footer to find them.' If you cannot fill in the 'because', you have an opinion, not a hypothesis.
Rank your hypotheses so the strongest run first. A common method is ICE scoring: rate each idea from 1 to 10 for impact (how much it could move the goal), confidence (how strong the evidence is) and ease (how quickly you can build it), then take the average. The scores are subjective, so tie confidence to your research, giving an idea backed by interviews, recordings and analytics a higher score than one backed by a hunch.
Sort ideas into three groups as you go: fixes to make immediately, questions that need more research, and genuine tests for your backlog. Start testing on pages with high traffic and clear signs of friction. They produce results fastest and build trust in the programme inside the business.
The setup is simpler than many teams assume. You need a testing tool (VWO and AB Tasty are established options; Google's free testing tool has been discontinued, so older guides that recommend it are out of date), one main metric per test, a sample size calculator to fix each test's length in advance, and a results log. A few rules then keep the results trustworthy.
A realistic first 90 days produces a research report, a ranked backlog for the next six to twelve months, several fixes already live and a handful of completed tests. Do not judge the programme on whether the first test wins. Many well-run tests end without a clear difference, and knowing that a change does not matter to your customers is useful too.
Classic A/B testing needs volume. As a rough guide, you need a few hundred conversions per version during the test to detect an improvement of 20–30%. A shop with 500 sales a month, split between two versions, can detect an improvement of about a quarter within a month and about a fifth within two.
A business with 40 enquiries a month is in a different position. Even a three-month test would reveal only changes of around 60% or more, so small tweaks cannot be tested at all. That is common for firms selling to other businesses and for specialist shops, and it is not a reason to give up.
Low traffic changes the method, not the goal. Make bigger, research-backed changes, measure them before and after over comparable periods, and lean harder on interviews, recordings and sales feedback. You can also test earlier steps that have more volume, such as clicks on a key button or form starts, as long as you later confirm the effect on completed conversions.
Record every test and every measured change: the hypothesis, the evidence behind it, the dates, the result, how confident you are and, above all, what it taught you about your customers. A winner without a recorded reason is a one-off improvement. A recorded reason can shape your ads, emails and sales conversations as well as your website.
Review the log monthly with whoever looks after the website and whoever looks after marketing. Patterns appear over time: perhaps your buyers respond strongly to delivery certainty, or ignore discounts but react to guarantees. Those patterns make each new hypothesis better than the last.
Give the programme one owner, a few days of design and development time each month and a fixed review date. Without an owner, CRO slips behind every urgent task.
A/B testing is an experiment; CRO is a programme, and the difference is the knowledge that builds up from one test to the next.