- OptimizeSmart Newsletter
- Posts
- How Developers Prevent GTM Scripts from Ad Blockers
How Developers Prevent GTM Scripts from Ad Blockers
๐งจ ๐คฏ I am not a web developer. So, I asked seasoned developers how they are currently stopping ad blockers from identifying and blocking GTM container scripts. I summarised their findings in a 6 steps approach to dealing with this issue. ๐
In case you are unaware, Adblockers like 'Ghostery' employ not one but multiple sophisticated mechanisms to identify and block tracking scripts like GTM container code.
Blocking the client-side GTM script makes even the GTM server-side tagging pretty much useless.
And since millions of people use adblockers, most of the time, your tracking does not work whether or not a user consents to tracking.
Step-by-step approach to save GTM script from being identified and blocked by AdBlockers.
Step-1: Rename the GTM Script to avoid detection by name.
>> Rename gtm.js to something generic like ra.js or app.js.
>> Ensure this renamed script contains the GTM container logic.
Step-2: Serve the script from a custom domain to mask its origin.
>> Host the renamed script (ra.js) on a custom subdomain (e.g., https://site.abc.com/ra.js).
This subdomain should not be associated with Google or GTM (e.g., avoid analytics. site. com or anything indicating tracking).
Step-3: Obfuscate the functionality and identifiers.
>> Obfuscate the loader script to make it harder to detect patterns.
Use random or generic variable names (e.g., rand or layer).
Use a random event name.
>> Optionally, minify the loader script using tools like UglifyJS.
Step-4: Mask the GTM Container ID.
>> Encode the container ID (GTM-MJ9VG94) using Base64 or encrypt it with a simple cipher. Decode or decrypt the ID dynamically before appending it to the request.
>> Alternatively, fetch the container ID dynamically from your server.
Step-5: Proxy the GTM Script to mask its origin, making it appear to come from your domain.
>> Configure your server to fetch the actual GTM container from Google and serve it as https ://site.abc.com/ra.js. This step ensures that no direct requests to googletagmanager.com are visible to the client.
>> Tools like Nginx or a server-side language (Node.js, PHP, Python) can handle this proxying.
Step-6: Test the Implementation.
>> Use browser debugging tools to verify that requests to googletagmanager.com or other Google domains are hidden.
>> Test with popular AdBlockers like Ghostery, uBlock Origin, and AdBlock Plus to ensure your implementation is not detected.
The screenshot below shows the final version of the custom loader that incorporates these steps.
To fully meet all requirements, server-side tagging and proxying the GTM script should be implemented on the server.
The current custom loader works well for reducing detection risks, but server-side tagging provides the most robust, future-proof solution.
Caveat: The custom loader script is a non-standard implementation of GTM, which could create hard-to-diagnose issues.
Diagnosing why tags or triggers fail could become extremely challenging as custom implementations obscure the GTM logic, , making it harder to debug or use tools like Google Tag Assistant, GA Debugger, or browser developer tools.