How to Exclude Internal Traffic in Google Analytics 4

Important: Some weird things. A delay?

While I writing this blog post, I did various experiments with filters in GA4 to understand how they work (because not every scenario is clearly explained in Google’s documentation).

The weird things started when sometimes, the same experiment (repeated several times) ended up with different results, thus trying to dig deeper was indeed very frustrating. Eventually, I came to the conclusion that there is some delay between editing/changing the filter and what you see in the DebugView.

For example, even 10 minutes after I deactivated the internal traffic filter, I still could not see my own events in the DebugView (until I changed my IP address).

So, this blog post is a result of various experiments and I hope I did that right. If you notice anything incorrect, please let me know.

There is always a chance that something was just not properly working in GA4 at that moment and maybe in the future (when you are reading this), this got resolved.

The problem with the Internal Traffic Filter in GA4

If you have ever tried to exclude internal traffic in Google Analytics 4, you have probably already found pages explaining how to use the Internal Traffic Filter. You can just go to your Admin > Data Streams > X Data Stream > Tagging Settings > Define Internal Traffic and then you enter your IP addresses.

Then you go to Admin > Data Settings > Data Filters > Internal Traffic and set it to Active.

Done, you have excluded your internal traffic based on IP addresses. But there’s one catch.

What if you want to exclude your internal traffic (including your own) but when you debug the GA/GTM setup, you’d still like to see yourself in the DebugView of GA4? With your current setup, that is not possible. You just won’t see yourself in the DebugView. At least, that’s what was happening to me.

One option here could be to create a separate GA4 property for testing and then (if you are in the preview mode) you could create a Lookup Table variable that picks the right property. If you’re in the Preview mode, then you send data to the testing property. If you’re not debugging, the data flows to the live property.

And there’s another option that I’m going to show you. It will involve a single (live) GA4 property. If you are not debugging, your data will be excluded. But if you are debugging (with GTM’s preview mode), then your data will be visible in the DebugView (but not standard reports). Thus, you are not going to litter your data collection.

How Internal Traffic Filter works

One last thing before we actually dive into the techniques/setup.

When you define your internal traffic (in the tagging settings of a Data Stream), Google Analytics 4 tracking code (activated on your site) starts adding an additional parameter tt=internal to every request. This parameter means “traffic type” a.k.a. traffic_type.

The default Internal Traffic Filter (that can be found in Admin > Data Settings > Data Filters) is preconfigured to exclude all the hits that contain the traffic_type=internal parameter (a.k.a. tt=internal). And it will do that once you set the filter to “Active”.

So, in this blog post, I’ll explain how to use that traffic_type=internal parameter and exclude internal traffic in GA4. But if someone is debugging with GTM’s preview and debug mode, then traffic_type’s value will be different and you would still see it in the DebugView.

Method #1 – excluding internal traffic by IP address

Let’s start with the classic. This might work if not many people are involved in running a business and you can easily exclude their hits by their IP addresses. This method does not work well if you have to enter a lot of different IP addresses or some IP addresses are not static (read: regularly changing).

Step #1. Define your internal IP addresses

In Google Analytics 4, go to Admin > Data Streams and select your website stream.

Then click Tagging Options:

And select Define internal traffic. Here you can create new internal traffic rules. If you are working with multiple IPs, you can create separate rules for each IP. I really hope, that in the future, regular expressions will be supported here as well.

To make things simple, you can always enter “internal” in the traffic_type value field. Then it will be enough to just have one Internal Traffic filter in the Data Settings of your GA property.

If you don’t know what is your IP address, click the link on the right side.

Step #2. Create a developer filter in GA4

You might be wondering what is the difference between a developer filter and an internal traffic filter in GA4. Both of them exclude data from the regular reports in GA4 (by checking different parameters).

The developer filter is checking the debug_mode or debug_event parameters while the internal traffic filter is looking for traffic_type.

But the key difference here is that you can see developer traffic in the DebugView of GA4 while the internal traffic is not displayed anywhere. And if your hits to GA contain both the debug_mode and traffic_type=internal, then the internal traffic parameter gets a higher priority and you won’t be able to see your hits in the DebugView.

So what can we do here? I’ll answer that in the next chapter. But first, let’s create a developer filter (because it’s is not ready by default). In GA4, go to  Admin > Data Settings > Data Filters > Create Filter. Select Developer Traffic. Enter the following settings:

You can enter any name in the “Data Filter Name” field. Set this filter to Testing (for now). Save it.

Step #3. Create a lookup table in GTM to override the traffic_type parameter

This is where the magic will happen. If you remember, in one of the previous chapters, I mentioned that GA4 automatically adds a tt=internal (traffic_type) parameter to all hits if they are coming from one of your internal IP addresses.

What we are going to do is to create a Lookup table variable that manipulates the value of the parameter. If we have the GTM preview mode enabled, then we will change the tt’s value to developer (or anything else). But if the Debug Mode is disabled, then we will not do any modifications and let the GA4 handle this.

First, create an Undefined variable. In GTM, go to Variables > New > Undefined and save the variable (its name can be, well, Undefined).

Now, let’s go to Variables > Customize (in the Built-in variables section) and enable the Debug Mode variable.

Finally, let’s go to Variables > New > Lookup table and enter the following settings:

Here we are using the Debug Mode variable as an input. If the GTM preview mode is enabled, this variable will return true, therefore, the lookup table variable will return the word “developer”. If GTM Preview mode is not being used, the Debug Mode variable will return false, therefore, we will return undefined. That’s why we created the Undefined variable.

This is not the same as just entering “undefined” in the field. In JavaScript, “undefined” surrounded by quotation marks is a string (text). But undefined means no value. If you just enter the word undefined in the Lookup table, that is a string.

Save the variable.

Finally, go to your Google Analytics 4 configuration tag and enter the following parameter: traffic_type. And its value should be the lookup table you’ve just created.

Step #4. Test the filters

Now, it’s time to test. Enable GTM’s preview mode. And go to your website (obviously, you should be browsing from the IP address that is configured in the Internal Traffic section of your Data Stream). Go to the DebugView of GA4.

First of all, you should still be seeing hits coming from your device. Click on any event in the event stream and check the parameter traffic_type. Its value should be developer.

Also, in that very same event, you should see the Debug Mode parameter too.

Remember: both filters (developer and internal) are not active yet. They are in the testing mode, which means that the soon-to-be-excluded data is still visible in the regular GA reports.  When filters are in the testing mode, an additional dimension is added to them called Test data filter name. You can use it as a secondary dimension (or in Analysis Hub) to check how much of the data would have been excluded if the filters were active. You can also more learn about the filters here.

Step #5. Activate both filters

The last step is to activate both filters. Go to Admin (in GA) > Data Settings > Data Filters and set both triggers (Internal traffic and developer traffic) to active. You can do that by opening each filter, changing their Filter state, and then saving the changes. Or you can just activate them from the list:

Now do the test once again.

• Browse from the IP address that is defined as Internal
• Have the GTM preview mode disabled. Browse your website (to send some events to GA4)
• Check the DebugView. You should not be able to find your device and see new events coming from it.
• Now enable GTM’s preview mode. Browse the website once again.
• Check the DebugView. You should now be able to find your device and start seeing some data.

<script>
  window.dataLayer = window.dataLayer || [];
  window.dataLayer.push({
    'event': 'traffic_type',
    'traffic_type': 'internal'
  });
</script>

<script>
 
 var cookieName = "gtm_internal_user"; // Name of your cookie
 var cookieValue = "true"; // Value of your cookie
 var expirationTime = 31104000; // One year in seconds
 expirationTime = expirationTime * 1000; // Converts expirationtime to milliseconds
 var date = new Date(); 
 var dateTimeNow = date.getTime(); 

 date.setTime(dateTimeNow + expirationTime); // Sets expiration time (Time now + one month)
 var date = date.toUTCString(); // Converts milliseconds to UTC time string
 document.cookie = cookieName+"="+cookieValue+"; SameSite=None; Secure; expires="+date+"; path=/; domain=." + location.hostname.replace(/^www./i, ""); // Sets cookie for all subdomains

</script>