Server-side Tag Manager is essentially a proxy between the user’s device and the vendor or endpoint used to collect data. With server-side GTM in place, you have full control over anything sent forward from the server. For example, personal data such as IP addresses are not forwarded to the vendors unless you specifically choose to do so.
However, some features in analytics tools require access to IP addresses. For example, Google Analytics uses IP addresses to determine the visitors’ geolocation and filter out internal traffic. Once the IP addresses are not available to GA anymore, these features will also stop working.
This article will show how to set up the internal IP exclusion filters in Server-side Tag Manager instead. The additional benefit is that the same filters will also be available for any other tag type than GA.
IP filter variable template
Server-side GTM handles incoming server requests and can trigger new outbound requests based on those. The IP address from which the incoming request originates is typically available in the X-Forwarded-For request header.
I’ve created a custom variable template to make it easier to list all excluded IP addresses or IP address patterns. This template provides a similar UI as the internal traffic rules in GA4. If one of the IP addresses or patterns on the list matches the originating IP, the variable will return true.
The template supports these match types:
For more information on how the template works, you can check the related GitHub repository.
Installing the template
You can find the variable template from the Tag Manager template gallery. First, head to variables, and click the New button to create a new one. Next, browse for more templates from the Community Template Gallery and add the IP Address Match template to the workspace in GTM.
After that, save the template, and it’s ready to use. Next, you can create a new variable that lists the patterns for all internal IP addresses to be excluded.
Blocking tags from firing
Next, you can create a blocking trigger that prevents all related tags from firing if the request comes from an internal IP address. Select the Custom trigger type and set it to fire on “Some Events.” In the trigger’s conditions, set it to fire on all events where the new IP exclusion variable equals true.
Next, include the trigger as an exception with all tags that should not fire for internal traffic.
Finally, you can test the functionality by using the GTM preview mode and including your own IP address on the list. The blocked tags’ details should look like this on the preview mode:
IP filtering with GA4 traffic type
Using a blocking trigger prevents the outgoing request from being sent at all. With GA4, another option for filtering out internal traffic is to use the traffic_type parameter. This way, the outgoing request is sent forward, and GA4 does the filtering once it receives the event. In GA4, you could first run the filter with test mode or flag it as developer traffic instead to enable debug view.
There’s a slight difference between the server-side and client-side Tag Managers in how the traffic type is declared: In server-side GTM’s event data model, the parameter name used is x-ga-mp2-tt instead of traffic_type.
You can use a lookup variable to set x-ga-mp2-tt. After the change, you’ll need to configure the GA4 property’s data filters accordingly.
The server-side GTM container handles incoming server requests and knows from which IP addresses they originate. Therefore, you can set up an IP exclusion filter inside the server-side container to prevent outgoing requests from being triggered for internal traffic. Furthermore, you can extend this same filter to apply to any tag, not just Google Analytics.
One consideration is that the blocking trigger prevents the outgoing requests with little trace of what happened. So it might be a good idea to set up some kind of monitoring to track how the IP filter is working. For example, you could use the same trigger and the BigQuery streaming insert API to build a simple monitor that logs all the blocked IPs or anonymized IPs for further analysis.