IP filtering in server-side GTM

IP Exclusion Filtering in Server-side Tag Manager

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.

IP address exposure when sending events directly to from client to vendor
When sending events directly from client to vendor, the client’s IP is exposed.
IP address exposure when sending events with server-side GTM as a proxy server
With server-side GTM as a proxy, the client’s IP is not visible to the vendor server.

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.

Server-side GTM IP filter variable

The template supports these match types:

  1. equals
  2. contains
  3. starts with
  4. begins with
  5. CIDR range with IPv4 addresses, based on this code
  6. Regex

The Regex match is a simple match based on the String.match() function in JavaScript.

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.

IP Address Match template in GTM template gallery

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.

Blocking trigger for internal IP addresses
The trigger matches any event that came from an excluded IP.

Next, include the trigger as an exception with all tags that should not fire for internal traffic.

Adding a blocking trigger to a tag's exceptions

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:

Server-side GTM preview with a tag that's been blocked by a blocking trigger

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.

GA4 traffic_type lookup variable
Return “internal” as the traffic_type when the IP address is excluded.
GA4 traffic_type tag configuration
Set the traffic_type using the x-ga-mp2-tt parameter.

Summary

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.

4 thoughts on “IP Exclusion Filtering in Server-side Tag Manager”

  1. Sorry, my fault. I importet it to the web container. Server-Container has it.

    My problem was that cookiebot generatet lots of requests on my stape server, which ruins my limits, as every hit counts. Wanted to exclude it before it creates a hit, but that seems not to work

  2. Hi,

    I just used your template, and it works fine. Just a question, why do you want to use an exception trigger when you can add a rule to the positive trigger where the IP variable value is “false”?

    1. Avatar photo
      Taneli Salonen

      Hi,

      That’s my personal preference, but of course the other way around works too.

      I find the blocking trigger easier to manage as it’s visible on all tags where I’ve included it. If I included the rule in all “positive triggers” then it would be difficult to keep track that all triggers actually include the rule.

Leave a Comment

Your email address will not be published. Required fields are marked *

Scroll to Top