The most common problems with a SST setup
A common source of frustration occurs when issues arise with measurements on your marketing or analytics platforms, and you’re dependent on the time we spend analyzing the problem. To help you reduce this dependency and reach a solution more quickly, we’ve put together a series of steps that allow you to conduct your own analyses. This guide will help you identify and possibly even resolve the issue on your own, saving time and improving your problem-solving skills.
This helpdesk article is based on our own support input. If you encounter other problems not covered here, please let us know via the chat function in the bottom left corner or by emailing us at support@adpage.io.
When you set up the cookie banner and configure the consent overview settings correctly, the first page visits may no longer be measured accurately. During these first page visits, UTM parameters from your visitors are recorded. The second page visit may then be considered the first page visit. This occurs because the Google Tag and page_view event tags are often set to fire on Initialization or All Pages. However, visitor consent updates happen after this step, causing the Google Tag and the GA4 page_view event tag to not fully trigger due to GTM’s Built-In Consent Checks. Therefore, when the visitor updates their consent, the Google Tag and page_view event tags need to be fired again or for the first time.
Solution:
Resolve this issue by following the steps in this article: Triggering consent updates correctly
Are you using Cookiebot? Then you have the option to specify under which category each cookie falls. Certain cookies placed by the server are crucial for recognizing a user, such as session_id, client_id, and user_id. However, these are not always considered ‘Necessary’ cookies by Cookiebot, requiring them to be regenerated when a new user accepts the cookies via the cookie banner. This mismatch can cause user information on the first page of session one to differ from the user information on the second page of session one. Follow the steps below to check if this problem is occurring for you.
Install a DataLayer checker extension in your browser. We recommend this one for Google Chrome users: DataLayer Checker
Ensure that this extension also works in an incognito window/private mode.
Now open an incognito window/private mode and go to your site.
Use your DataLayer Checker to view the information from the trytagging_user_data/sld_user_data event. Click on the ‘json’ button in the DataLayer Checker to see the following:
Take a screenshot of your user_id, client_id, session_id, and session_count.
Now accept all cookies and navigate to the next page.
On this second page, open the trytagging_user_data/sld_user_data event in the DataLayer Checker again by clicking on the ‘json’ button.
Compare whether your user_id, client_id, session_id, and session_count match the values from the first page where you took a screenshot.
If any of these IDs differ, you need to perform the steps below.
Solution:
Resolve this issue by following the steps in this article: Set server cookies as necessary via Cookiebot
The trytagging_user_data/sld_user_data event in the DataLayer contains the marketing and user information from which Google Tag Manager retrieves user data. If you trigger the Google Tag or the GA4 event tags before this event occurs, you may miss important data. This can cause errors, such as users and their sessions not being properly transmitted to marketing and analytics platforms, leading to unassigned events in GA4.
Solution:
Replace all your Initialization or Page View triggers with the user_data trigger.
Ensure that all other event tag triggers fire after the Google Tag trigger, meaning after the user_data trigger.
You can do this using a trigger group:
If the Google Tag is fired after a GA4 event tag, your tracking setup is not ideally configured. The Google Tag must fire before the GA4 event tags. You can check this by looking at the order of triggers. For example, does the Google Tag trigger on All Pages - Page View, while the GA4 event tag for page_view triggers on Initialization? If so, you need to adjust this.
If the triggers for the Google Tag and other GA4 event tags are set to the same trigger, you will need to use the tag priority settings. The higher the tag priority number, the earlier it will fire. For example, set the Google Tag to “1000” and the GA4 event tag for page_view to a lower number.
If you use Cookiebot on your website, a large amount of traffic may appear in your Google Analytics property. This is normal behavior, as the Cookiebot scanner visits every page of the website to determine which cookies/trackers are used.
Solution:
Perform the following steps: Exclude Cookiebot data from GA4
If you see too much data in GA4 compared to reality, or if you notice a large percentage of unassigned traffic, it may be that you are still collecting data from an old or different (sub)domain. You can test this by adding a new dimension called ‘Hostname’ to a GA4 report.
In addition to receiving events from another (sub)domain, specific problems like unassigned traffic can also come from specific pages on your site. You can test this by adding a new dimension called ‘Page path and screen name’ in your traffic acquisition report in GA4. In the search bar above, you can type “unassigned” to view all pages where unassigned traffic is found.
This will help you identify which pages are causing all your unassigned traffic. For example, if search-based event tags are firing before the Google Tag on a site’s search results page, this could result in unassigned traffic on those specific pages.
If purchases in your marketing platforms aren’t being attributed to campaigns, and you see that every purchase event in GA4 is assigned to unassigned, it may be that you aren’t sending marketing information with your conversion webhooks. This marketing information is crucial for properly attributing purchases to the correct channels/sources.
Follow these steps to check a purchase via webhooks in the server container preview mode: Testing webhooks in sGTM preview mode
If you aren’t sending marketing information, pause the webhook tags on the server container and remove the condition in the GA4 and Meta triggers that the event name must not contain purchase.
This helpdesk article is based on our own support input. If you encounter other problems not covered here, please let us know via the chat function in the bottom left corner or by emailing us at support@adpage.io.
Do GTM triggers work properly with your CMP?
When you set up the cookie banner and configure the consent overview settings correctly, the first page visits may no longer be measured accurately. During these first page visits, UTM parameters from your visitors are recorded. The second page visit may then be considered the first page visit. This occurs because the Google Tag and page_view event tags are often set to fire on Initialization or All Pages. However, visitor consent updates happen after this step, causing the Google Tag and the GA4 page_view event tag to not fully trigger due to GTM’s Built-In Consent Checks. Therefore, when the visitor updates their consent, the Google Tag and page_view event tags need to be fired again or for the first time.
Solution:
Resolve this issue by following the steps in this article: Triggering consent updates correctly
Are server cookies regenerated after updating consent in a Cookiebot banner?
Are you using Cookiebot? Then you have the option to specify under which category each cookie falls. Certain cookies placed by the server are crucial for recognizing a user, such as session_id, client_id, and user_id. However, these are not always considered ‘Necessary’ cookies by Cookiebot, requiring them to be regenerated when a new user accepts the cookies via the cookie banner. This mismatch can cause user information on the first page of session one to differ from the user information on the second page of session one. Follow the steps below to check if this problem is occurring for you.
Install a DataLayer checker extension in your browser. We recommend this one for Google Chrome users: DataLayer Checker
Ensure that this extension also works in an incognito window/private mode.
Now open an incognito window/private mode and go to your site.
Use your DataLayer Checker to view the information from the trytagging_user_data/sld_user_data event. Click on the ‘json’ button in the DataLayer Checker to see the following:
Take a screenshot of your user_id, client_id, session_id, and session_count.
Now accept all cookies and navigate to the next page.
On this second page, open the trytagging_user_data/sld_user_data event in the DataLayer Checker again by clicking on the ‘json’ button.
Compare whether your user_id, client_id, session_id, and session_count match the values from the first page where you took a screenshot.
If any of these IDs differ, you need to perform the steps below.
Solution:
Resolve this issue by following the steps in this article: Set server cookies as necessary via Cookiebot
Are the tags triggered before or after the user_data event in the DataLayer?
The trytagging_user_data/sld_user_data event in the DataLayer contains the marketing and user information from which Google Tag Manager retrieves user data. If you trigger the Google Tag or the GA4 event tags before this event occurs, you may miss important data. This can cause errors, such as users and their sessions not being properly transmitted to marketing and analytics platforms, leading to unassigned events in GA4.
Solution:
Replace all your Initialization or Page View triggers with the user_data trigger.
Ensure that all other event tag triggers fire after the Google Tag trigger, meaning after the user_data trigger.
You can do this using a trigger group:
Is the Google Tag triggered first?
If the Google Tag is fired after a GA4 event tag, your tracking setup is not ideally configured. The Google Tag must fire before the GA4 event tags. You can check this by looking at the order of triggers. For example, does the Google Tag trigger on All Pages - Page View, while the GA4 event tag for page_view triggers on Initialization? If so, you need to adjust this.
If the triggers for the Google Tag and other GA4 event tags are set to the same trigger, you will need to use the tag priority settings. The higher the tag priority number, the earlier it will fire. For example, set the Google Tag to “1000” and the GA4 event tag for page_view to a lower number.
Are you seeing traffic spikes while using Cookiebot?
If you use Cookiebot on your website, a large amount of traffic may appear in your Google Analytics property. This is normal behavior, as the Cookiebot scanner visits every page of the website to determine which cookies/trackers are used.
Solution:
Perform the following steps: Exclude Cookiebot data from GA4
Are you receiving events from other (sub)domains?
If you see too much data in GA4 compared to reality, or if you notice a large percentage of unassigned traffic, it may be that you are still collecting data from an old or different (sub)domain. You can test this by adding a new dimension called ‘Hostname’ to a GA4 report.
Are specific pages causing issues?
In addition to receiving events from another (sub)domain, specific problems like unassigned traffic can also come from specific pages on your site. You can test this by adding a new dimension called ‘Page path and screen name’ in your traffic acquisition report in GA4. In the search bar above, you can type “unassigned” to view all pages where unassigned traffic is found.
This will help you identify which pages are causing all your unassigned traffic. For example, if search-based event tags are firing before the Google Tag on a site’s search results page, this could result in unassigned traffic on those specific pages.
Are you sending marketing information with the webhooks?
If purchases in your marketing platforms aren’t being attributed to campaigns, and you see that every purchase event in GA4 is assigned to unassigned, it may be that you aren’t sending marketing information with your conversion webhooks. This marketing information is crucial for properly attributing purchases to the correct channels/sources.
Follow these steps to check a purchase via webhooks in the server container preview mode: Testing webhooks in sGTM preview mode
If you aren’t sending marketing information, pause the webhook tags on the server container and remove the condition in the GA4 and Meta triggers that the event name must not contain purchase.
Updated on: 21/08/2024
Thank you!