I'm trying to keep count of the visitors to my blog (I'm using a static site published on Github Pages) and for that purpose I'm using Google Analytics 4.

But I realized that ad blockers such as uBlock Origin block request to tag manager or analytics domains and even URL path segments like /gtm.js or /gtag/js?, see EasyPrivacy. So making the metric not very realistic as many people is using browser ad-blocking extensions.

I've been reading recent articles about server side tagging, and how it can be used to deploy an App Engine instance for Tag Manager, and bypass ad blocking (between other goals). But as far as I can understand, doing it this way could bypass the domain blocking (e.g. www.googletagmanager.com), as tag manager becomes a first-party under your managed domain. But not to circumvent the blocking rules based on URL path. So,

1. Is there any way to configure the server side tag manager to serve the JS scripts in different custom paths so that become impossible to block? If so, how can it be configured?

2. In case it's possible, should I use directly the analytics script?

  <script async src="https://stats.MY-DOMAIN.com/gtag/js?id=G-xxxx"></script>
  <script>
    window.dataLayer = window.dataLayer || [];
    function gtag(){dataLayer.push(arguments);}
    gtag('js', new Date());
    gtag('config', 'G-xxxx');
  </script>

3. Or should I use the tag manager script/noscript snippets instead?

I'm also trying to understand what's the difference in placing one snippet (Google Analytics 4) or the other (tag manager) in the HTML. Thx!

P.S. I'm mainly interested in knowing the number of visitors/country of origin (not much interested a priori in any other metric).

CodePudding user response：

Seems like you're misunderstanding the concept of server-side GTM.

The idea here is that the endpoint of your server-side GTM (the G Engine instance) is never exposed on front-end.

So your back-end sends events to your App Engine instance, not the front-end. You typically don't need to deploy ANY code on the front-end. All logic is supposed to be set up solely on the backend. By your back-end developers. Your backend usually can listen to all the important events that are happening seemingly on the front-end. Like page navigations, form submissions, purchases, etc.

You still can send seemingly front-end events to your server-side GTM. But you have to be smart about it. You don't want to expose your real GTM endpoint exactly to avoid bots, "hackers" and adblockers.

So what you do instead, is:

1. Build a custom "mirror" endpoint on your backend the main idea of which is to relay everything it gets to your App Engine GTM endpoint. Actually, it doesn't matter where you build the mirror endpoint. Your backend team would likely frown upon the idea of analytics contributing to "their" repos, so it may be a good idea to own your endpoint.
2. Add protection, data enrichment, validation and logging to your mirror endpoint. It's optional, but it's good to have.
3. Now use your new endpoint for the rare cases when you need to add front-end tracking to your existing back-end tracking. Addblockers will still block your front-end GTM, so you likely want to use something else (NOT a TMS) for your front-end code.
4. Optionally, add some back-end logic to synchronize client ids between the backend events and your mirror endpoint events. And it's a lot easier if your mirror lives with your main back-end codebase, keep it in mind.

Yes, server-side brings a lot of elegant solutions to modern tracking. It, however, requires the implementation specialists to be full-stack web-devs. And it's not typical for the industry. In fact, it's rare for the implementators to have even mid-JS dev skills, not mentioning full-stack or REST API experience.