von Matilda Wassgren
Debugging events in GTM when server side is set up includes more steps than client side GTM. In this article we go through how you can validate your event in every step. First we look at the preview mode of client side GTM. Then we follow the request and look at how it arrives in the server side container. We look at the different tabs and what the data in each of them means. If the data does not look like you expect when you are debugging, there are some things you can look at to find out what the issue might be.
Webanalyse steht für Messbarkeit und ist die Grundlage für langfristige Erfolgskontrolle und Effizienzsteigerung Ihrer (Online) Marketing Aktivitäten.
Mehr ErfahrenAre all your tags firing correctly in GTM with server side? This step by step guide to debug your tag manager implementation will help you out.
If you have worked a bit with Google Tag Manager, you know how to open preview mode and test your tags. You know how to check triggers and variables so see what needs to be changed to get the data you need all the way to the tracking tool of your choice.
With the introduction of server side tagging, debugging in GTM has gotten more complex. In this post we will look at what to look at when debugging a server side set up in Google Tag Manager. For that you need to look in both the preview mode of your client side container and your server side container.
First, let’s look at how information flows between the website and your end destination when you are using a server side set up.
Open preview mode first in your server side container. There might be an option to choose which environment you want to debug if you see the three list symbol to the right of the preview button.
Server side preview mode. Source: GTM
This could be if your site has a test version where you can see features before they are launched or make a purchase without actually placing an order.
Pick the right url for the version of the site you want to debug and click preview, this window opens:
Server side preview open. Source: GTM
If you do not know which url to pick, you can try one and if you see no data when debugging, switch to the other url and test that one instead.
Then open your client side GTM preview like normal. Here you can trigger an event and validate that your server side tags fire when they should.
Server side preview open. Source: GTM
Then go over to the server side preview tab. In the left column, instead of seeing what happened in the dataLayer, you will see which requests were sent to the server side container. If you for example test a GA4event that fired in the client side GTM you will look for that event name in the server side preview.
For each request that comes to the server side container there is a lot of information available, divided into different tabs. Let’s look at them one at a time:
In this tab you find data that comes with the client side request. It will contain the parameters you set on the client side tag. It also includes automatically collected information about for example the browser, consent state or if the event triggered a first_visit or a session_start.
Event data is the server side equivalent to the dataLayer, it is the information that the server side container receives and potentially transforms before it sends it off in the different tags.
Event data. Source: GTM
In this tab you will find the values on the current event of the user defined or built in variables that you have added to the server side container. This works just like in a client side container. The difference is the types of variables that are available. For example instead of dataLayer variables, there are event data variables that pick up information from the event data we looked at earlier.
Variables. Source: GTM
The tags tab also works like you would expect compared to client side GTM. It shows which tags fired for the event, it can be several. For example the view_item event from client side might trigger one GA4 Tag and one Floodlight Tag, sending off different requests to the different tools, but still based on the same event data.
Tags. Source: GTM
If you open up one of the tags, you will see some more information about the tag when it fired. You will, just like on the client side, see which trigger made it fire and or blocked it.
A new feature in server side however, is the transformations. A transformation is a set of rules for which event data that came into the server side container the tag in question is allowed to use. For example the same client side event might be used for both GA4 and Floodlights. But some of the event data is excluded from the Floodlight but used in GA4.
In this case I used a transformation to exclude the event parameter “action” from the event data for this specific tag. It will not be processed and sent on to GA4.
Modified event data. Source: GTM
If you click the checkbox to “show original” you will get a side by side comparison of which data is available on the event and what data this tag is allowed to process.
Here we can see that the action parameter is no longer included:
Show original. Source: GTM
The last tab is the request tab. Here we can see more technical information about the client, the outgoing request and the incoming request. This is a little different from what you might be used to in the client side container.
Request. Source: GTM
The client is a server side specific feature. There can be several clients in the container but only one client is allowed to process each incoming request.
This is the information that is coming into the server side container that can then be processed. In this case it is the same GA4 event that was sent from the client side container. For normal debugging it is easier to look at the event data tab. But if you want to know look up some technical details or how the request looked before it was processed, you can look here.
In the example there is only one, but there could be several. These are mainly the result of the tags that you see fire in the Tags tab. In the example we see the request that the GA4 tag made of the incoming request and the rules set in the transformations. It is this information that will be sent off to GA4. This is the equivalent of the request that the client side tag would send directly to GA4 if there were no server side installed.
Check also that the events you test are received in the destination that you are sending them to. This could be the GA4 debug mode or the Pixel test page for your social tracking. A tip is to add a debug parameter with the server side container information to your requests. This way you can verify that the request really went through your server side container.
In case the step by step workflow does not work out right, these are our recommendations for troubleshooting :
If you get this pop-up when trying to preview, you need to follow the link and add the url. This will only affect the preview abilities of your server side container. It is the url added to the client side tag that controls where the request will be sent.
Server side container. Source: GTM
Container settings. Source: GTM
Here are suggestions of some things you can check if you do not see the event in the server side container.
Just like you would normally for client side tags.
It should match with the url in the preview settings (see above) and the url where the server side container is set up.
Server container url. Source: GTM
Go to the browser developer tools (F12 or right click and then choose “Inspect”). In the Network tab, filter on the event you want to examine.
To see all GA4 requests you can filter on collect?v=2. If you want to only see a certain measurement id, you can filter on tid=G-XXXXXX (replace G-XXXXXX with your measurement id). Or you can filter on the GA4 event name, for example view_item.
In the example below, the request with status 200 was successful while the request with the blocked status was not. Check in the Console tab for an error message with more information of what exactly was blocked.
Network tab. Source: Chrome developer tools
Debugging a server side tracking set up in GTM follows the same patterns as you are used to with client side tracking. Once you know where to look, it is actually easy to follow your request as it moves from the browser to the client side container, on to the server side container and then sets off to the end destination.
Wir freuen uns auf Ihre Anfrage und beraten Sie gerne unverbindlich! Füllen Sie dazu einfach das Kontaktformular aus oder rufen uns direkt an.
Jetzt kontaktierenNewsletter
Holen Sie sich unsere Online Marketing-Insights und Trends direkt in Ihr Postfach!