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?
With the sunset announcement of the Universal Analytics service, it certainly does seem like a waste of time to write articles about it. However, a recent update to Google Tag Manager is an interesting one and should provide relief to those Google Analytics users who are set on double-tagging their sites for both Universal Analytics and Google Analytics 4 and who want to make use of GA4’s new Data Layer schema.
With certain types of HTTP requests, the web browser might first dispatch a request with the OPTIONS method, also known as a preflight request. The purpose of the preflight request is to “check” with the web server that it’s equipped to handle the type of cross-origin request the browser wants to dispatch. If the server doesn’t handle this preflight request, or if it returns a response that doesn’t agree with what the web browser wants to actually dispatch, the check fails and the browser refuses to send the actual request.
Server-side Google Tag Manager has an excellent Preview mode, which lets you inspect incoming requests, monitor the event data object, view console messages, and identify outgoing requests, among other things. To enable this Preview mode on the web, you simply need to click the Preview button in the container, after which any requests sent from the same browser instance will be automatically shown in the Preview mode window. However, what about if you want to send requests from another browser?
If you want to manually install server-side Google Tag Manager on App Engine in the Google Cloud Platform, you are of course welcome to do so. The main benefits of doing this are that you get to choose the region where App Engine is deployed and that you can use existing project resources instead of having a new project automatically created for you. However, to run the script without errors, there are a number of things you need to enable first.
While Google App Engine, the default implementation pattern of server-side Google Tag Manager, is straightforward to setup with the automatic provisioning steps, it’s certainly not the only way to deploy the server. You can set it up in Amazon AWS (this blog) You can set it up in Microsoft Azure (this blog) You can set it up with Cloud Run (Mark Edmondson’s blog) In fact, the manual setup guide gives you the details on how to deploy a Google Tag Manager Server in any environment that runs Docker.
- OLDER POSTS
- page 1 of 20