**Last updated March 7, 2024. Clarified that you do NOT need to resend hits when consent is granted, if those hits were collected on the same page when consent was denied.
Google’s Consent Mode continues to be a hot topic, especially since in 2024 it will be required to implement Consent Mode in case a website or app is collecting data for audience building or remarketing with Google’s advertising services.
In a recent update to server-side tagging in Google Tag Manager, Google switched the default deployment of a server-side tagging backend from Google App Engine to Google Cloud Run.
Now, when you create a new container and choose the automatically provisioned tagging server option, this service will be created in Google Cloud Run instead of in Google App Engine.
While I’ve written about Cloud Run before, this update gives me an opportunity to review what actually happens when you provision a Cloud Run environment, how you can upgrade it, and how you can add enhancements such as multi-region load balancing to it (with ease, I might add!
Google is going all-in with Google Tag. We’ve already seen the consolidation effort through products like Google Analytics 4, and now Google is extending the merging of the tagging stack into Google Tag Manager, too.
I’m referring to the new Google Tag that has replaced Google Analytics 4 configuration tags in your Google Tag Manager containers.
With this release, all your old GA4 configuration tags have been auto-migrated to the new Google Tag.
One of the big pain points in configuring Google Analytics 4 through Google Tag Manager has been the difficulty of setting up event parameters, user properties, and settings across a range of tags.
Well, we can finally get rid of our clumsy Config tag sequencing hacks because Google has released two new settings variables that mimic how the Google Analytics Settings Variable used to work in Universal Analytics.
The new variables are:
In January 2020, when Google Tag Manager’s server-side tagging was first introduced to the general public at SuperWeek, I wrote a flurry of tweets, sharing my vision of a server-side tagging future.
In one of the tweets, I discussed how you could do these:
Hit validation and fixing before the hit is sent to the endpoint PII and privacy controls for the requests before dispatch Fast forward to today, over three years later, and we are finally treated to a feature that grants us scalable controls to properly interrupt data flows within server-side GTM.
The FPID cookie is what server-side Google Tag Manager would prefer to use for your Google Analytics 4 tracking.
It’s a cookie set in the HTTP response from the server, and it’s flagged as HttpOnly, which means it’s only accessible by a web server running on the domain on which it was set.
There’s nothing wrong with the technology, and I do recommend that server-side setups toggle it on by default.
Server-side tagging is all about control. Being able to intercept, modify, and even block requests as they come in before they are dispatched to their actual endpoints is extremely valuable.
The built-in Google Analytics 4 tag template has options for modifying event parameters and user properties in the Google Analytics 4 request, but did you know you can use these options to modify some of the fields as well, such as Client ID, User ID, and event Engagement Time?