Simo Ahava's blog

Today marks the date of exactly 10 years of marriage to my wife, my friend, the loving mother to our children, and my business partner at Simmer. And yes, they are all the same person – I’m that lucky!

Thank you, Mari, for everything.

Today marks the date of exactly 10 years of marriage to my wife, my friend, the loving mother to our children, and my business partner at Simmer. And yes, they are all the same person – I’m that lucky!

Thank you, Mari, for everything.

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.

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.

However, there might be cases where you want the server-side GA4 client (which handles the incoming GA4 requests) to occasionally not use the FPID cookie. Perhaps it’s because you have a custom consent system in place, or perhaps you want some GA4 measurement IDs to use the regular JavaScript cookies and others to use the FPID.

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. It’s very straightforward to do, and contrary to many of the articles I write, there’s only one caveat that I could think of.

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. In Universal Analytics, Measurement Protocol was the collection mechanism, with the same protocol being used for both client-side library hits and server-to-server hits.

This is a guest post by Sebastian Pospischil, Evangelist Digital Analytics at TRKKN. All credit for the solution goes to him. The Summary section is the only one authored by Simo Ahava.

You know the deal.

Each and every day, clients reach out to you asking for custom click tracking for this call-to-action on that slider, or that button in this section of a page. They reach out to you because such things cannot be answered out of the box in Google Analytics 4.

If you recall, in February 2019, Apple published a post on the WebKit blog, which introduced version 2.1 of their Intelligent Tracking Prevention browser mechanism.

In this version, Safari (and soon all WebKit browsers, including browser apps on iOS and iPadOS) placed an expiration limit on browser cookies set with JavaScript. It was no longer possible to set the expiration date further than 7 days in the future.

In a recent 2022 release (I don’t have the exact date or version number), WebKit has now modified this mechanism to no longer set an expiration cap on JavaScript cookies.