Filter Out Internal Traffic in Google Analytics 4 Without IP Addresses

For this implementation, we define internal traffic as web traffic generated by a company’s employees, like marketers, developers, and others. We all know the headache of internal traffic. Companies, big and small, often get caught up in spikes on their user graphs and events until someone on the team realizes, “Hold on! That was the launch day, and everyone from the team was glued to the page like it was the latest season finale.”

Even after the launch, developers may continue to tweak some things, and test them on the live site. Unless your site gets a ton of traffic, these visits from your team can skew your data at least in the beginning, making it less useful for tracking real user behavior

Traffic filtering in GA4 has changed

In Google Analytics 4, traffic filtering has evolved significantly from the methods used in Universal Analytics.

1. IP Filters are useless

Currently, we only have IP address filtering available in Google Analytics 4. This approach is quite outdated, especially in today’s world where a significant portion of employees, if not the entire workforce, work remotely. Additionally, freelancers and agencies often work from their own offices or homes. Moreover, many employees frequently travel or work from flexible locations, resulting in constantly changing IP addresses.

While “the way we work” has evolved, Google Analytics 4 has not adequately addressed this area. As mentioned, relying on IP address filtering is not a viable solution for modern work environments

2. “Hostname filter” is not available in GA4 to filter traffic from dev servers

If your company has a development or staging server, and you test your GA4 tracking implementation on these servers before going live, you likely use a separate GA4 account or manage it through Google Tag Manager.

However, without a “Hostname filter”, GA4 analysts must filter out traffic from these pages only after the data has been processed. This process is both unnecessary and frustrating.

How to filter out internal traffic

We propose a solution that involves passing a parameter in the URL. Instead of visiting yourdomain.com, your team should always use yourdomain.com/?traffic_type=internal.

You might be skeptical about the feasibility of this method given that the team may not always follow this practice, but stay with us as we discuss strategies to make it work. Let’s first discuss how this can help.

Why this method works?

In GA4, IP filtering works by adding a query parameter to all events generated from the specified IP. This parameter is “traffic_type,” and the value passed is “internal.”

By manually adding this parameter with the value “internal” to our URLs, we can control the processing of our events as internal traffic. However, this is only part of the solution. Note that this is still a URL parameter, not an event parameter. In the next steps, we’ll explain how to convert this URL parameter into an event parameter for effective tracking.

But before diving into the technical details, let’s address this substantial task.

Internal Culture

Effective data tracking relies on rules and conventions to ensure clean data from the outset. Clean data is crucial for accurate campaign analysis and prevents frustration later on. This is why we establish conventions around UTM parameters, Google Tag Manager (GTM) tags, variables, and trigger naming.

However, ensuring your team consistently adds this parameter every time they visit the website is easier said than done. It’s a lot to ask, and compliance may be inconsistent.

Bookmarks

Bookmarking offers a simple, one-time setup to address internal traffic concerns.

Here’s how you can implement it:

1. Generate a link with the parameter, e.g., yourdomain.com/?traffic_type=internal.
2. Email this link to your team and ask them to save it as a bookmark.

Next time they visit the website, their browser will automatically suggest the bookmarked URL. For even better results, ask them to add this link to their bookmark bar and always use it to visit the site.

Once this administrative step is complete, it’s now time to set up your GTM and GA4 account.

Steps in Google Tag Manager

1. Create a Variable

Go to Variables > User defined variables > Create new > Choose Variable Type of URL > Component Type = Query > Add Query Key as “traffic_type”. Name it “traffic_type value” or anything else you like.

This will grab the value from the URL’s traffic_type parameter.

2. Change your Event settings variable

Go to your “Google Tag: Event Settings” variable and add a parameter of traffic_type and choose the variable we created in Step #1 as its value (see screenshot)

Steps in Google Analytics 4

Now that we are passing the internal traffic as a parameter in Google Tag Manager, we can proceed to set up our rule in GA4. Note that this rule is not configured by default. To set it up, follow these steps:

1. Go to Admin > Data Filters
2. Click the “Create Filter” button.
3. Choose Internal Traffic. (You only have to worry about Developer traffic if you want to flag it separately but we are not dealing with that here).
4. Give your data filter a name. This is the name you will see in your reports (do not worry this will happen only when you have this filter under “Testing”)

Verify the filter in GA4 reports

Create a quick report with the following dimensions:

1. Event Name
2. Test data filter name

Choose the following metrics:

1. Event count
2. Total users

Drop both dimensions to rows and both metrics to values. Here you go, you now can see your internal traffic coming through perfectly.

Problems with Using the Above Solution to Filter Internal Traffic

1. Manual Addition: Team members may visit URLs that aren’t bookmarked, requiring them to manually add the URL parameter each time.
2. Event-Scoped Filtering: The filter is event-scoped, not user-scoped. This means that even if a user starts with the bookmarked URL, navigating to another page will lose the parameter. Consequently, any events generated without the parameter won’t be identified as internal traffic by the filter.
3. Cross-Device Consistency: The bookmark needs to be saved on all devices. If team members switch devices, they must ensure the bookmark is present on each one to maintain consistent filtering.

A Comprehensive Solution is under development

We understand these concerns and are excited to announce that we are developing a Chrome extension to address them. With this extension, you can add your domain once, and it will automatically append the parameter to all URLs originating from that domain.

For early access to this extension, please follow us on LinkedIn and we’ll make sure you get free access as soon as the extension is live, Your interest will also help us prioritize the extension launch.