Why Your Analytics Investment Isn't Delivering Insight

Why your analytics investment isn't delivering the insight you pay for

Open a typical GA4 account and there’s a good chance BigQuery is linked but never queried. Consent mode is often still on the basic setting it was given at launch, and the server-side container, if there is one, runs on a default cloud endpoint that loses the durability it was installed for.

None of that shows up on a dashboard. So when analytics isn’t giving clear answers, the usual response is to spend more, on another dashboard, a bigger platform licence or a new tool layered over what’s already there.

That rarely closes the gap. Gartner’s 2026 survey of 401 CMOs and marketing leaders found that martech still takes 19.4% of the average marketing budget, yet 57% of those same leaders say their department lacks the talent to deliver this year’s strategy. Lack of integrated marketing data was the second most named barrier to using AI in marketing. I’d argue the tools were seldom the bottleneck in the first place.

Years of martech spending have rested on the assumption that better tools lead to better decisions, and the capability gap hasn’t closed. When analytics underperforms, it usually traces back to four causes. Teams measure the wrong things, nobody owns the data once it’s live, tools that were paid for never get properly configured, and the insight that does come through doesn’t change decisions.

Measuring what's easy instead of what matters

Most reporting defaults to whatever is easiest to pull, such as pageviews, sessions, click-through rate and time on site. They’re real and trackable, and none of them tell you whether the business is better off. Because the numbers move, they feel like progress, but they don’t tie anyone to a target.

A measurement plan fixes this before a single dashboard gets built. It makes you define what you’re trying to affect, and why, before you decide what to track.

Take a new campaign going live. The vanity-metric version asks how many people saw it and clicked through. The measurement-plan version asks what it did to revenue and the KPIs the business cares about, and builds the tracking to answer that specific question.

Nobody owns the tracking once it's live

Analytics is usually implemented once and rarely revisited. It sits between marketing, digital and IT, which in practice means it often belongs to none of them, or to whoever set it up two roles ago and left without documenting it. In a lot of businesses that’s the default. The configuration was built by someone who has since moved on, nobody currently in the building understands it, and it only gets touched when something visibly breaks.

Poor maintenance under those conditions is hard to spot. A tag stops firing or a UTM misattributes revenue, and nothing flags it as an error. The same goes for a conversion that stops mapping to the right event. It just shows up as a gap, usually mid-campaign or halfway through a board meeting, at the exact moment someone needs the data.

Training won’t fix this. A tag drifting out of alignment needs someone whose job it is to notice, and in most organisations that job doesn’t exist.

Tools switched on but rarely used to the full

Even where the tooling isn’t the problem, most organisations use a fraction of what they’ve already paid for. Three gaps come up again and again.

Consent mode left on basic – GA4’s advanced consent mode enables behavioural modelling for unconsented sessions in the interface and surfaces anonymised event-level data from those users in BigQuery. On the basic setup, GA4 still models conversions but misses that behavioural insight entirely, and most teams never revisit the setting after launch.

Server-side tagging only half done – server-side tagging is gaining ground, but most implementations stop short of what makes it worthwhile.

The first gap is the domain. To get the full benefit, the tagging server needs to run on your own mapped domain instead of a default cloud endpoint. Skip that step and you lose the security and durability benefits, falling back to JavaScript-set cookies without the persistence that server-set cookies provide.

The bigger miss is what the tag manager does with the data once it’s flowing. Set up properly, it can do three useful things:

  • Allowlist which parameters reach each tag.
  • Strip sensitive fields based on consent state.
  • Enrich events with data from elsewhere before they’re sent on.
 

Most implementations skip this. That means no enrichment to feed value-based bidding with real backend pricing, and no stripping of IP addresses from unconsented sessions before they reach a downstream vendor.

BigQuery connected but never trusted – plenty of GA4 accounts have BigQuery linked, and almost nobody queries it.

That’s a waste, because BigQuery holds the raw, event-level data with exact counts, while the standard interface applies modelling and approximation. Used properly, it gives you what the interface can’t:

  • Data kept well beyond GA4’s own retention limits.
  • Every event on higher-traffic properties, where the interface approximates.
  • The first-click, linear, time-decay and position-based attribution models that GA4 no longer offers.

Left unused, or wired up through an add-on that re-pulls the same aggregated interface numbers, it becomes a paid way to store data nobody looks at.

Insight that doesn't change decisions

Even with the right metrics, a named owner and a fully used stack, analytics only pays off if the insight changes what the business does. A report that lands without changing a plan has cost money and delivered nothing. To me, better decisions are the whole point of analytics, and reporting is only the means.

The measurement plan is where this starts. When every metric is tied to a decision before the tracking is built, it’s clear who should act when the number moves.

What to check before the next spend request

Ask to see the measurement plan as well as the dashboard – if nobody can say what business question a tool answers, that’s the real gap, and closing it costs nothing.

Ask who owns the tracking day to day – the person who built it matters less than the person accountable for it still being right next quarter.

Ask what’s already switched on but unused – consent mode settings, server-side domain mapping and BigQuery access are often already paid for and sitting idle.

Ask which decisions last quarter’s reports changed – if nobody can name one, the reports aren’t doing their job.

Fixing this doesn't need a bigger budget

None of these problems has to mean another big technology investment. Naming an owner for the tracking is a decision you can make this week, and switching consent mode to advanced, mapping a proper domain or starting to query BigQuery is configuration work on tools you already have. What it does need is someone with the time and the mandate to do it, and that’s exactly what most in-house teams are too stretched to spare.

So the question worth asking is whether that person is on your team right now, or whether the stack is still running on whatever got configured at launch. If it’s the second, our Digital Analytics team can give you an independent read on what’s configured and what it would take to trust it.

Frequently asked questions

What is a measurement plan, and why does it matter more than the dashboard itself?

A measurement plan is a short document that defines what the business is trying to affect and why, before any tracking is built. It matters as much as the dashboard because it makes sure every metric you report links back to a specific business decision.

Vanity metrics are figures that look encouraging but don’t connect to revenue, retention or other business outcomes. If a metric can’t be tied to a specific decision, it belongs in a diagnostic view rather than a decision-making one.

A server-side setup running on a default cloud endpoint, instead of a domain mapped to the business’s own site, can’t use server-set cookies and falls back to JavaScript-set cookies. That loses the extra persistence and security the migration is meant to deliver. Mapping a custom first-party domain is what gives server-side tracking the durability it’s chosen for.

Use it alongside the interface, for the questions the interface can’t answer reliably. BigQuery holds the raw data GA4 collects, while the interface applies modelling, deduplication and attribution logic on top. For ground-truth analysis BigQuery is usually the better source, and for standard business metrics that rely on that modelling the interface still has its place.

Data quality works best as a named individual’s responsibility. When it’s shared across teams with no name attached, nobody tends to revalidate it. That person doesn’t need to build every dashboard, but they should be accountable for confirming the tracking still reflects how the business runs and for flagging when it doesn’t.

Sources

Similar posts

Ready when you are

Sign up

Worried we'll send you crap? Don't. No crap. No spam. Only the best insights.

This field is for validation purposes and should be left unchanged.
Name(Required)