If you have enabled Google Tag Gateway on your website, or are considering doing so, this guide explains a frequently overlooked side effect in simple terms: GTG can change when Google tags are loaded, causing them to load before the consent banner. When this happens, consent arrives "late" and compliance may be affected.
The good news is that this is a technical issue, which means it can be monitored and managed. Here you will find what happens, how to detect it, and how to resolve it. For more technical details, please refer to Google's official documentation linked at the end of this article.
Google Tag Gateway (GTG) is a Google feature that serves tags, such as Google Analytics 4 and Google Ads, from your own domain instead of Google's servers.
In practice, tags are normally downloaded from a Google address such as googletagmanager.com. With GTG enabled, the same tags are served through a path on your own website, for example yourdomain.com/metrics. The goal is to reduce the impact of ad blockers and recover more measurement data.
GTG can be enabled in three ways: through a one click integration with a CDN such as Cloudflare, through Google Cloud Load Balancer, or through a manual configuration.
GTG does not change what the tag does. It changes where it comes from, and for consent management, that difference matters.
The compliance rule is simple: consent must be established before tags are allowed to run. Your Consent Management Platform must load and set the default consent values through Consent Mode before any Google tag executes.
Without GTG, this order is generally predictable: the consent banner loads first, sets the default consent values, and the tags follow the user's choice.
With GTG, especially when enabled through a one click CDN integration, things can change. Because the tags are served from your own domain, they may load faster, sometimes before the consent banner has had a chance to set the default values. The CDN-based one click setup can also inject scripts upstream, without giving you control over where they appear in the page code. As a result, you lose control over the loading sequence precisely where that sequence matters most.
The result is that a Google tag may execute before it knows the user's consent status. This is what diagnostic tools report as a late consent signal: the tag reads the consent state before a default value has been established. From a GDPR perspective, this is a real concern because data collection itself is considered processing and therefore requires a legal basis, namely consent, before it begins.
Late consent applies to both consent-signalling layers, not only to Consent Mode. It occurs when either the Consent Mode default command (gtag('consent', 'default', ...)) or the IAB TCF stub (the __tcfapi function that the CMP must expose before anything else) loads after the Google tags have already fired. In both cases the tag runs before a valid consent state exists, and the signal is recorded as late.
The one click setup is convenient because it asks for nothing. Unfortunately, what it does not ask for is control over the order in which things happen.
Before taking action, first confirm that GTG is actually enabled. You can check this within the Google product where the tag was created.
yourdomain.com/metrics) rather than googletagmanager.com, GTG is active. Google's Tag Assistant can also help identify late consent signals in real time.analytics_storage, ad_storage, ad_user_data, ad_personalization) in real time on any page and immediately spot a late consent signal, including when tags are served through GTG.You cannot fix a loading sequence that you have not first observed. Verification always comes before intervention.
If your tools report a late consent signal and you have confirmed that GTG is active, there are three ways to restore the correct order. The technical implementation details for each option are described in Google's documentation linked below.
Enable Advanced Consent Mode (also referred to as U+C) and configure, according to your requirements, the two settings Google provides within the product where the tag was created (Google Ads, Google Analytics, or Google Tag Manager):
denied within the EEA and UK where GDPR applies, or granted in jurisdictions where opt out models are legally permitted).When the user interacts with the consent banner, their choice overrides these default settings.
New to the distinction between the two modes? Our guide explains the differences between basic and advanced Consent Mode in detail, so you can choose the configuration that fits your needs.
Move all tags into a Google Tag Manager container and configure GTG to serve the container rather than individual tags. This allows you to manage all firing rules, including consent based triggers, from a single location.
Instead of using the one click setup, configure GTG manually and insert the GTG path directly into your website code. Place the Consent Management Platform snippet before the GTG script. This gives you direct control over the loading order.
For websites with GTG enabled and verified, the recommended approach is Advanced Consent Mode (U+C).
The reason is compatibility. It works both with manual GTG implementations, where you control the script order, and with standard Google deployments. Most importantly, it establishes consent defaults before any tag executes, regardless of whether the tag is loaded directly from Google's servers or through GTG. If you want to understand why advanced mode behaves differently from the basic one, see our comparison of the basic and advanced Consent Mode.
Advanced Consent Mode does not bypass consent requirements. It enforces them before a tag has the opportunity to bypass the rule.
My Agile Privacy® is designed to set consent signals as early as possible and includes mechanisms that automatically mitigate late consent situations, minimizing cases where a GTG served tag executes before default consent values are established.
However, in certain scenarios, such as one click CDN deployments where the page cannot fully control the loading order, the issue may not be solvable automatically. In these situations, when detection is active, a notification appears in the back office, informing you of the problem and providing the steps required to resolve it through one of the three approaches described above.
Automatic detection covers the most typical GTG case: Google Tag Manager starting before the default consent state has been set. The report is recorded during the Cookie Shield learning phase (the "Learning" mode the plugin uses to scan your site), and the alert expires on its own after 7 days without new detections. For other late consent cases - such as tags loaded without a GTM container, or an IAB TCF stub exposed too late - rely on manual verification with the Consent Mode V2 Inspector extension or Tag Assistant, as described above.
Once the problem is resolved - or if the configuration is intentional and verified - you can manage the alert directly from the plugin: in the My Agile Privacy® settings page, Consent tab, inside the Google Consent Mode v2 box you will find the "Google Tag Gateway detection" entry with the "Disable detection and notifications" option. The entry appears only after at least one detection has been recorded.
The goal is that you should not have to discover the problem on your own. The system identifies it and guides you toward a solution. You can also independently confirm the behaviour at any time, on your own site or on any other, with our free Consent Mode V2 Inspector Chrome extension.
A good tool does not simply work when everything is fine. It alerts you when something needs attention.
My Agile Privacy® is the Consent Management Platform you can genuinely trust for GDPR compliance. Even when the tagging infrastructure changes, as it does with Google Tag Gateway, one principle remains unchanged: consent must always come before tracking.