Set a Baseline Before You Change Anything

Before you change anything, record how the site performs now: sessions, orders and conversion rate for the last 60 to 90 days, split by device (mobile, desktop, tablet) and by broad traffic source (search, social, email, direct, paid). Save it somewhere it cannot be quietly edited later - a dated export or a screenshot in your change log. Every change you make from then on is judged against this picture. Skip the baseline and you will never know whether a change worked; you will only know that the number is different, which is not the same thing.

A blended baseline is nearly useless because traffic mix moves. Illustration: your store converts desktop at 2.4 percent and mobile at 0.9 percent. If a social campaign doubles mobile's share of traffic, your blended rate falls even though both device rates held perfectly steady. Owners without device baselines redesign pages in response to what is actually a marketing event. Owners with them ask the right question first: did any segment's own rate move, or only the mix? That single question prevents most wasted CRO work.

For each segment write down: sessions, orders, conversion rate, and revenue per session if your platform shows it. Add the funnel step rates your tools expose - add-to-cart rate and checkout completion rate at minimum. Note anything unusual inside the window: promotions, stock-outs, a press mention, an outage, a price change. Those notes are what let you interpret the baseline later instead of arguing with it. Date the file and store it with the change log. Fifteen minutes of capture saves hours of later confusion.

Ninety days smooths weekly lumps and most small promotions; sixty is acceptable when ninety includes a genuinely different season - a Christmas-heavy quarter is a poor baseline for spring trading. Avoid windows containing a site migration, a theme change or a pricing overhaul: the baseline must describe the site you are about to change, not its ancestor. If the honest answer is that recent history is all disruption, take the cleanest recent 30 days and label the baseline provisional.

Every change entry in your log gets judged against the baseline segment it aimed at: a mobile checkout fix is read on mobile checkout completion, not on the blended store rate. After a change has run long enough - the guide on judging a change covers the timing - compare like with like: same segment, similar period shape, promotions noted. Update the baseline quarterly, or after a change you have decided to keep permanently resets what normal means.

The classic mistakes: taking the baseline after the change (no before-picture exists, and memory supplies a flattering one); cherry-picking the best historical month as the comparison; and letting the baseline quietly absorb a problem - a broken discount code week - as if it were normal performance. A baseline is evidence. Treat it the way you would treat a bank statement: dated, complete, and never improved in the telling.

Sometimes history is unusable: the store is new, the analytics were installed last week, or last quarter contained a migration and a sale. Take the best available window anyway - even 30 recent days - and mark the baseline provisional in the log, with the reason. A provisional baseline still disciplines the work: it forces segment splits, it exists before the change rather than after, and it can be replaced by a firmer one next quarter without invalidating the habit. What you must not do is postpone all measurement until perfect data arrives. Perfect data is not coming; a dated, honestly labelled approximation beats an immaculate intention, every quarter of the year.