Google Tag Manager (googletagmanager.com) does not load trackers itself, it manages them. The actual data-protection issue is the tags it deploys.
The most common mistake with Tag Manager is assuming a blocked consent tool in the container is enough. As long as the container snippet sits in the <head>, a connection to googletagmanager.com is established on page view and the IP address is transmitted to Google — before any tag fires. For the container itself this can only be avoided by loading it after consent or serving it server-side.
Google Consent Mode v2 has been effectively mandatory for advertising functions in the EEA since March 2024 if conversion data is to flow to Google Ads. But it does not replace a consent tool: Consent Mode only adjusts the behaviour of the Google tags to the consent status — the status itself must still be captured by a banner that meets the requirements for consent.
With server-side tagging, tag execution moves to a dedicated endpoint (often a subdomain). This improves load time and data control but does not shift the consent requirement: server-side tags that access client-side identifiers also need prior agreement.
If the Tag Manager loads consent-requiring tags (Analytics, Ads, Pixel) before or despite a rejection, there is no legal basis for these under § 25 (1) TDDDG. The container request itself already transmits the IP to Google (USA).
The free scan checks the delivered HTML and shows which services are embedded, whether a cookie banner is detected and whether privacy-policy and legal-notice links are present — with context for each finding. It is not a substitute for legal advice.
This text is general information to the best of our knowledge, not legal advice. For an individual case, consult a law firm specialising in IT law.