The FPID Cookie For Google Analytics In Server-side Tagging
With Server-side tagging, the developer community has a chance to vastly improve the data collection capabilities of Google’s analytics platforms (Universal Analytics and App+Web). The ability to build our own templates is particularly potent with a Server container.
However, it’s not as if Google themselves are just sitting idly by and seeing what the community can come up with.
In the built-in Universal Analytics Client template in a Server container, there’s an option to migrate to a Server Managed Client ID.
FPID (First Party Identifier) by default. The value stored in
FPID will be used for setting the Client ID in the request to Google’s servers.
In this article, I’ll walk you through how this works and what its implications are for data collection and security.X
The Simmer Newsletter
Subscribe to the Simmer newsletter to get the latest news and content from Simo Ahava into your email inbox!
How it works
Google Analytics uses the
HttpOnly flag. The new setting in the Universal Analytics Client gives you a couple of approaches to how to migrate (or not).
Server Managed - new HTTP cookie
However, when you set it to Server Managed, the Client will now parse the identifier from a new cookie and prefer that to what the browser (or device) sends as the value of the
&cid parameter. The new cookie is written in the
Set-Cookie HTTP header in the response back to the browser or other network source.
In other words, without making adjustments (see below), the Server container will generate a new
FPID cookie (if one doesn’t already exist) and use that to populate the Client ID of the outgoing request to Google Analytics servers.
The cookie is set with the
_ga cookie is deleted or the Client ID is reset. At that point, the system will migrate to the new Server Managed option stored in the
Here’s what it does in detail:
- IF the incoming HTTP request doesn’t have the
FPIDcookie but does have the
&cidparameter set in the request, a new
FPIDcookie is created with a hash from the value of the
&cidparameter in the incoming request. This
&cidvalue is passed through to Google Analytics as the Client ID, thus not resetting the user.
- IF the incoming HTTP request has both the
FPIDcookie and the
&cidparameter AND the
FPIDhash has been generated from this precise
&cidparameter, the value of the
&cidin the incoming request is passed through to Google Analytics as the Client ID, thus not resetting the user.
- IF the incoming HTTP request has the
FPIDcookie and either doesn’t have the
&cidparameter OR the values differ, then the hash stored in
FPIDis sent to Google Analytics as the Client ID. This technically “resets” the user, but since the
&cidalready has a different value than what the
FPIDwas originally derived from, the user would have been reset anyway.
Note that the
FPIDhash generated from the
&cidvalue also includes a server-side seed, making it impossible to deduce the
FPIDvalue from that stored in the
_gacookie using client-side code.
If these hits sent by the Server container are collected in a new Google Analytics property, it makes no sense to enable the migration option, as there would be no pre-existing users. Just use the Server Managed option without the migration selection checked.
On the other hand, if you start with a Server Managed setup but then want to switch to the migration flow, perhaps because you decide to start collecting to your main Google Analytics property instead of a test property, you can enable the migration option. However, you’ll first want to rename the
FPID cookie or else the value stored in
FPID from the original setup will be used instead of the Client ID of the incoming request. Renaming the
FPID cookie essentially resets it.
Caveat 1: Multiple Google Analytics cookies
One problem that arises with the Server Managed
FPID cookie is when your site’s trackers use different Client IDs. This is quite common, especially with cross-domain tracking, where the roll-up cookie is kept separate from the regular Google Analytics cookie to avoid cross-domain tracking from overwriting the Client ID for trackers that don’t want to use cross-domain tracking.
There is no support for multiple Client IDs in the Server Managed
FPID option, so if you don’t want the Server Managed option to break your multi-cookie setup, you need to hold off until a solution is released.
Caveat 2: Cross-domain tracking
HttpOnly, it doesn’t lend itself to cross-domain tracking. Cross-domain tracking is enabled with client-side code, and the
HttpOnly flag makes it impossible for client-side code to access the Client ID for cross-domain link decoration.
There is very likely a feature being designed to support cross-domain tracking, but until such a feature is released, you should hold off from running with the Server Managed option.
Caveat 3: No cookieless option
Client-side Google Analytics can be used without cookies. This is a viable option in the EU if the user hasn’t given consent for storing or persisting any data in the browser or device.
Unfortunately, the Server Managed
FPID cookie doesn’t currently have a way to comply with this wish. Incoming HTTP requests claimed by the Client with the Server Managed option activated generate the
FPID cookie in all cases.
Again, if this is a deal-breaker for you, you’ll need to wait for the Client to support a cookieless option.
If Google Analytics engineers were given a chance to redesign how GA persists the client identifier, they would build GA with the
Cookies are notoriously tricky to get right, but the fact is that the closer they are to client-side access, the less secure they are. Even though the Google Analytics identifier doesn’t have any personal data encoded within, nor can it be used as an access key for any authentication systems, it’s still a vector for cross-site tracking.
The Google Analytics cookie is a persistent first-party identifier that can be repurposed for cross-site tracking in cookie syncing setups, for example.
By moving the identifier to an
HttpOnly cookie, the identifier is protected from misuse.