I am currently trying to understand more about server side tracking and its ability to get around ad blockers. AS well as best practices for server side tracking setup.
What would be the best way to test sGTM setup to effectively get around ad blockers? Would it be possible to install the Custom Loader script on the site and continue to use the standard GTM code snippet for browser side tracking and see how server side vs browser side compare? This way we can see the difference in collected traffic between Browser side and server side tracking?
When setting up server side tracking is it necessary to use the browser side GTM container as well or can everything be configured in the server GTM container?
What kind of impact have others seen when using the Custom Loader in Stape.io vs the standard GTM tracking code?
It will depend where do you want to send your data. For example if you want to send them to GA4 then according to Google you need to have two separate GA4 account. One for browser-side and other for server-side data. Yes you can have standard GTM code and GTM custom loader script. However it’s not ideal to have two GTM code. Best to keep only one.
You need to collect data from your browser and then send them to your server. So you’ll have some tag for SST. Although most of your tags will be inside you sGTM container. So your number of browser-side tags will be minimum.
I’ve set up SST for my clients and from the Stape’s analytics last 10 days:
Stape recovered requests from ad blockers: 6,976
Stape recovered requests from tracking prevention: 72,300
@Md_Monirul_Islam wrote everything correctly, I will add a little from my side
What would be the best way to test sGTM setup to effectively get around ad blockers? Would it be possible to install the Custom Loader script on the site and continue to use the standard GTM code snippet for browser side tracking and see how server side vs browser side compare? This way we can see the difference in collected traffic between Browser side and server side tracking?
It really depends on the platform. In GA4 it is extremely difficult to set up parallel client and server tracking and it is not recommended to use several properties at the same time. I wouldn’t recommend doing this with GA4.
But you can easily check it for example on Meta events and/or Google ADS conversions.
Just configure separate events/conversions that work through the web only and others through the server only. This way you can see how much more data is collected by server tracking in your case.
Don’t forget to install custom loader instead of standard GTM and activate GA4 bypass if you use GA4 as a mechanism to transfer data to the server.
It actually depends on your audience, how often they use adblockers. If you have a technical audience, I have seen cases where the percentage of adblockers is around 50%.
At the same time, if it is a site with children’s clothes for example, the percentage of adblockers is unlikely to be too high, in my experience about 5%.
When setting up server side tracking is it necessary to use the browser side GTM container as well or can everything be configured in the server GTM container?
In most cases, it’s mandatory. Since something has to pass data to the server container. You can do this without a web container e.g. by using webhooks or by setting up the data transfer yourself e.g. via fetch(), but there is usually no point in doing this as it is just much longer and more complicated.
What kind of impact have others seen when using the Custom Loader in Stape.io vs the standard GTM tracking code?
Custom loader itself has the effect of preventing adblockers from blocking the GTM container from loading.
There is also a GA4 bypass function in adblocker that protects GA4 server-side events from adblockers.
But besides that there are also ITP (Safari) restrictions that are not affected by custom loader. You can bypass them in one of three ways:
@Alex You are absolutely spot on!
I’m facing this similar situation with one of my client.
I have a client who is adamant to use standard GTM due to his existing client-side tracking setup. He doesn’t want to disrupt his setting without comparing the SST result. That’s why he doesn’t want to remove standard GTM script yet.
He want’s to create separate GA4 property for client-side and server side. After getting comparable data then he’ll consider removing standard GTM. I explained him everything but he’s so stubborn!!
So I’m planning to keep standard GTM for his client-side and am also going to integrate custom loader script as well for my GAds and GA4 SST setup.
What’s your thoughts on this? Will it work properly or disrupt the client-side setup?
Option b are the most effective to bypass any ad blockers but it’s a bit complex to set up and need technical knowledge to implement.
Option c is second best. You’ll set up custom domain and will use cookie keeper. It’s very easy to set up and you don’t need any technical knowledge to implement.
The preferred options are own CDN or same origin. But there are platforms where this is not technically possible (e.g. Shopify).
In the case of ITP there is actually no difference between using your own CDN or the same origin. For cookies it will work exactly the same.
In the case of same origin you can set it up for example on Ngnix and not use Cloudflare, which can save you money if you don’t need a CDN in general.
So I’m planning to keep standard GTM for his client-side and am also going to integrate custom loader script as well for my GAds and GA4 SST setup.
If it’s the same container then it makes little sense.
Custom loader helps to avoid blocking GTM loading by adblockers. If you have a standard loader and custom loader of the same container - I don’t see the point of it. If the container is not loaded by the standard loader, it will be loaded by the custom loader anyway, but you can’t check or track the results of this in any way.
Well, the work of several GA4 that run client-side and server-side in parallel - it works extremely badly and leads to incorrect data in both analytics.
