Server-side tagging in Google Tag Manager is still a rather new concept to most digital marketeers, and it’s normal that some common issues arise. Apart from it being a new concept, it is on the crossroads of marketing and IT, so a close collaboration with teams of different backgrounds is often needed. At Semetis, we’ve been experimenting with server-side tagging over the last years, and did some interesting studies. One of them was the impact server-side tagging had on page speed.
If you’re completely new to the concept of server-side tagging in GTM, there are a couple of interesting resources we can recommend. The most complete resource to this day is definitely the Server-side Tagging In Google Tag Manager course by Simo Ahava. Julius Fedorovicius from Analytics Mania has also written an impressive guide, complemented with some videos. On top, this is free, while the course by Simo Ahava isn’t.
Today, we will be looking at one of the most common issues we saw arise since the conception of server-side tagging in Google Tag Manager: why some GA4 events might not show up in the preview mode of your server container. Note that in this article, we’re using a set-up in which we are sending GA4 HTTP requests to our server container.
There are a couple of primary reasons why your GA4 events might not be showing up in your server container while previewing. Here’s a checklist to go through:
- Make sure you’re referring to the right GA4 Configuration Tag in your GA4 event tag.
- Your Configuration Tag needs to be pointing to the right server URL.
- Make sure that the tag that fires the event is firing on the correct pages or in the correct situations.
- The data layer is used to pass data to the GA4 event tag. Make sure that the data layer is being pushed correctly and that it contains all of the necessary information for the event.
If you’ve checked all of the reasons above, there might still be another reason why your GA4 event is not showing up: the configuration tag is firing too late. The GA4 configuration tag is responsible for routing hits to the correct destination, whether it's the Google Analytics 4 property or the server container. Make sure that the GA4 configuration tag is firing before the GA4 event tag.
In the example I’ll be using below, we had recently implemented consent mode. This set-up pushes a new data layer event gtm_consent_update which we in turn use to trigger our GA4 configuration tag (and any other pageview tag). The downside of this is that the newly created event gtm_consent_update fires quite late, after all other events have been fired. If you’re pushing an event on a pageload, it can happen that gtm_consent_update is only being fired after that event has been passed in the data layer. Let’s take the example of the data layer event view_item.
As you can see from the screenshot above, the view_item event has been fired way before the gtm_consent_update event has been fired. The GA4 view_item event tag, that is supposed to be sent to the server, fires before the GA4 configuration tag, which fires on gtm_consent_update. Since the configuration tag is responsible for routing the event tag to the right destination, the event is not being sent to the server. The GA4 event in turn doesn’t show up in my server container.
One way of working around this is making sure your event only fires after your configuration tag, but in most cases this requires development support.
Another workaround is to add an extra parameter to your GA4 event tags. When adding server_container_url as an event parameter, the event tag in theory doesn’t need the configuration tag to know where it needs to send data. Even if the event fires before it can use information from the configuration tag, it sends an HTTP request to the server. The result is that my event now shows up in my server container, even before the page_view event sent by the configuration tag.