Analytics and conversion optimisation

Why most tracking is broken, and how to tell

Almost every account we open has at least one measurement fault, and the business has been making decisions on the output for months. The faults are rarely exotic. A tag installed twice so every session is counted twice. A conversion firing on a thank-you page that also fires on refresh. Internal traffic never excluded. A form that reports a submission before the server has accepted it.

The reason it goes unnoticed is that broken analytics still produce charts. Nothing errors. The line goes up and down plausibly, and nobody has an independent number to compare it with. That is the tell: if the analytics figure has never been reconciled against your CRM, your order system or your inbox, assume it is wrong until checked.

The quickest checks are the crude ones. Submit your own form and see whether exactly one conversion appears. Compare last month enquiries in analytics with actual enquiries received. Look for a bounce rate that is implausibly low, which usually means double tagging. Look for traffic from your own office.

• Reconcile conversions against the system that receives them, monthly
• Test every form and call to action yourself after any site change
• Exclude internal and agency traffic, and check the exclusion still works
• Watch for suspiciously low bounce rates or doubled session counts
• Confirm that consent settings are not silently dropping most of your data

Designing events that answer questions

Event tracking goes wrong when it is built from what is easy to track rather than from what someone needs to know. The result is hundreds of events nobody looks at and the one number the business cares about missing. Start from the questions instead. Which pages produce enquiries. Where do people abandon the quote form. Which service pages lead to booked calls.

Then define a small, consistent set of events that answer those questions, with a naming convention agreed before anyone builds anything. Consistency matters more than cleverness, because inconsistent naming makes reporting impossible later and renaming after the fact does not fix historic data.

Distinguish the events that represent business value from the ones that represent behaviour. A form submission is value. A video play is behaviour. Mark only the genuinely valuable ones as conversions, because every optimisation and bidding decision downstream will treat them as the goal. Marking twelve things as conversions means you have no goal.

• Write the questions first, then the events that answer them
• Agree naming conventions before implementation, and document them
• Keep one primary conversion, with supporting events recorded but not optimised towards
• Attach the parameters you will actually segment by, and no more

Why measurement signal degrades, and the honest response

Measurement is less complete than it used to be, but the reasons are often misstated. Google kept third-party cookies in Chrome and retired most of the Privacy Sandbox proposals, so the change everyone planned for did not happen in the way it was described. What is actually eroding signal is simpler and already in effect.

Ad blockers stop tags loading at all for a share of visitors. Browser tracking prevention shortens the life of cookies set by scripts, so returning visitors get counted as new. Consent requirements mean a portion of visitors decline measurement outright, and that portion is not random. Cross-device journeys were never fully visible in the first place.

The honest response is to improve the quality of what you can measure rather than to chase completeness. First-party data collected with consent. Server-side measurement where it is set up properly. Conversion values sent back from your own systems rather than inferred in the browser. And a working assumption that reported numbers understate reality, so trends and relative comparisons are more trustworthy than absolute totals.

• Blockers, browser tracking prevention and consent choices are the real causes
• Prefer first-party and server-side collection over more browser tags
• Send business outcomes back from your CRM or order system where you can
• Compare periods and channels against each other, not against a fictional complete total

Research before testing: the discipline that separates CRO from guessing

Conversion optimisation done badly is a queue of opinions dressed as tests. Someone suggests a green button, it gets tested, it does nothing, and the programme loses credibility. The problem is not the test, it is that nobody established why visitors were leaving before proposing a fix.

Research means combining sources that each show a different part of the picture. Analytics shows where people drop out. Session recordings and heatmaps show what they did just before. Surveys and exit prompts capture what they were trying to do. Sales and support conversations reveal the objections that never make it into a form. User testing shows you a stranger failing at something you thought was obvious.

From that you write hypotheses with a reason attached. Not we should try a shorter form, but visitors abandon the quote form at the phone number field and support says people are wary of being cold called, so removing the phone requirement should increase completions. That version can be tested, and whichever way it goes you learn something.

• Analytics for where, recordings for what, surveys and sales calls for why
• One hypothesis, one reason, one predicted outcome
• Prioritise by expected impact and effort, and be honest about both
• Keep a log of every test and result, including the failures

How long a test really needs, and why traffic gates it

A test needs enough conversions, not enough days, and the two get confused constantly. The number required depends on your current conversion rate and how large a difference you want to be able to detect. Small improvements need far more data than large ones, which is why detecting a small lift on a low-traffic site can be practically impossible.

Calculate the required sample before starting, then run until you reach it. Stopping the moment a result looks significant is the most common error in testing, and it reliably produces false winners, because random variation crosses the threshold regularly on its way to settling down. Peeking is fine. Stopping on a peek is not.

Run for whole weeks, at least two and usually more, so weekday and weekend behaviour are both represented. Avoid running through an unusual period such as a sale or a holiday, or accept that the result only applies to periods like that. And know when to stop testing altogether: if you cannot reach a decent sample in a month, run research-led improvements instead and measure the before and after honestly, rather than pretending an underpowered test told you something.

• Decide the sample size and the minimum effect worth detecting before launch
• Run in whole weeks, and at least two of them
• Do not stop early because the result looks good
• Below roughly a few hundred conversions a month, prefer research-led changes to formal testing

Reading results honestly

Most tests do not produce a winner, and that is normal rather than a failure of the programme. A flat result is still information: it tells you that the thing you changed was not what was holding people back, which redirects the next round of research. Teams that only report winners end up with a distorted view of what works.

Watch for the traps. Segmenting the results after the fact until some subgroup looks significant will always find something, and it is almost always noise. A lift in clicks with no lift in revenue is not a win. A win that only appears in one browser usually means something broke in the others. And a result that reverses when repeated was never real.

Finally, connect results to money before declaring victory. A higher form completion rate that fills the pipeline with unqualified enquiries costs the sales team more than it earns. The measure that matters is qualified outcomes, which means the test result should be checked against the CRM a month later, not just against the analytics dashboard on the day.

• Report flat and losing tests as openly as winners
• Treat after-the-fact segment findings as hypotheses, not results
• Check the downstream metric, not just the immediate click
• Re-check the win in the CRM once the leads have had time to qualify

Reporting that people actually use

A report that nobody reads is a cost with no return, and most reports fail for the same reason: they show everything the tool can produce instead of the few things the business acts on. A useful report answers three questions. What happened, why it happened, and what we are doing next.

Build the dashboard around outcomes rather than platform metrics. Enquiries and revenue at the top, with the channel breakdown beneath, and the diagnostic detail available for anyone who wants it rather than pushed at everyone. Add comparison to the previous period and to the same period last year, because a single number in isolation cannot be judged.

Then write the two sentences the dashboard cannot. Numbers do not explain themselves, and the value of a good analyst is in the interpretation, not in the chart. Automated dashboards are for monitoring. A short written commentary each month is what turns monitoring into decisions.