IP Address Filtering in GA4

GA4 IP filtering is possible, but not regexy.

“There’s an old vaudeville story about a man who was about to be hanged, and they had brought him out on the scaffold and put the rope around his neck, and the minister in the prison said, ‘Have you any last words before we spring the trap?’ And this thing was kind of shaky and he looked up and he says, ‘Yes, I don’t think this damn thing is safe.’ “ — Groucho Marx

Introduction

In other news and system checks, view filters aren’t available in GA4. Fortunately Google provided Data Filters and Rules on each property that can be applied to its data streams, and they work kind-of well.

It’s a pretty good way to go since you don’t need to replicate the rules per view as was necessary in GA UA. But it has its own limitations, one of which is the fact that there is no regex matching available for IPs. This is a step away from GA UA filters where regex was widely available and used. What this change means is this: you have to get good at working with CIDR notation to match ranges of IP address. This works, but it’s greedy, exclusive, and it loves you back a little — depending on what you feed it. Kind of like your pet pig.

This boils down to a slightly suboptimal but possibly more run-time efficient means of filtering out traffic by IPs. Since CIDR can cast a very wide (more like a vacuum cleaner hose) or a very narrow net, it can either be excessive or too permissive. There aren’t many in-betweens in CIDR IP matches.

What I find helpful is doing some experimentation in CIDR matches on the IP address ranges that I’m creating newly or trying to replicate from GA UA view filters.

I suggest using a tool like Subnetcalculator to make it easy, and there is more about this below under: Using CIDR matching.

IP Filtering

Three steps and lots of subparts.

1. Create Filter(s): Internal Traffic Filter(s) in Data Settings / Data Filters
2. Create Rules: A series of filtering Rules in Data Stream settings that apply to your Filter by name.
3. Test and Set to Active

GA4 Filtering Guidelines and Limits:

Filters are set at the property level:

- Up to 10 Filters can be created per property
- Operate in one of three states: Testing, Active, Inactive
- Apply to one or more Data Streams (as many as are created for the Property)

Rules are set at the Data Stream level:

- Up to 10 Rules can be created per Data Stream, per Property
- A rule is a set of up to 10 conditions
- Multiple Rules (up to 10) can be attributed to one Filter
- One Rule may not be attributed to multiple Filters
- GA4-360 sub-properties do not have their own IP Filters and Rules
- Sub-properties are filtered by the Filters and Rules of the parent property
- Rules are only Active when the Filter at the property is set to Active

* One Property can have 10 Filters X 10 Rules per Data Stream 
  X 10 Match Conditions per Rule

I found these limits by experimenting: 
-- Not yet summarized in the GA4 Filter Help

Reference: Google’s [GA4] Data Filters help documentation

(1) Filters

Filter Step 1: Under the GA4 property settings select Data Settings / Data Filters, click “Create Filter” on the top right.

Filter Step 2: Select the Filter type: Developer or Internal Traffic.

[This post concentrates on Internal filters only, and IP address rules].

Help on filter types

Help on creating filters

For IP filtering, select “Internal Traffic”. This does not mean that all IP filters are internal only. It is a misnomer because the actual sets of IP’s and ranges that you will be filtering are created in Rules

Filter Step 4. Name and configure your filter.

Google creates a default filter named Internal Traffic, of type Internal Traffic as an Exclude filter, in the default state, Testing. But this filter has no rules created or applied to it, so it’s doing zilch until you create rules against it.

We may as well customize it to be our own. You may also create several Filters per property, naming them separately, giving them unique values for the traffic_type parameter. Steps below in modifying the default Filter, or creating your own.

After clicking “Create” this popup is visible:

Tip > Begin by using the default Filter, but customize it.

A. Data Filter Name:

• In my example, I named it “Exclude Internal and Vendor IPs”

B. Filter Operation:

• Set it as an include or exclude Filter. Typically it’s an exclude but this choice needs to be made based upon how many IPs are allowed access to the site. If the site is an internal one, or an extremely limited offering, then use an include Filter with a known range of IPs for your Rule. Otherwise, this should be set to exclude.

C. Parameter

• The Parameter name “traffic_type” is automatically added to GA4 and appended to your events with the value “internal”.
• Tip > The value of the parameter can be customized here. This can be valuable if you want to 1. create several different Filters that use separate rules, and 2. differentiate them in reporting later. The advantage of doing this is to uniquely identify which filter is running and when (e.g. using the traffic_type parameter in a BQ SQL script, and/or by setting it as a custom dimension in the GA4 interface to use in an Exploration.
• Google help

D. Filter State: Testing, Active, Inactive

• Initially the default state of the Filter is Testing. Use this state to test the effectiveness of the filter over a few days or more of traffic by querying the provided dimension named Test data filter name.
• As it indicates, this parameter will show the Filter name that has been applied during the given query dates, and you can use this to determine the number of events that would have been filtered by the particular filter name. Tip > This is why it can be useful to create several filters with different names, using different Rules.
• When testing is over and you want the Filter applied, set the status to Active. When no longer needed or it needs to be paused, then set state to Inactive.

Example Filters

(2) Creating Rules

Converting GA UA IP filters to GA4 Rules

Rule Sets

Step 1: Select the intended data stream

Step 2: Select Configure tag settings under Google tag

Step 3: Click Show all

Step 4: Select Define internal traffic

Step 5: Click on “Create”

Step 6: Create Rule sets and Conditions per rule set

• Rule sets: below is a list of example rules by name

• One Rule and it’s Match Conditions:
• > Give the Rule a name that differentiates its IPs from another rule
• > traffic_type value is a name that will be set to the traffic_type parameter. It can be changed to show the traffic’s origination (e.g. uk_offices) in this case. If the rule is set to an Include filter, then this will be visible in GA4
• > IP addresses and match conditions are covered next.

(2.a) Match Conditions

Create rules (which act like rule sets).

Limits :

For each Data Stream:
— Up to 10 Internal Traffic Rules
— Up to 10 IP match conditions within each Rule

• There is no regex. That’s the mic-drop for doing IP filtering in GA4. Regex isn’t available (yet), so the lengthy regex matches that we’ve grown accustomed to in GA3/360 are gone.
• Replacement: the following match types:

IP address equals
IP address begins with
IP address ends with
IP address contains
IP address is in range (CIDR notation)

Matches are possible with either IPv4 of IPv5 address types, and CIDR supports both of the with its address range matching.

• — CIDR is not an equivalent replacement for regex, but it’s something.
• — The exclusion of regex matches forces us to be economical with IP matches, and I have found myself having to choose between two realities:
• > 1. not excluding some IPs because I ran out of specific matches in my rules (limit 10 per rule, and 10 rules)
• > 2. using CIDR notation in matches that are overly greedy

Ultimately, websites may be served by instituting either a user login and a user type variable that is used for exclusion instead by using GTM to shuttle away traffic to a test property instead of relying upon IP exclusion with rules, or a VPN with dedicated IPs. The latter can be more reliable and easier to use.

Suggested steps:

Make a list of IP filters that you need to replicate from key GA3 or 360 Views

• In this stage it’s best to list out all of the filters and their logic from the GA3/360 views that logically match your GA4 property. I use Google Docs or Sheets

Example Filter Settings for GA3/360 UA Views

• Regex IP View Filter Examples

Example regex IP View Filters from GA3/360 UA

Example of IP regex.

^(155\.160\.60\.18|155\.160\.60\.(2[1-7])|155\.160\.60\.(29|30)
|155\.160\.60\.(4[7-8])|155\.160\.60\.56|155\.160\.60\.58
|177\.142\.230\.49|277\.124\.26\.114|3\.125\.99\.135|277\.13\.121\.241
|277\.133\.38\.181|277\.135\.49\.180|277\.136\.111\.218|277\.138\.54\.100
|277\.58\.165\.213|277\.64\.159\.177|277\.66\.247\.32|277\.68\.122\.244)

Identify the IP puzzle pieces and determine what kind of matches work. Expand the regex into individual IP matches to assist you in determining the coverage bands for CIDR matches.

Expanded list below

Break into component IP blocks… 

//155\.160\.60\.18
155.160.60.18

//155\.160\.60\.(2[1-7])
155.160.60.21
155.160.60.22
155.160.60.23
155.160.60.24
155.160.60.25
155.160.60.26
155.160.60.27

//155\.160\.60\.(29|30)
155.160.60.29
155.160.60.30

//155\.160\.60\.(4[7-8])
155.160.60.47
155.160.60.48

155.160.60.56
155.160.60.58
177.142.230.49
277.124.26.114
277.125.99.135
277.13.121.241
277.133.38.181
277.135.49.180
277.136.111.218
277.138.54.100
277.58.165.213
277.64.159.177
277.66.247.32
277.68.122.244

Using CIDR matching

• CIDR matching is helped by using a free online CIDR calculator. Example: https://mxtoolbox.com/subnetcalculator.aspx

Using an example from the list above:

//155\.160\.60\.(2[1-7])
155.160.60.21
155.160.60.22
155.160.60.23
155.160.60.24
155.160.60.25
155.160.60.26
155.160.60.27

CIDR notation matches:

• Using the CIDR matching tool, we’re looking for matches for .21 — .27 as specifically as possible.

A CIDR mask = /29 results in IP Range 155.160.60.16 - 155.160.60.23
A CIDR mask = /28 results in: IP Range155.160.60.16 – 155.160.60.31
A CIDR mast = /27 results in IP Range 155.160.60.0 - 155.160.60.31

• Tool shown here:

CIDR and IP Matching Summary

• The winner is: 155.160.50.21/28 Even though its range of .15 — .31 extends a bit above and beyond the desired ranges of .21 — .27, it’s pretty close and what we have available with CIDR.
• There aren’t enough Rule conditions available to allow specific identification of every IP address because there are way more than 10.
• Spreading the IPs across all 10 Rules will still not provide enough individual IP conditions since there can be far more than 100 individual IP addresses.
• So CIDR is the only shop in town to match more, until and if regex is eventually supported by Google in GA4.

Rule Management

(3) Testing

When the Filter is set in Test mode, the traffic filtered out can be tested for each filter name by using the parameter: Test data filter name

Add it to the Pages report, or create an Exploration.

Exploration:

Conclusion

> Filtering GA4 properties by IP is possible but not optimal with “internal traffic” filters, but the logic needed to identify IP addresses is different compared to its predecessor logic in GA3/360 view filters.

• Up to 10 Filters on a Property
• Up to 10 Filter rules per Data Stream, with up to 10 conditions per rule

> You can reuse rules among filters by being creative with the filter name

> CIDR is the replacement for regex. It’s not a great replacement in terms of specificity, or greedy inclusion of a large set of non-sequential IPs. It also is probably better performing because it doesn’t allow greedy regex logic. It’s a tradeoff.

> Using a CIDR calculator helps with experimentation to identify IP bands.

> There is a risk of over or under-reaching with CIDR because its bands are not helpful because IP ranges can be within a small bracket but the CIDR band might be either too small or too large, and can block unintended IPs.

> Matching options are helpful, but in today’s much more geographically diverse and at home or out of office workforce, IPs can range all over the place, and are normally non-sequential. This makes the list of IPs to block larger than the capacity for creating Rules in GA4.

> Consider VPN:

• For a large organization, it’s a good idea to try implmenting a VPN for all internal. This provides the ability to create sequantial IP addresses, or one dedicated shared IP address.
• The idea is to create dedicated IPs for employees. It can be done either as a list of sequential IPs that could be identified pretty easily with one or a few CIDR blocks, or as a single dedicated IP for the whole organization [not recommended due to incursion risk].

Thank you. Please let me know if you found this useful, or !useful.