Skip to content

Guide 136 · Setup · GA4 + Tag Manager

Define internal traffic: tag your office IP addresses so the filter can exclude them

Checked 11 November 2026 · Verification: CIDR range recomputed (a /24 holds 256 addresses; 256 − 2 = 254 usable hosts) · Steps traced to Analytics Help, read 11 November 2026 · 6-minute read

Every visit the team makes to its own site lands in the reports unless someone tells GA4 it is internal. Defining internal traffic is step one of two: the rule attaches a traffic_type parameter of internal to events from the office IP addresses, and a data filter then excludes those events from the reports. This guide builds the rule. The filter that uses it is the next guide's companion step, covered here as step 5 so the rule is never left half done.

Expected signal

After step 4, events from an office computer carry the traffic_type parameter set to internal, visible in DebugView on the event's parameters.

Download the reference: the internal traffic reference (JSON) (1035 bytes, MD5 c5d57a3b7d3638fcba25d7276d7386fb). The internal traffic rule from Google's help pages, with the CIDR range recomputed: a /24 holds 256 addresses, 254 usable hosts.

What you need

  • A web data stream. Internal traffic is defined in the stream's tag settings.
  • The Editor role at the property level. Google requires the Editor role to identify internal traffic and to create data filters.
  • The office IP addresses. One address, several addresses, or a CIDR range. Find the office's public IP by searching for what is my IP on an office computer.
  • A name for the rule. Something descriptive, such as Office IP addresses, so the rule is easy to find later.

The trace

  1. Open the stream's tag settings. In Admin, under Data collection and modification, click Data streams, then click the web data stream. Scroll to the Google tag section and click Configure tag settings.
  2. Open Define internal traffic. In the tag settings, click Define internal traffic, then Create. The rule you build here only marks the traffic — it does not exclude anything yet.
  3. Name the rule and set the traffic_type value. Enter a name for the rule, then enter a value for the traffic_type parameter. internal is the default value. You can enter a new value, such as emea_headquarters, to represent a location the traffic comes from, which matters when two offices need two different rules.
  4. Add the IP addresses. Enter the IP addresses or CIDR ranges the rule covers. CIDR notation is the way to write a range of addresses: a /24 range holds 256 addresses in total, and 256 − 2 = 254 of them are usable hosts, since the first and last addresses in the range are reserved. A small office on one /24 therefore covers its whole network with one entry.
  5. Create the data filter that uses the rule. Defining the rule is only half the job. In Admin, under Data collection and modification, click Data filters, then Create Filter. Choose Internal Traffic, enter a name for the filter, and choose Exclude to filter out events where the value of the traffic_type parameter matches the value from step 3. You can create up to 10 data filters per property, so one filter per office is affordable; the default internal traffic filter Google creates with the property already covers the value internal.
  6. Test before activating. Data filters have three states: Testing, Active, and Inactive. Run the new filter in Testing first and check in DebugView that office events carry traffic_type=internal. Then set the filter to Active. Once a filter is Active, its effect on the data is permanent — excluded data is never processed and will never be available in Analytics or BigQuery — and filters do not affect historical data.

Dead ends

DEAD END — DEFINING THE RULE AND STOPPING THERE. The rule only tags events. Nothing is excluded until a data filter is created and set to Active. Teams that finish step 4 and stop still see their own visits in every report.

DEAD END — SETTING THE FILTER TO ACTIVE WITHOUT TESTING. An Active filter permanently removes the matching data. A wrong IP range in the rule, activated without a Testing run, deletes real visitor data that looked internal. Test first, activate second.

DEAD END — FILTERING DEVELOPERS WITH THE INTERNAL TRAFFIC RULE. Internal traffic rules are IP-based and developer traffic is debug-mode-based. If the team's developers work from home on changing IP addresses, their traffic is better handled with the developer traffic filter, which is the next guide.

End state

An internal traffic rule marks office events with traffic_type internal, and a data filter in the Active state excludes them from the reports. The team's own visits no longer inflate the numbers, and DebugView still shows the tagged events while the filter is in Testing.

Sources

  • Analytics Help — Filter out internal traffic — the two steps: identify internal traffic in the stream's tag settings, then create the data filter; the 10-filter limit, the Editor role, the traffic_type value, and CIDR notation
  • Analytics Help — Data filters — data filters are permanent once applied and do not affect historical data; the internal traffic and developer traffic types

Checked 11 November 2026. The two steps and the limits above are the ones in Google's internal traffic page and data filters page, both read 11 November 2026. No step in this guide was run inside a live Analytics property, because that needs a Google sign-in and this site does not sign in as anyone. The reference file was checked in Python: its figures were recomputed from the documentation values and match the numbers on this page. Google moves menu items without warning; if a path on this page no longer matches, the linked help page is the current map.