Content warning: introspection, parenthood, “Floating Butt”.
When Benjamin (our first child) was born, my life as an individual was unraveled.
With every bellow from the newborn’s lungs, I could feel my personal agency slipping away from me.
From that magical moment onwards, I’ve been gripped by the polarizing emotions of parenthood.
At any given time, I’m galvanized by fear for the well-being of my children, or existentially deadlocked by the calamities of all the possible (terrible) futures for this planet, or (figuratively) high from the amazing content and purpose my children bring to my life.
The Simmer Newsletter
Subscribe to the Simmer newsletter to get the latest news and content from Simo Ahava into your email inbox!
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.
I owe my career to Google Analytics.
Whatever success I have achieved over the past 15 years or so can be directly attributed to my work with GA and, by extension, other tools in the Google stack.
Now, Universal Analytics is about to be turned down.
It fills me with a sense of nostalgia and pining for past, simpler times.
When I cast my mind back, a scattering of memories emerges in my mind:
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?
While Measurement Protocol for GA4 is still rather, well, rough, it can be used to augment existing collection quite nicely. Recently, I wrote an article that discussed the nuances of session attribution with Measurement Protocol.
One of the pain points of any data ingestion setup is how to debug it.
Measurement Protocol hits are not automatically surfaced in GA4’s DebugView.
In this article, I’ll show you how to make those hits pop up in the debug stream.
In this article, I’ll try to clarify the understandably murky Measurement Protocol functionality in Google Analytics 4.
Measurement Protocol is a way to send events to Google Analytics 4 directly from a machine capable of sending HTTP requests (such as a web server). It’s an alternative collection method to the client-side libraries of Google Tag and the Firebase SDK.
Measurement Protocol in GA4 is very different from its predecessor in Universal Analytics.