Numbers nobody trusts
Three tools report three different figures for the same month. Consent was bolted on, so a chunk of traffic is invisible in a way nobody has quantified. Event names were invented ad hoc, so nothing aggregates. Everyone quietly picks the number that supports their case.
One schema, agreed once
We start with a written measurement plan: what an event is, what it is called, what travels with it. Then we implement it once, in GTM or server-side where it belongs, with consent handled properly rather than as a banner over the top. The dashboard that comes out is short, agreed in advance, and reconciles with the CRM.
What you get
Included as standard
- GA4 and Google Tag Manager implementation or repair
- Server-side tagging and consent mode done properly
- A written event schema, so names stay consistent
- Attribution models chosen for your sales cycle, not the default
- Looker Studio dashboards with agreed definitions on the page
The chain
How the pieces connect
- User action
- dataLayer event
- Web container
- Server container
- GA4 and CRM
- Dashboard
The measurement plan comes before the tag
Almost every broken analytics setup we are asked to repair was built tag first. Someone needed a conversion number, so a tag went in. Then a campaign needed a different number, so another tag went in beside it. Two years later there are forty tags, six of which fire on the same action under different names, and no document anywhere says what any of them mean.
A measurement plan is a short document, not a project. It lists the events that matter, the exact name of each one, the parameters that travel with it, and the business question each event exists to answer. If an event cannot be traced to a question someone actually asks, it does not go in. That constraint alone removes most of the noise.
Naming is the part that pays off later. Consistent event names aggregate; inconsistent ones do not, and no amount of reporting effort afterwards recovers the difference. Deciding once that a purchase is called "purchase" everywhere, rather than "purchase", "order_complete" and "txn", is worth more than any individual tag.
Server-side tagging, and what it does not fix
Server-side tagging is genuinely useful and it is oversold. What it actually does is move tag execution off the browser and onto a container you control, which means the browser makes fewer third-party requests, page performance improves, and you get a single place to shape and validate data before it reaches any vendor.
What it does not do is restore data you lost to consent refusals. A visitor who declined analytics has declined analytics, and routing the request through your own domain does not change that, nor should anyone sell it to you as though it does. It also does not eliminate ad blockers entirely, because blocking increasingly works on patterns rather than hostnames.
It also has real costs that should be stated up front: a server container needs hosting, which is a running expense; it needs a subdomain and DNS configuration; and it adds a component to your stack that can fail independently. For a business with meaningful ad spend and a real attribution problem, it pays for itself comfortably. For a site with modest traffic and no paid acquisition, it is usually not yet the right spend, and we will tell you that.
Consent mode changes your numbers, and that is correct
Implementing consent properly makes reported numbers go down. This is the single most common reason it gets quietly deferred, and it is worth naming directly: the previous number was not more accurate, it was collected without permission.
Consent Mode v2 with denied defaults means no analytics or advertising storage is written until a visitor accepts. Tags still load and send a cookieless signal, so you retain a count of page views, and Google uses those signals to model the gap. The modelling is genuinely useful at volume and genuinely unreliable at low volume, which is a distinction worth understanding before you build a board report on top of it.
The implementation detail that most often goes wrong is ordering. The consent default call has to execute before any tag loads, not after, and a banner bolted on top of an existing setup usually fires too late to be doing anything at all. That failure is invisible in the interface and obvious in the network tab, which is where we check it.
A dashboard is a contract about definitions
Most dashboard disputes are not about numbers. They are about whether a "lead" means a form submission, a marketing qualified contact, or a contact sales agreed to call, and about whether revenue is booked at order or at fulfilment.
So the useful dashboard is short and carries its definitions on the page. Six numbers everyone has agreed on beats forty nobody trusts, and putting the definition next to the figure ends the recurring meeting where two people discover they were describing different things.
The other rule we hold to is that the dashboard must reconcile with something outside analytics. Revenue should tie to what finance sees. Lead counts should tie to CRM record counts. A dashboard that only agrees with itself is a dashboard that tells you nothing when it starts to drift.
Before you ask
Questions we get
Our GA4 revenue does not match the shop platform. What is usually wrong?
In our experience the usual suspects are a small set: the purchase event firing twice because the confirmation page reloads or the customer refreshes, refunds never being sent back so revenue only ever goes up, currency or tax handled differently in the two systems, and consent removing a slice of traffic that nobody has quantified. The diagnosis is normally quick. It is worth knowing that the two numbers will never match exactly, and the goal is a small, explained gap rather than a perfect one.
Will server-side tracking recover the data we are losing?
Some of it, not all, and anyone promising all of it is selling something. It reliably improves data quality and page performance, and it gives you control over what leaves your site. It does not recover data from visitors who declined consent, and it is not a complete answer to ad blocking.
Does a server container cost extra to run?
Yes, and it is a running cost rather than a one-off. It needs hosting and a subdomain. Whether that is worth it depends mostly on your ad spend: if you are optimising campaigns against the data, the improvement usually pays for itself quickly. If you are not, it often is not the right spend yet.
Is consent mode going to destroy our numbers?
It will reduce them, and the reduction is the correct figure rather than a loss. What we can do is make sure the drop is understood, dated and explained in the reporting, so nobody spends a quarter hunting for a traffic problem that is actually a consent implementation.
Can you fix what we have rather than rebuilding it?
Usually, and it is normally the cheaper path. We start with an audit of what currently fires, which often finds duplicate tags and orphaned events that can simply be removed. A rebuild is only worth it when the event naming is so inconsistent that nothing aggregates, and we will show you the evidence for that rather than asserting it.
Scope, plainly
What this is not
Worth saying before you write, so nobody wastes a fortnight finding out.
- Media buying or campaign management. We build the measurement; someone else spends the budget.
- Legal advice on data protection. We implement consent correctly and document it; your adviser confirms your obligations.
- Vanity dashboards. If a metric has no decision attached to it, we will argue for leaving it out.
Rarely done alone
What this usually comes with
- Ecommerce and shop backends Most revenue reconciliation problems start in the order data, not the analytics.
- CRM integration Attribution has to land on a clean CRM record or it reports nothing useful.
- Campaigns and automation Scoring and lifecycle flows depend on the event schema defined here.
Also on the chain
Nothing here works alone
Every one of these connects to the others. That is the point of the way we work.
Start with the gap
Tell us where the chain breaks.
One reply from the person who would do the work, not a sales desk.
Tell us about itor write straight to hello@dot-connectors.net