Before we dive into server-side Google Tag Manager (GTM), I’ll prefix the meat of this post with a caveat: always respect user privacy. 

Any data collection techniques discussed here must be applied righteously and not as a workaround to circumvent data collection consent regulation.

10,000 Foot View

Here’s a familiar situation - Google Tag Manager as we’ve known it for years.

Your container is loaded on all pages, or screens in your site/app, and based on trigger events, data is sent to first- and third-party endpoints.

It works, it’s fine, but it’s not perfect. Tracking blockers, JavaScript failures, many, many requests to endpoints, and inefficient JavaScript are all risks, and potential performance problems that can lead to data quality issues.  

Server-side GTM moves the tag vendor request from the client to a server—a server on Google Cloud Platform living on a subdomain of your site. The container loaded in the browser/app still has tags and still sends a request but has way less code, sends fewer requests, isn’t necessarily affected by anti-tracking software, doesn’t send the user’s IP address to third-party tag vendors, and first-party cookies are correctly set in an ITP compliant manner.  

Out of the Box - What’s Cool?

There’s a lot to be excited about with server-side GTM in that, on the client side, it’s all very familiar—but way better! The “traditional” digital marketer can still set up their Facebook tag(s) with the same triggers, and deploy Floodlights as required. Same, same… but different.

As mentioned earlier, rather than sending data to the tag vendor endpoint, it’s sent to a subdomain. For example, if you’re on www.mysite.com, server-side GTM will send data to tracking.mysite.com, a subdomain you can have configured.  

And that’s great because…?

• It respects user privacy: The user’s IP address isn’t sent to a third party.
• It preserves data quality: Tracking prevention doesn’t happen on requests to your own domain.
• It lightens code bloat from the client side: The tags require less work on the browser, shifting the workload to the server instead. This means what remains in GTM on the browser does less, so the site runs faster.
• It consolidates requests from the client side: You can send multiple requests from the server based on one request from the client.

At MightyHive, we strongly advocate for focusing on what’s best for the user, not the ability to foil or circumvent anti-tracking software. Reminder: act righteously, not selfishly. As it stands now, data is collected, not captured. In the future data will be exchanged… Think about that for a minute.

Deeper Impact

Have you noticed that tracking requests are sent to your domain and not a third-party domain? The data collection workload is moved to your infrastructure.

Does that feel like just going back to web server logging? How different is this from web server logging?  

Very. 

Analytics data is formatted (sessionized), cleaned (PII removed), integrated (joined with data from Google Ads, Search Ads/Display & Video 360) and presented ready to perform its function: analysis and optimization of all aspects of the online business, which, let’s face it, is all about better marketing.  

Web server logs don’t collect all behavioral data. Typically, log-level data isn’t integrated with marketing channel data, meaning there’s no feedback loop for activation of the data. 

But! There are similarities between server-side GTM and web server logging. The web server receives a request, typically for a page, builds the page content and responds, possibly setting first-party cookies along with the response. The server-side GTM endpoint also receives requests, and responds, potentially with cookies (but with less content).

Now… the web server knows what page it’s returning.

It knows what data to render on the data layer to record a transaction (for example). 

The data layer is picked up by a tag firing in the browser and then sent back to the tracking endpoint. 

The end point then takes the same data and fires it off to Google Analytics (GA) to complete the round trip and get your analytics data recorded. 

Phew!

Wait one minute. If the web server knows it’s rendering a “thank you” confirmation page, and it knows what data to render on the data layer, why bother sending this to the browser for the browser to just send it back to the tracking end point and then to GA?  

Why not remove some steps for efficiency? The web server knows it is rendering a confirmation page. So it builds the exact same request the browser was going to, and sends the GA transaction data straight to the tracking end point. Cut out the client round trip.

It’s quite normal to fire off conversion tags, Floodlights, FB pixels, Adnxs, TTD, and so on to record transactions. Don’t send those to the client to handle. As the web server responds with the confirmation page, send those requests straight to the tracking endpoint. The endpoint responds with the details of the cookies to set, and the web server sends those with the confirmation page content in the response to the client.

Think how many marketing tags and tracking pixels fire on page level events. How many tags actually need to fire on the client? How many tags don’t even need to be exposed to the browser? What if, just maybe, you only had page-level event-triggered tags? Maybe you only need page-level tracking if you’ve removed all of your data bloat? Then you don’t need to CNAME the tracking subdomain, you can restrict access to your tracking endpoint to only allow your web server to access it via https (think IP range restriction). That’s a bunch less complexity and a fair amount of moving parts removed from the solution.

Simpler is better. No code is better than no code, as the saying goes.

In Conclusion

The server-side GTM solution offers a good and correct solution to digital analytics measurement. It’s good because data quality can be improved, user privacy is further protected, and significantly, it’s a step towards doing less work in the browser, meaning sites and apps get faster.

Thinking about the possible solutions the technology offers, with the right motivation in mind, demonstrates how versatile the solution is, how much power is available and what avenues are still to be explored to leverage first-party data.