There are many reasons why you might want to duplicate your tags (or triggers, or variables, or templates) in Google Tag Manager. One prime example is server-side tagging, where it’s sensible to first build and validate your tracking setup before migrating fully to a server-side approach. Alternatively, you might want to collect analytics data to a second property, for example when you want to have a local and a global dataset for site visit data.

Continue reading

If you’re using server-side Google Tag Manager, Google (Advanced) Consent Mode and you’re collecting hits to Google Analytics 4, you might have noticed something odd happening when switching consent to granted state. It looks as if your page_view hits as well as any other hits marked as “Conversions” (or key events now, I guess) are automatically redispatched to the server-side Google Tag Manager endpoint when consent is granted! This sounds incredibly useful.

Continue reading

This will be a quick tip, but it’s here to correct my previous statements in the comments section of different articles on this blog. When using Advanced Consent Mode, Google Analytics 4 collects hits when consent is in "denied" state. These hits have a lot of parameters stripped off them, including identifiers like the Client ID and the Session ID. The hits will not surface in reports directly, but they will instead go through a modeling process to enrich the reports once modeled.

Continue reading

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.

Continue reading

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?

Continue reading

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.

Continue reading

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.

Continue reading