Guide 14 · Debugging · GA4 + Tag Manager
Your own visits are filtered out: check the internal traffic rule and the filter state
GA4 marks your office IP as internal traffic, and an Active filter deletes it from reports permanently. A missing event from your own desk may be a filter doing its job.
After the steps below, you know whether your IP is in an internal traffic rule, whether the filter is Testing or Active, and whether your test event was excluded.
Download the check: the debugging check (JSON) (MD5 fe54bf49e5f009a3b8065480b4b4af13, 529 bytes). It lists the checkpoints from this guide and the worked check, with the figures recomputed. The file was built for this guide and validated structurally — it was not exported from a live container or a live property.
What you need
- Your public IP address. Search for what is my IP, and write the address down before you open GA4.
- Editor access on the GA4 property. Defining internal traffic and creating data filters both need the Editor role at the property level.
- The internal traffic rules for the web stream. Admin, then Data Streams, then the stream, then Configure tag settings, then Define internal traffic.
- The data filters list. Admin, then Data collection and modification, then Data filters, where each filter shows Testing, Active, or Inactive.
The trace
The worked check: the figures below were recomputed before publication, and the note under the table shows the working.
| Check | Figure |
|---|---|
| Data filters allowed per property | 10 |
| Data filters in this property | 2 |
| Internal traffic rules defined | 1 |
| Test events sent from the office IP | 6 |
| Test events excluded by the filter | 6 |
The property held 2 data filters out of the 10 allowed, so 10 minus 2 is 8 filter slots still free. One internal traffic rule was defined, and 6 test events were sent from the office IP — all 6 were excluded by the filter, so 6 of 6, or 100.00%, of the office test traffic was removed before it reached the reports.
- Find your public IP address. Search for what is my IP on the network you test from — the office network, not your phone on mobile data. The address you see is the one GA4 sees. Write it down; you will compare it with the rule.
- Open the internal traffic rules. In Analytics, go to Admin, then under Data collection and modification, click Data Streams, then the web stream, then Configure tag settings, then Show more, then Define internal traffic. Read the rules: the IP addresses or ranges, and the traffic_type value, which is internal by default.
- Check whether your IP matches a rule. Compare your address against the rule's match type and value. A rule matching your IP adds a traffic_type parameter to every event you send. If your IP matches, your test traffic is tagged internal, and the filter decides what happens to it.
- Read the data filter state. Go to Admin, then Data collection and modification, then Data filters. Find the Internal Traffic filter. If its state is Testing, the events are still in the reports and tagged with the test data filter name. If it is Active, matching events are excluded — permanently, and never available in Analytics or BigQuery.
- Test from an unmatched network to confirm. Send the same test event from a network whose IP is not in any rule — a phone on mobile data, for example. If the event appears in Realtime from there and not from the office, the filter is the cause. Do not fix it by deleting the rule; the filter is doing what it was built to do.
Dead ends
DEAD END — ACTIVE MEANS PERMANENT. Google's warning is plain: once you apply an exclude data filter, the excluded data is never processed and will never be available. Testing a filter by setting it Active on a Friday and checking on Monday cannot bring the weekend back. Start every filter in Testing.
DEAD END — A RULE WITH NO FILTER DOES NOTHING. Defining the IP rule only tags the traffic with traffic_type. Without a data filter set to Exclude, the tagged traffic stays in the reports. If your own visits still pollute the reports after you defined the rule, the filter is missing or still in Testing.
DEAD END — THE FILTER TAKES A DAY OR MORE. A data filter can take 24 to 36 hours to apply. A test event sent an hour after you changed the filter state may not reflect the change yet. Check the state, then wait, then test — do not change the state again in the meantime.
End state
Your IP compared with the rules, the filter state read, and the exclusion confirmed from a second network. Your own visits are either in the reports because no filter excludes them, or out of the reports because a filter you built excludes them — and now you know which it is.
Sources
- Analytics Help — Filter out internal traffic — Defining internal traffic by IP address, the traffic_type parameter, creating up to 10 data filters per property, Testing versus Active states, the permanent effect of an Active exclude filter, and the 24 to 36 hour apply time
- Analytics Help — Confirm that you are collecting data — Realtime as the same-day check for whether a test event arrived
Checked 11 November 2026. The click paths above are the ones in Google's help pages, opened 11 November 2026. What was run: the filter counts, recomputed — 2 of 10 allowed data filters in use, so 8 slots free, and 6 of 6 office test events excluded, 100.00%. No step in this guide was run inside a live Analytics property or a live Tag Manager container, because both need a Google sign-in and this site does not sign in as anyone. Google moves menu items without warning; if a path on this page no longer matches, the linked help page is the current map.