Analytics setup you can finally trust

Why most analytics accounts are quietly wrong

Most of the accounts we open have never been configured. They were created, a tag was pasted into the site, and everything since has run on defaults. The reports fill with numbers, the numbers look plausible, and nobody finds the problem until two systems are compared and disagree by a wide margin.

The most common faults are dull and expensive. Key events never marked, so the platform is optimising against nothing. Thank-you pages counted on every reload, so one enquiry reports as three. Internal and agency traffic never filtered, so your own team inflates engagement on the pages they work on most. Cross-domain tracking missing, so a visitor moving to a booking or checkout subdomain arrives as a brand new direct visit and the original source is lost.

Automatically collected interactions cause a subtler problem. Modern analytics records scrolls, outbound clicks, file downloads and video engagement by default, which is useful, but it also means a page can look engaged when nobody did anything meaningful. Without deliberately defined events for the actions that matter to your business, you get activity data rather than outcome data.

• Key events not marked, so no conversion exists to optimise against
• Confirmation pages counted on reload and on repeat visits
• Internal, agency and bot traffic never excluded
• Cross-domain journeys broken, attributing conversions to direct
• Forms tracked by page view rather than by actual submission

Events, parameters and the model underneath

Current analytics platforms are event-based rather than session-based. Everything is an event with parameters attached, including page views. Once that lands, configuration gets clearer: you are not choosing which pages to track, you are deciding which actions matter and what detail each should carry.

The detail is where the value sits. An event recording that a form was submitted is worth little. The same event carrying which form, which page, which service was selected and which enquiry type was chosen lets you answer real questions about which pages and services generate business.

Naming discipline is what keeps this usable. Events named inconsistently across a site produce reports nobody can read six months later, and there is no clean way to repair historic data after the fact. We agree a naming convention before implementation and write it down, because this is the part that breaks quietly when a new developer or agency starts adding tags.

Duplicates, attribution and why two systems never agree

Analytics and ad platforms will never match exactly, and expecting them to wastes a lot of meeting time. They count different things. An ad platform typically credits a conversion to the click that preceded it within its own attribution window, and may include view-through activity. Your analytics platform uses its own model across all sources. Both can be correct and still differ substantially.

What matters is that each is internally consistent and that everyone knows which number is the source of truth for which decision. We document that explicitly. Ad platform numbers steer bidding, because that is what the platform optimises on. Analytics numbers steer channel comparison. Your own sales or CRM records settle revenue.

Duplicates are a genuine fault rather than a modelling difference, and they are common. The usual causes are a tag installed both directly and through a tag manager, a confirmation page reachable more than once, and a single-page application firing on route changes as well as on load. Each one inflates results, and inflated conversion data actively degrades ad platform performance, because the platform learns from it.

Consent, and what it does to your numbers

Consent handling is not only a legal requirement, it changes what your reports contain. When a visitor declines tracking, a properly configured setup stops setting identifying cookies but still sends anonymous signals, which the platform uses to model the gap. Configured badly, you either lose the visitor entirely or you collect data you were not permitted to collect.

This has a consequence people find surprising: after a consent banner is introduced or changed, reported conversions usually move. That is not a tracking fault, it is measurement now reflecting consent. Recording the date of any consent change alongside your reports prevents a lot of confusion later.

We configure consent so choices are respected at the point of collection rather than filtered afterwards, and we test the declined path as carefully as the accepted one. It is routinely the untested case, and it is the one carrying the legal exposure.

What a measurement plan contains, and why it outlives the setup

The deliverable is not a configured account. It is a written measurement plan, because the account will be edited by other people and the reasoning has to survive that.

It records what the business wants to know, which events answer those questions, what parameters each event carries, where each is triggered, how it was verified, and which reports depend on it. When someone later asks why a number moved, that document turns a week of investigation into a ten minute check.

It also makes handover possible. If we stop working together, or you bring in another supplier, they inherit a documented setup rather than an undocumented one. We think that is the right way to build measurement, and it removes the quiet dependency that makes analytics work hard to leave.

• The questions the business needs answered, written first
• Event and parameter specification, with naming conventions
• Trigger conditions and where each fires
• Verification evidence for every conversion path, desktop and mobile
• Which number is authoritative for which decision