Have you installed the tracking tags, but no requests are coming in? This can have several causes. Below, we listed 7 ranked from the most to the least likely.
The most common reason for not receiving data is failing to publish the containers. Ensure you publish both containers (the web container and the server container) once you've finished setting them up.
Server Side Tracking works best on your own subdomain. If you chose this option in the setup process, always validate the DNS in TAGGRS. Do this by clicking the Validate button in the container.
If you haven't correctly processed the DNS settings and are using TAGGRS's enhanced tracking script, no data will come into the account.
Even after validating the DNS and publishing the GTM containers, data might still not come in. A reason could be the lack of tracking codes installed on the website. You can use two methods for this:
If you opt for the enhanced tracking script, there's an extra step to correctly send the data: adding a web container client in the server container.
This is explained in this manual.
If a developer accidentally changes something in the DNS settings, you might get an SSL error on the subdomain.
This error only causes a complete loss of data if you've also installed the enhanced tracking script. In this case, ask the developer to check if the DNS settings of your container still match the current settings.You can also check it yourself by going to mx toolbox, then selecting DNS Lookup, entering your subdomain, and you will see the DNS settings of your subdomain. Make sure the IP Address (A type) matches the one in the TAGGRS Dashboard. The IPV6 Address (AAAA type) should be empty. If this is not the case as in the example below, you will need to remove them within your hosting. This varies by hosting. Therefore, you will need to contact your hosting provider.
To fix issues where a Content Security Policy (CSP) blocks Google Tag Manager (GTM) or your server-side container's subdomain, update the CSP to allow the necessary domains and scripts. Add https://www.googletagmanager.com and https://subdomain.yourdomain.com to the script-src and connect-src directives of your CSP. Test the changes in a safe environment to ensure GTM and your server-side container work correctly, and monitor your site for any CSP errors post-implementation.
More info? Check out the Google official documentation.
Google Tag has a feature to prevent duplicate tracking. If duplicate tracking codes are in the code, this setting might block one of them. If you manage a Google Tag from GTM and have a code directly sending data to GA4, the Google Tag in GTM might be seen as duplicate tracking.
In this case, it will be blocked, and the Google Tag won't send data to the server container.
Check this by going to ‘manage your Google tag’ in the admin settings and disabling the setting. Then test in preview mode to see if data now comes through.
If it does, we recommend removing the other gtag script from the code and managing all tracking via GTM.
You have created an account with TAGGRS and started with Server Side Tracking. After configuration, the requests are coming in, but you notice a spike in the statistics on the TAGGRS dashboard.
Here are the 2 most common reasons for spikes in your TAGGRS dashboard's request graph, ranked from most to least common:
There is no way to prevent these scans, but you can exclude this traffic from your regular website statistics by either excluding the provider Microsoft Corporation or by excluding the IP addresses we scan from:
It is crucial to exclude these before they reach the server container; otherwise, they still be counted as requests in TAGGRS.
If no graph is visible in your TAGGRS dashboard, the TAGGRS Tracking Tags may not be installed. These tags collect and visualize your data.
Want to know how to install these tags? Read our documentation manual to get the full process.
You have installed the tracking tags, and the message 'data is being collected' remains for more than 5 minutes. This can have various causes.
Figure out the possible reasons by reading our support guide.
Do you notice a negative difference in your data after implementing TAGGRS Tracking Tags? This may indicate discrepancies in data collection.
Check out our support guide for more information and solutions.
After installing TAGGRS Tracking Tags, no web or server line is visible. This can have multiple causes.
Click the support guide for the solution.
You notice an upward trend in your measured data. Do you want to further optimize this and achieve better results?
View the article for tips to increase this difference. Click the button below for details.
After installing the TAGGRS tracking tags, you notice an unrealistically high data discrepancy of more than 60%.
View the support guide for the main causes. Click the button below for more information.
Here are 4 possible causes and the fixes you can perform.
In Google Tag Manager, set the web container trigger to initialization instead of all pages. This ensures the ‘allpages’ trigger is called before the events, avoiding concurrent triggers which can lead to issues like the Unassigned GA4 Traffic.
Note: this solution only works if you have configured Consent Mode V2. For Google tags with automatic consent management, adjust the Additional Consent Checks setting to 'no additional consent required' instead of 'not set'. By doing this, you specifically indicate which tags do not require an extra consent setting. This reduces the amount of unassigned traffic (not set) data within Google Tag Manager.
This only applies to tags where consent is managed automatically! For tags where this is not the case, for example, with Facebook, you should leave the additional consent unchanged.
In the server container, you can update the Cookies and Client Identification System as an alternative solution to address unassigned traffic in GA4. To do this, navigate to 'Clients' -> 'GA4', and click on 'More Settings'. Locate the 'Cookies and Client Identification' section and change the setting from 'Server Managed' to 'JavaScript Managed'.This change modifies how attribution is measured and often resolves the issue of unassigned traffic. While it is not guaranteed to work in all cases, it is a highly effective solution in most scenarios.
Place this inline script as high as possible in the <head>, before Cookiebot and your GTM container:
<script>
window.dataLayer = window.dataLayer || [];
window.dataLayer.push({
event: 'storeInitialReferrer',
initialReferrer: document.referrer
});
</script>This ensures the document.referrer is stored in the dataLayer before it is lost.
2. Create a Data Layer Variable in GTM
• In Google Tag Manager, go to Variables → New → Data Layer Variable
• Name it: DLV - Initial Referrer
• Set Data Layer Variable Name to: storeInitialReferrerSave
•
3. Use the Referrer in GA4 Tags
When firing your GA4 tag (after consent), do one of the following:
Option A: Send it as a Custom Dimension
In your GA4 Event Tag, add a parameter:• Name: initial_referrerValue:
• {{DLV - Initial Referrer}}In GA4 admin, register initial_referrer as a custom dimension.
Option B: Override page_referrerIf you want to overwrite the default referrer:
• Go to the GA4 tag → Advanced Settings → Fields to Set
• Field Name: page_referrerValue:
• {{DLV - Initial Referrer}}
If you do not set up Consent Mode (V2) correctly, it can lead to the loss of valuable data, as tags are not activated when cookies are declined.
With a correct setup of Consent Mode (V2), you can still collect valuable data, even without full cookie consent. Read our documentation guide.
The heart of the problem lies in the Client Name not aligning with the trigger set for the configuration tag. For the GA4 configuration tag to be properly triggered, the Client Name must exactly match the name specified in the trigger conditions.
To resolve this, you must ensure that the Client Name is correctly matched with the trigger of the configuration tag. This means that the condition (Client name equals [name of the client]) must be accurately fulfilled for the GA4 configuration tag to activate.
Here you will find solutions for error messages during debugging in the server container after all tags and triggers have been configured.
Read our support article for causes and solutions.
Failure to set up Consent Mode (V2) properly can result in the loss of a lot of valuable data. This is often because when a visitor does not agree to certain cookies, the related tags are not activated.
If you set up Consent Mode (V2) correctly, you can still access valuable data even without full consent for the cookies. Read our support manual to learn more.
You might encounter a scenario where your server container doesn't receive incoming requests while using Cookieyes. Let’s navigate through the potential cause and its solution to swiftly rectify this situation.
The primary reason your server container might be missing incoming requests is a specific setting within Cookieyes. In its advanced settings, you’ll find an option named Allow Google tags before consent. If this feature is turned off, your server container will not properly receive incoming requests.
How to fix it in 2 steps:
3.3.1 Enable Google Tags Before Consent
Head over to the advanced settings in your Cookieyes account. Look for the "Allow Google tags before consent" option. Activating this setting allows Google tags to load prior to obtaining user consent, which, in turn, ensures your server container starts receiving the incoming requests as intended.
3.3.2 Confirm changes and test
After adjusting this setting, ensure that changes are saved and then test to confirm that your server container is now receiving requests. This can usually be verified by observing the incoming request logs within your TAGGRS dashboard.
When you click preview mode in the server container you might encounter the error that you cannot preview this container.
You can resolve this error by going to Edit Container Settings. Under Server container URLs, add your subdomain including https://. Once you have done this you can start using preview mode.
If you encounter the message This site can't provide a secure connection it probably means that DNS has not been validated within TAGGRS as shown in the picture below. So make sure your DNS is validated.
When testing a page in the preview mode of the server container you receive a 404 error.
Solution: Within the container settings, your current domain is listed. Here, the subdomain of TAGGRS should be specified; otherwise, you may encounter a 404 error.
When you get the message There is no summary for Requests when opening the server container it probably means that the data is not coming in to the server container. The cause of this is probably that there is another GTM script (hardcoded or by plugin) on the website hijacking this requests which causes the request not to come in. You need to remove this script and then most likely the data will come in to the server container.
When setting up Server Side Tracking for your Magento 2 website, you might encounter an issue where no requests are reaching the server container. This problem often arises due to a CORS (Cross-Origin Resource Sharing) rule in Magento, which can block outgoing requests from your hosting.
Magento 2 implements CORS rules as a security measure to prevent cross-site scripting attacks. This means it restricts how resources on a web page can be requested from another domain than the one from which the first resource was served. Essentially, if your Magento hosting is blocking outgoing requests, it's likely due to these CORS rules.
To check if you have a CORS Error, go to your website -> Inspect -> Network tab. Search for your subdomain. If you see Script Origin When Cross Origin then you have a CORS Error.
To resolve this, adjust your web hosting's .htaccess file by adding:<IfModule mod_headers.c>
Header add Access-Control-Allow-Origin "https://*.yourdomain.com"</IfModule>
Make sure to replace "https://*.yourdomain.com" with your actual (top level) domain. This adjustment ensures that requests from your subdomain are permitted, bypassing the CORS restrictions that might be in place.
More info: thread on CORS policy.
By methodically following these steps, you should be able to resolve the no-request issue in your Magento 2 setup for Server-side Tracking. If the problem persists, reviewing the policy directives might provide insight into which domains are allowed and which are not, allowing for further troubleshooting.
Has the number of Google Ads Remarketing audiences decreased after implementing Server Side Tracking or Consent Mode V2?
View the article for causes and solutions.
After implementing Server Side Tracking via TAGGRS, error messages may appear in the browser console. These errors are often harmless or easy to resolve.
Read the support guide for possible error messages and solutions.
