The digital analytics team at this international company had noticed something that didn't quite add up. Their paid acquisition campaigns were generating strong click volumes according to ad platform reports, yet Google Analytics was capturing a fraction of those visits as page views. The gap was too wide to be explained by the usual suspects — bot traffic, ad fraud, attribution windows. Something else was happening.
The team was diligent. They'd been running digital analytics for years, had a mature tagging setup, and relied on a well-established consent management workflow. This wasn't a team that overlooked things easily. And yet, every time they looked at campaign landing pages, the numbers just didn't reconcile.
"We kept going back to the same question: where are these sessions going? The ad platforms said the clicks happened. Analytics said most of them never did. The gap was right there in front of us — we just couldn't explain it.”
The discrepancy was significant enough to distort how the team evaluated campaign performance, how budgets were allocated, and how conversion rates were reported to the wider business. The numbers were clearly wrong. Finding out what was causing them to be wrong was a different challenge entirely.
Once the Page Load to page view gap was confirmed, the Trackingplan support team moved quickly. The investigation became a collaborative effort, with Trackingplan's team working closely alongside the customer to understand what was causing the drop and where to look next.
"Trackingplan's team was all in from the beginning. They structured the investigation clearly, ruled out every other explanation one by one, and kept pushing until they found the real answer. It felt like having an extension of our own team working on it."
Rather than jumping to conclusions, they worked through the problem systematically, evaluating four distinct hypotheses:
Could it be consent? Consent rates for paid landing page sessions were lower than for organic traffic — but not nearly low enough to account for the scale of the gap. Consent explained part of the story, not most of it.
Could the ad platforms be overcounting? Page Load data — captured at the moment a session begins, before any consent or tag dependency — showed that real session volumes from paid campaigns broadly matched what the ad platforms were reporting. The clicks were real.
Could Google Analytics itself be undercounting? Trackingplan's own event capture, which operates independently of the analytics implementation, corroborated GA's numbers. The platform wasn't the problem.
Were events simply not firing before users left? Everything pointed to the same explanation: users were leaving before the events had time to fire. Once the team could verify the entire tracking flow, the hypothesis was confirmed almost immediately.
What made the fourth hypothesis so conclusive was a dimension the team hadn't been able to measure before: the relationship between when events fired and when users actually left.
Trackingplan's analysis revealed two distributions that, when placed side by side, told the whole story.
The first was how long users were spending on paid landing pages. Users arriving via paid campaigns make fast decisions — they either find what they need immediately or they leave. Median session duration for this cohort was just a matter of seconds.
The second was when the page view event was actually firing — and across both paid and organic sessions, that timing was broadly similar, but far too late for short-session traffic.
For organic traffic, this hadn't been a visible problem. Those sessions were long enough that even a delayed page view event would fire before the user left. The data looked reasonable, so nobody raised a flag.
For paid traffic, the same delay was catastrophic. The median user was leaving the page before the tag management container had even finished loading — let alone before a page view could fire. More than half of paid sessions ended before the tracking stack had reached the point of capturing them.
"The page view event was firing at around the same time for both paid and organic sessions. The difference was that organic users stayed long enough for it to matter. For paid sessions, by the time the event triggered, most of those users had already gone, as if they'd never been on the page at all.”
The consent layer compounded things further. Because the consent banner was itself controlled by the tag management container, users who arrived and left quickly had never even seen the consent prompt. The low consent rate that had initially seemed like a possible explanation turned out to be a downstream symptom of the same root problem.
With the timing gap confirmed, the investigation turned to why the tag management container was initialising so late. This is where the Trackingplan team went beyond the platform and did the debugging work directly — digging into the site's architecture on the customer's behalf to find the answer.
What they found was a structural issue rooted in how the site had been built. The site used a modern JavaScript framework with server-side rendering. The server rendered the initial HTML quickly — performance metrics looked healthy — but the framework's client-side hydration process, which brings the interactive application layer to life in the browser, was happening afterwards. And the tag management container had been embedded inside that hydration flow.
This meant the tag container was not loading as an independent, asynchronous script in the document head — as every tag management vendor explicitly recommends. Instead, it was loading at the end of a long JavaScript execution chain: after the framework had initialised its routing module, application shell, runtime scheduler, and hundreds of other chunks covering UI components, third-party widgets, search, chat, and content modules.
By design, the framework's hydration process is lazy-loaded — it isn't needed for the initial render, so it carries no execution priority. The tag management container was buried at the bottom of that chain — loading after all of it and inheriting the same low priority.
"Once we understood the architecture, it was almost obvious in retrospect. The tag manager was being treated like just another part of the application. The script was buried so deep in the page that it simply had no chance of firing in time for short sessions."
The fix was exactly what the vendor's own documentation recommends: move the container script in the <head> of the document, independently of any framework lifecycle. The script loads asynchronously, so it has no effect on rendering performance. The computationally expensive part — loading third-party pixels and tags — only happens after consent is given. Moving the container to the <head> doesn't front-load that cost; it simply ensures the infrastructure is ready before users have a chance to leave.
The development team made the change, and the results were immediate. Page view capture rates on paid landing pages improved dramatically. The gap between ad platform click volumes and analytics page views narrowed to a range that could be fully accounted for by consent rates and normal attribution differences — both expected and explainable.
Campaign performance data that had been systematically understated now reflected reality, so budget decisions made on distorted data could be revisited with accurate inputs.
"The fix itself was straightforward once we knew what to do. What took time was getting the visibility to understand the problem clearly. Once we had that, the path forward was obvious."
Moreover, beyond the immediate improvement in data capture, the team came away from this experience with a fundamentally different understanding of how implementation errors can hide.
The team has also continued using Trackingplan's event coverage and timing analysis as a standing operational health check — not a diagnostic tool deployed only when something seems wrong, but a continuous layer of visibility that makes this class of implementation error impossible to miss.
The most instructive part of this case isn't the fix. It's what made the root cause so difficult to find.
The gap in the numbers was visible from the start. But knowing that page views were dramatically under-reported in paid sessions didn't explain the mechanism. The natural first assumptions — a configuration error, a consent problem, a platform discrepancy — all showed up clean in standard tooling.
The ability to see not just what events fired but when — relative to actual session duration, segmented by traffic type — turned a frustrating data quality mystery into a diagnosable, fixable architectural issue.
"You can have a perfectly implemented tag, in the right place, firing the right event — and still lose most of your data. If the timing is wrong relative to how real users behave on your specific traffic mix, it is operationally invisible until something makes you look at it differently.”
For this company, that something was Trackingplan. The gap was obvious. The cause was not. And closing that distance — between knowing something is wrong and understanding why — required both the right monitoring infrastructure and a team that stayed with the investigation until the answer was found.
This customer story has been extracted from one or more real customer interactions. Names and other related data have been anonymized for privacy reasons.
Interested in understanding how your tracking performs under real user behaviour — not just QA conditions? Book a demo with Trackingplan.
