Troubleshooting Google Analytics 4 Implementation in GTM: A Kentico Case Study
When Google Analytics 4 Mysteriously Disappears: A GTM Detective Story
Our Google Analytics tag (implemented via Google Tag Manager) only functions correctly when a seemingly unrelated custom HTML tag (temp_ga4) containing a basic gtag.js implementation is present. Disabling or removing temp_ga4 causes the GA tag to stop firing, preventing data collection.
Observations:
The temp_ga4 tag is a standard gtag.js setup, triggering on window load. Its code should have no bearing on other tags.
This strongly points to an underlying website code conflict or dependency that's being unintentionally resolved by the presence of temp_ga4.
Recently, I encountered an intriguing analytics implementation puzzle on a Kentico-powered website. The symptoms were peculiar: the Google Analytics 4 tracking would initially load but then mysteriously vanish, leaving gaps in our data collection. What made this particularly interesting was that the Google Tag Manager container appeared to be working correctly, yet the GA4 tracking would consistently fail.
Tag Manager would fire the tag, but when you looked at the actual GA4 no tags would actually fire. Very strange because the GTM was firing on the correct trigger. One strange thing was that container loaded was missing.
The Plot Thickens
The first clue came from my debugging efforts. I observed that the essential ‘gtag' function (Google's tracking function) would exist briefly after page load but then disappear entirely. This behaviour occurred despite having a seemingly correct GTM implementation. Curiously, when I added a basic GA4 tag, with a different stream ID, using custom HTML on window loaded, everything worked perfectly – but why? It's a totally unrelated tag here with a different stream ID, so it really should not have made any difference.
The Discovery
Through systematic querying of LLMs, testing and a bit of Googling, I discovered that the issue wasn't with GA4 or GTM itself, but rather with how the tracking code was being maintained on the page. The default GTM implementation wasn't protecting the tracking function from being overwritten during the page's JavaScript execution cycle.
The Solution
We implemented a more robust version of the tracking code that:
- Established a persistent gtag function
- Protected it from being overwritten
- Maintained all standard tracking capabilities
<script>
(function() {
// Ensure gtag persists
window.dataLayer = window.dataLayer || [];
if (!window.gtag) {
window.gtag = function() {
window.dataLayer.push(arguments);
};
// Make gtag non-configurable to prevent overwriting
Object.defineProperty(window, 'gtag', {
value: window.gtag,
writable: false,
configurable: false
});
}
gtag('js', new Date());
})();
</script>The fix was elegantly simple: I added a custom HTML tag in GTM that initialised the tracking code in a more durable way, ensuring it remained active throughout the page lifecycle. In other words, I just added that code at the initialisation stage and that fixed it.
Key Learnings
This case highlights an important lesson in web analytics implementation: sometimes the standard approach needs adaptation to work within specific content management systems and website architectures. While GTM's default implementation works for most scenarios, certain technical environments may require a more tailored approach.
For developers and analysts facing similar issues, maybe not specific in Kentico environments, I recommend:
- Monitoring the persistence of tracking functions
- Using GTM's debug mode to observe tag behaviour
- Considering custom initialisation methods when standard implementations fail
The Takeaway
What initially appeared as a mysterious analytics failure turned out to be a valuable lesson in the importance of understanding how tracking code interacts with the broader website environment. By taking a methodical approach to troubleshooting and being willing to look beyond standard implementations, we were able to restore reliable analytics tracking without having to resort to dummy tags to trick the system.
Notes.
The container load event just never happened, so it went consent initialization, initialization, DOM ready, window loaded. After the fixed, the container loaded event. loaded just fine
Trigger groups didn't work.
Click triggers didn't work either
Cookie consent was looked at but the onetrust/ cookie pro was a red herring. Cookie consent and site scanning had nothing to do with the issue but the issue did stop onetrust scanning the site properly.
No errors in the console. Sometimes the website's Content Security Policy (CSP) interferes with tags.
Ben has a BEng (Hons) in Computer Science and 20 years of experience in online marketing, specialising in SEO, lead generation and affiliate marketing. After spending over a decade as an igaming affiliate, he has decided to concentrate on GA4 training and SEO Audits.
