When server-side tagging is available, the developers can vastly improve the data collection capabilities of Google Analytics platforms(Universal Analytics and App+Web). The ability to build our own templates is particularly potent with a Sever container.
In the built-in Universal Analytics Client template in the Server container, there’s an option to migrate to a Sever Managed Client ID.
FPID (First Party Identifier) by default. The value stored
FPID will be used for setting the Client ID in the request to Google’s servers.
How does It work?
Google Analytics uses the
HttpOnly flag. The new setting in the Universal Analytics Client gives you a couple of approaches to migrating (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
FPIDa cookie is created with a hash from the value of the &cid the parameter 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 FPID hash generated from the &cid value also includes a server-side seed, making it impossible to deduce the FPID value from that stored in the _ga cookie 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.
Multiple Google Analytics Cookies
One problem that arises with the Server Managed
FPID a 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.
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.
If Google Analytics engineers were given a chance to redesign how GA persists in 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 a
HttpOnly cookie, the identifier is protected from misuse.