How to Exclude Internal Traffic in Google Analytics 4

Updated: March 30th, 2025

When you implement Google Analytics 4, you are tracking your own interactions/events as well. That’s the default. That becomes an even larger problem when working with a larger business (having more employees). Every visit/event made by an employee skews your data. Luckily, this can be fixed because you can exclude internal traffic in Google Analytics 4.

But there are several catches here. If you exclude yourself, you won’t be able to see your events in the DebugView (while testing with GTM). GA4 documentation says it should work fine with the developer filter, but the reality is different. At least when I am writing this article.

And if you have to exclude multiple people, relying on the IP address might not be the best option. In this blog post, I wanted to show you how to exclude internal traffic in Google Analytics 4 and tackle the aforementioned two problems.

However, the IP-related option will also be described.

Table of contents

– Here’s what you will learn in this article –

• The limitation with the Internal Traffic Filter in GA4
• How the Internal Traffic Filter works
• Warning for the users of GTM server-side tagging
• Method #1 – excluding internal traffic by IP address
  • #1. Define your internal IP addresses
  • #2. Create a developer filter in GA4
  • #3. Create a lookup table in GTM
  • #4. Test the filters
  • #5. Activate both filters
• Method #2 – excluding internal traffic with the data layer
  • #1. Getting the internal data parameter into the Data Layer
  • #2. Create a developer filter in GA4
  • #3. Create a lookup table in GTM
  • #4. Test the filters
  • #5. Activate both filters
• Method #3 – excluding internal traffic based on a cookie
  • #1. Set a cookie for internal users
  • #2. Cookie variable
  • #3. Create a developer filter in GA4
  • #3. Create a lookup table in GTM
  • #4. Test the filters
  • #5. Activate both filters
• Send internal data to a separate GA4 property
• Final words

Video tutorial

Prefer video content? Here’s a tutorial from my Youtube channel. If you want to stay up-to-date with GA4, consider subscribing.

Important: Some weird things. A delay?

While 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) yielded different results. Thus, trying to dig deeper was indeed very frustrating. Eventually, I concluded there is some delay between editing/changing the filter and what you see in the DebugView.

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

So, this blog post results from 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 not working properly in GA4 at that moment, and maybe in the future (when you are reading this), this got resolved.

The limitation of 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 go to your Admin > Data Streams > X Data Stream > Configure tag settings > Show all > Define Internal Traffic, and then you enter your IP addresses.

Then, go to Admin > 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 won’t see yourself in the DebugView. At least, that’s what was happening to me.

Update: after some time, it looked like things were improving in GA4, but now this problem is repeating again.

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, 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), your data will be visible in the DebugView.

How Internal Traffic Filter works

When you define internal traffic (in the tagging settings of a Data Stream), Google Analytics 4 tracking code (activated on your site) starts adding a 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 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 will still see it in the DebugView.

Warning to users of GTM server-side tagging

It looks like the built-in GA4 exclusion of internal traffic does not properly work with GTM server-side tagging. The traffic_type=internal parameter is not added to GA4 requests if requests are sent to your server-side setup first.

At least, that’s what I am seeing. This means that you would need to build the exclusion logic yourself in the GTM server (for example, set the tags to not fire if the user’s IP address matches/contains some value.

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 many different IP addresses or if some IP addresses are not static (read: regularly changing). Or maybe your colleagues use VPNs often.

Step #1. Define your internal IP addresses

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

Then click Configure tag settings:

Then click Show all and select Define internal traffic. Here you can create new internal traffic rules.

You can create separate rules for each IP if you are working with multiple IPs. Or you can create a regular expression and include multiple IP addresses there, like in the example below:

You can always enter “internal” in the traffic_type value field to simplify things. Then it will be enough to have one Internal Traffic filter in your GA property.

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

Step #2. Create a developer filter in GA4

You might wonder what the difference is 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 checks the debug_mode or debug_event parameters while the internal traffic filter looks 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.

At least, that’s the theory. But I had mixed results here, and sometimes the internal traffic filter gets a higher priority than the developer traffic, and the debug view does not work as a result.

So what can we do here? I’ll answer that in the next chapter. But first, let’s create a developer filter (because it is not ready by default). In GA4, go to  Admin > 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. In one of the previous chapters, I mentioned that GA4 automatically adds a tt=internal (traffic_type) parameter to all hits if they come 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 > Configure (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 input. If the GTM preview mode is enabled, this variable will return true. Therefore, the lookup table variable will return the word “developer”. The Debug Mode variable will return false if GTM Preview mode is not used. 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 enter the word undefined in the Lookup table, that is a string.

Save the variable.

Finally, go to your Google 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 same event, you should see the Debug Mode parameter too.

Remember: both filters (developer and internal) are not active yet. They are in testing mode, meaning 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 learn more about the filters here.

If this setup with the lookup table variable does not work, then you can consider not using it at all. The bright side of this is that at least your internal traffic will not be polluting standard reports and explorations.

The downside is that the debug view will not work (until GA4 fixes this). To avoid the downside, you could use a VPN service (like NordVPN, etc.) that can temporarily change your IP address. In that case, your company’s internal traffic is still excluded, and only you will be polluting GA4 data (but at least debug view will be working for you).

Alternatively, you can use a separate property for testing. I explain how to do that at the end of this blog post.

Step #5. Activate both filters

The last step is to activate both filters. Go to Admin (in GA) > Data Filters and set both triggers (Internal traffic and developer traffic) to active. You can do that by opening each filter, changing its Filter state, and then save 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.

Method #2 – excluding internal traffic with the data layer

Another method does not involve IP addresses. Maybe your developers can identify somehow that the visitor/user who’s now browsing your website/web application is internal? Maybe they can identify that by a user id, or maybe they can think of something else? Talk to them.

Step #1. Getting the internal data parameter into the Data Layer

If that is possible, you should ask them to push the user_type (or traffic_type, or whatever) parameter to the data layer that could help you identify that the visitor/user belongs to your own company. If a visitor belongs to your company, then the parameter’s value should be internal. If a user/visitor does not belong to your company, no dataLayer.push should happen.

Here’s a sample dataLayer.push code that your developer could activate if the user/visitor belongs to your company:

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

The event key is not required (but recommended). This code must be activated before the GTM Container snippet is loaded.

Then create a Data Layer Variable with the following settings:

Step #2. Create a developer filter in GA4

In GA4, go to  Admin > Data Filters > Create Filter. Select Developer Traffic. Enter the following settings:

Set this filter to Testing (for now). Save it.

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

Go to Variables > New > Lookup table and enter the following settings:

Here we are using the Debug Mode variable as 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 the value of the Data Layer Variable that you created in the first step.

If the data layer contains the traffic_type key, then its value will be sent to GA. If the key does not exist, then it will be set to undefined (meaning that GA4 will not send the traffic_type key at all).

Save the variable.

Finally, go to your Google 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

Follow the same process as I have described here.

Step #5. Activate both filters

The last step is to activate both filters. Go to Admin (in GA) > Data Filters and set both triggers (Internal traffic and developer traffic) to active. You can do that by opening each filter, changing its Filter state, and then save the changes.

Or you can activate them from the list:

Then test everything once again (as I have described here).

Method #3 – excluding internal traffic based on a cookie

Another possible way to exclude internal traffic in Google Analytics 4 could be by using a cookie. You tell your employees to visit a certain unique URL, then you set a cookie with GTM and use its value in the lookup table variable.

Step #1. Set a cookie for internal users

However, keep in mind that just like any other method mentioned in this article, this one has its flaws. If most of your employees are using Safari (or browsing with iOS), the Intelligent Tracking Prevention will limit the lifetime of a cookie, and your employees will have to revisit that unique link often.

Let’s say that your website’s URL is www.mybusiness.com. Then you can tell your employees to visit the following URL: www.mybusiness.com?internal_user=true

Then go to Google Tag Manager and create a Custom HTML tag, paste the following code inside of it:

<script>
(function(){
 var cookieName = "gtm_internal_user"; // Name of your cookie
 var cookieValue = "internal"; // 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>

Set this tag to fire on a Pageview trigger when Page URL contains internal_user=true.

Step #2. Cookie variable

Go to GTM > Variables > 1st Party Cookie and enter the following settings:

Save the variable

Step #3. Create a developer filter in GA4

Create a developer filter in GA4, just as I have explained here.

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

Go to Variables > New > Lookup table and enter the following settings:

Here, we are using the Debug Mode variable as 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 the value of the 1st Party Cookie Variable that you created in the first step. If the cookie exists, then its value will be sent to GA. If the cookie does not exist, then it will be as undefined (meaning that GA4 will not send the traffic_type key at all).

Save the variable.

Finally, go to your Google 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

Follow the same process as I have described here.

Step #5. Activate both filters

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

Then test everything once again (as I have described here).

Send internal data to a separate GA4 property

This is optional, but if you want, you can send the internal data to a separate property (instead of playing with the traffic_type parameter as we did above). I won’t be explaining this step-by-step. Instead, I will explain a general overview and will leave this for you to play around with.

Basically, you can create a lookup table variable that will pick the correct GA4 measurement ID based on some variable that indicates internal traffic. So, let’s say that you have a cookie variable Cookie – internal traffic, and its value is true if the visitor is one of your coworkers.

In that case, go to GTM > Variables > New > Lookup table and enter the following settings:

If the cookie variable’s value equals true, then it will return the measurement ID of a test property (by the way, you should create a separate GA4 property for this). In all other cases, the variable will return your “LIVE” property’s measurement ID.

The final step is to insert this lookup table in your Google tag.

Exclude Internal Traffic in Google Analytics 4: Final words

The main benefit of how I exclude internal traffic is that it is still visible in the DebugView as long as you have the GTM Preview mode enabled. That way, you can debug your incoming hits without the need to do some manual hacks to overcome the traffic_type=internal.

Keep in mind that none of the aforementioned solutions are perfect:

• IP-based filters won’t work if your employees have dynamic IP addresses
• dataLayer.push-based filtering requires the developer’s input + still can miss some employees who browse anonymously-ish and haven’t logged in anywhere, so that your developer could identify them
• The cookie-based solution is, well, based on cookies. Cookies cannot be shared across multiple devices of the same visitor. Cookies can be cleared. Cookies expire sooner because of ITP on iOS or Safari. Thus, your employees might need to regularly revisit that unique URL (that sets the cookie).

I really hope that my experiments with filters were correct and that if you indeed exclude your internal traffic, it is not displayed in the debug view (until you do the modifications with the lookup table). If, on the other hand, you see that I’m wrong, please let me know, and I’ll update the guide accordingly.