Within your TAGGRS container, locate the product ID and copy it.
Visit the GTM template gallery to find the TAGGRS tags you need. Choose the access method you prefer:
If you choose the live version, follow the instructions sent to you via email. If you prefer to use the JSON file, instead, follow the steps outlined below.
Now that the tag file has been downloaded, you can start uploading the tag on Google Tag Manager. Go to your web container. Within your workspace, click to Templates and click New under tag templates.
Then click on the 3 dots at the top right and click Import.
Make sure the downloaded zip file is extracted, you do this by opening the file.
Once this is done you can upload the file to Google Tag Manager. As shown in the example below you only need to upload template.tpl. Then click Save and the TAGGRS tracking tag - client side is uploaded and ready to use.
Before setting up TAGGRS Tracking Tags, we need to create a trigger. This trigger will ensure that all events are taken and forwarded to TAGGRS, giving you the most insight into the actual data difference. We differentiate between several events including:
Go to the client container in Google Tag Manager. Within your workspace, go to Triggers, then click New.
Give the trigger a name such as GA4 - All events and choose Custom event as the trigger type under Trigger configuration.
Under event name, enter .*. Then check Use matching regular expression. Under This trigger is triggered for, select All custom events. Then save the trigger.
Now that we have created the trigger, we are going to create and set up the TAGGRS Tracking Tag. Go to the web container in Google Tag Manager. Within your workspace, go to Tags and then click New.
Click on Tag configuration. Then under Custom, click the client-side tracking tag of TAGGRS.
Under Identifier, enter the Product ID you copied from your container in the TAGGRS dashboard. Then click on the + at Event name and select Event.
We want to measure the data on all pages and events to properly show the difference in data. As a trigger, choose the GA4 All events trigger you just created. Then give the tag a name and click Save.
All events in the data layer are now integrated. If you want to track additional events, such as form submissions, you need to create a specific tracking tag for this. Then choose the desired event as the trigger for this tag.
The events are now passed client side to TAGGRS. To measure the difference in data we need to start doing the same for the server side. This works the same way as the client side tag.
Go to the server container in Google Tag Manager. Within your workspace, go to Tags, then click New.
Like the client side tracking tag, the server side tracking tag must be downloaded from GitHub and uploaded to Google Tag Manager. To do this, follow the same steps as the client side tracking tag, but now download the server side tracking tag.
Once it is uploaded on Google Tag Manager, we can start installing the tag. Click on Tag configuration. Then under Custom, click on TAGGRS server-side tracking tag.
As with the client side tracking tag, enter the product ID under Identifier. Then select Event Name under Event name.
Next, we're going to set the trigger. Not using consent mode? Choose GA4 Client as the trigger.
Do you use consent mode? Then add the trigger GA4 Client + Analytics storage. This way you will comply with the consent rules and avoid large data differences within the TAGGRS dashboard.
Then give the tag a name and click Save. Don't see GA4 Client listed? Check out this blog to create a GA4 tag with associated trigger in the server container. Once set up, the trigger will appear.
Successful? Nice going! Now go to your container within TAGGRS. The effects of Server Side Tagging are now measured per event, top!
If you already see a positive difference and want to increase it further:
• Implement the Enhanced Tracking Script. It improves client-side resilience against advanced ad blockers (≈1–2% uplift)
• Enable Cookie Recovery. It restores tracking cookies removed by Safari and iOS. Mind: it requires the Enhanced Tracking Script.
• Use Webhooks for critical events.
It ensures purchases are tracked even if users close payment flows early. Please mind that it is not not suitable for Google Ads (no GCLID support).
A negative data difference means that fewer events are received server-side than client-side. This is usually caused by configuration issues rather than TAGGRS itself. Below are the 6 most common causes, ordered from most to least frequent, along with practical guidance on how to identify and resolve them.
Many websites have evolved over time and often contain old GA or GA4 scripts, direct Google Analytics integrations, plugins that inject tracking code, and a Google tag configured outside GTM. When this happens, client-side data is sent multiple times, while only one stream reaches the server container. If you see more than two “container loaded” blockchain your GTM Preview mode for the web container, extra tracking is active.
How to fix:
1. Remove legacy GA / gtag scripts
2. Ensure GA4 is implemented only via GTM
3. Use one single Google tag as the data source.
Some cookie banner solutions block tracking requests selectively. In certain setups, the client-side tracking tag still fires and the GA4 / Google tag request to the server container is blocked until consent is given. This results in client-side data being collected while Server-side Tracking is suppressed.
Common scenario:
• You browse the site before accepting cookies
• Client-side TAGGRS tracking fires
• Server-side data does not arrive
How to fix:
1. Configure Consent Mode v2 correctly in the web container
2. Ensure that analytics storage consent is aligned for client-side TAGGRS tracking tag and server-side TAGGRS tracking tag.
Mind: disabling automatic cookie blocking may solve the issue but is not compliant with privacy regulations.
In some cases, GTM is loaded multiple times: 1x manually in the code and 1x via a CMS or plugin. This can disrupt event flow and data forwarding to the server container.
How to detect:
Right-click → Inspect → search for GTM-. If you find the same container ID twice, one must be removed.
Ad blockers can sometimes block the request from the web container to the server container, even if server-side tracking itself is functioning. It happens when client-side tracking still works and fewer events reach the server container.
The data difference decreases
This effect is usually small but noticeable in the TAGGRS dashboard.
Mitigation:
1. Use the Enhanced Tracking Script
2. Enable the anti-adblocker option to reduce request blocking.
If GA4 is implemented outside of GTM (for example via a plugin), some requests may bypass Google Tag Manager entirely. As a result: not all events are forwarded to the server container and Server-side Tracking receives fewer events than expected.
How to check
1. Inspect the page source for gtag( calls
2. Look for GA4 plugins in your CMS
3. Verify that GA4 is routed exclusively through GTM.
When using Consent Mode v2, consent settings must be consistent on both sides.
A common mistake? Analytics storage is added to the server-side tracking tag but not applied to the client-side tracking tag (or vice versa). This mismatch can result in client-side events firing and/or server-side events being blocked.
Best practice:
1. Apply analytics storage consent to both client-side TAGGRS tracking tag and server-side TAGGRS tracking tag.
2. Use the trigger GA4 Client + analytics storage in the server container.
If only page_view appears, the trigger is likely set to All Pages instead of All Events.
You can fix it by updating the trigger to use Custom Event with regex .*
Most common reasons:
• Consent mode active in web container but not in server container
• Duplicate events added directly in GA4
• Server-side Tracking tag firing without a specific GA4 client
• Additional direct GA4 integration bypassing GTM.
Always specify GA4 Client in server-side triggers.
Check the following in order:
1. Both containers are published
2. Tracking tags exist in both containers
3. DNS is validated in TAGGRS
server_container_url is set in the Google tag
4. No SSL or 502 errors on the subdomain
5. CSP allows GTM and the server-side subdomain
6. No duplicate GTM or gtag scripts
7. Triggers are correctly configured.
Possible causes are:
• Fewer than 10 events recorded (minimum threshold)
• Data processing delay (up to 30 minutes)
• Incorrect trigger configuration
Use GTM Preview mode to verify that both tracking tags fire correctly.
We use the info for statistics for our TAGGRS Server Side Analytics. So for Consent Mode V2 you can use statistics as Consent State for our tracking tags.
There may be a delay of up to 48 hours before changes are fully processed and displayed correctly on the dashboard.
