The internal traffic filter is on and the reports have not changed

Symptom

You set up internal traffic to keep staff and developers out of the numbers. The office IP is registered and the screen clearly shows it saved. A week later the reports still contain the sessions your own team generated. Conversion rate is as low as it was, and the visitor graph still has a bump at the hour when everyone opens the site.

The less traffic a site has, the worse this contamination is. On a B2B site with 200 visits a day, twenty internal visits are ten percent of everything — and those twenty never convert.

Cause

Excluding internal traffic in GA4 is two steps, and skipping the second one means nothing happens at all.

1. Define internal traffic on the data stream. Admin → Data Streams → Configure tag settings → Define internal traffic lets you write an IP rule, and events matching it get marked as internal traffic. That is all it does — the data still comes in.
2. A data filter on the property removes the marked events. Admin → Data collection and modification → Data filters is the part that actually discards anything.

Where it breaks is usually one of four places.

• The filter is still in testing. Data filters have three states — testing, active and inactive — and testing removes nothing. Testing is the stage for previewing what the filter would catch, and what it catches shows up only through the "Test data filter name" dimension. Creating the filter in testing and forgetting to switch it to active is the single most common cause.
• Only step one was done. Defining internal traffic lives on the data stream screen while data filters live in property settings. They are different screens, and it is easy to finish the first and think it is registered.
• The IP is not that IP any more. Remote work, mobile connections, VPNs and non-static lines all mean the address you registered no longer matches. An office line on IPv6 with only an IPv4 address registered ends the same way.
• There is more than one stream. Internal traffic definitions are per stream. If web and app are separate, or you have a stream per domain, only the stream you configured gets the marking.

And in every case, filters are not retroactive. Only data arriving after you switch the filter to active is removed; the internal visits already collected stay in the reports.

This is a check we cannot make for you automatically. The GA4 Admin API does not expose the list of data filters at all, so the AnalyticScan engine has no way of knowing whether a filter exists, or whether it is active or in testing. ST-03 therefore always resolves to "not applicable" in the report and is handled as a manual check that a person makes. The second link on this article's check card (/checks#ST-03) goes to that explanation. We do not promise to look at something and then show you "not applicable".

How to check in GA4

1) Start with the filter's state. Open Admin → Data collection and modification → Data filters and read the state of the internal traffic filter. If it says testing, you have your answer right there. If the list is empty, step two was never done.

2) Check the marking is being applied. While the filter is in testing, the "Test data filter name" dimension shows what it is catching. Open the site from the office once, and if nothing at all shows up, the problem is the IP rule in step one, not the filter.

3) Compare against the public IP you actually use. Look up the public IP your office or home connection goes out on and compare it character by character with what is registered. Often nobody has updated the list since the line changed or the office moved.

4) Split the date range around the day you activated it. If internal sessions keep arriving after that day, the rule does not match. If they stop dead on that day, the setup is fine and you were looking at older data.

How to fix it

Switch the filter to active. But data an active filter excludes is permanently discarded and cannot be recovered, so the order matters: leave it in testing for a few days, see what it catches, then activate. A rule drawn too wide will quietly delete real customer traffic.

People an IP cannot catch need a different method. Remote and mobile workers are the blind spot of IP rules. For development and staging environments a separate measurement ID is the reliable answer (that is the next article). If it is one employee's browser you need out, blocking collection on their side is faster.

Read past data by excluding it in explorations. Since nothing is retroactive, the practical fallback for periods before the filter is to build a segment in an exploration — on the region, hour or hostname where internal traffic concentrates — and read the numbers with it excluded.

Write down the day you changed it. Re-investigating "why did the metrics drop on this date" months later costs far more than one line of notes.

In one line

Excluding internal traffic is a definition plus a filter, two steps. If the reports have not moved, the filter is almost certainly still in testing. And because the GA4 API does not expose it, this is one check our diagnosis cannot make on your behalf — open it yourself today.