Exclude staff and test visits from GA4 reports

Keep staff browsing and tracking tests out of future GA4 reports after checking both filters in Testing mode.

• Outcome: Tracking & measurement
• Tools: Google Analytics 4, Google Tag Manager
• Responsible: People who maintain a website’s Analytics reports and test its tracking
• Estimated time: 45 minutes

Scope

This SOP covers:

• Mark staff website visits from known public IP addresses
• Test internal and developer traffic filters before activating them
• Keep debug visits available in DebugView while excluding them from ordinary reports

This does not cover:

• Filter app traffic
• Remove historical visits
• Exclude visitors by email, login or location
• Maintain broad or changing IP ranges

Requirements

• Editor access or above to the intended GA4 website property
• An existing GA4 web data stream receiving website visits
• Access to the website’s installed Google Tag Manager container so you can start Preview
• Public IP addresses supplied or confirmed by the website owner for staff networks, plus a different network for a visitor check
• A website owner who can confirm the staff networks and approve permanently excluding their future visits

Related SOPs

• SOP 012: Install GA4 through Google Tag Manager

01. Choose which visits belong outside reports

Staff network visits and tracking tests are different. Each needs its own filter.

1. Open Google Analytics and select the website’s property. Create a note called GA4 filter setup with sections Property, Staff networks, Tests, and Activation. Open Admin > Property > Property details and enter the property name and Property ID under Property. Then open Admin > Data collection and modification > Data streams and the website’s web stream; add its stream name and Website URL to that section.

2. In Staff networks, list each owner-confirmed public IP address and which staff network uses it. Use the internet-facing address, not a computer’s local address such as 192.168.1.10. A shared office address identifies everyone on that network; a changing home address can stop matching later. Use exact addresses for this guide.

   • Warning: A public Wi-Fi network may include customers. Do not exclude its address. Ask the owner for a dedicated staff network instead.

3. Open Admin > Data collection and modification > Data filters. Inspect existing Internal traffic and Developer traffic filters. In Activation, record their names, states and match values. Reuse a matching filter; create a new one only when it is missing. Testing labels matching visits without discarding them; Active permanently discards future matches; Inactive does nothing.

   • Warning: If a matching filter is already Active, have the property owner approve changing it to Testing for this check; matching visits will be retained while it is Testing.

02. Mark staff visits and create testing filters

First label staff traffic. Then make Analytics show you what each filter would remove.

1. Return to Admin > Data streams and open the web stream. Under Configure tag settings, click Show more > Define internal traffic. Create one rule for each address in Staff networks.

   1. Name the rule after the network, such as Office staff. Set traffic_type to internal. This label connects the network rule to the data filter.

   2. Choose IP address equals and enter that network’s public IP address. Click Create, then repeat for the other confirmed addresses.

2. Open Admin > Data collection and modification > Data filters. Create Filter > Internal Traffic, or open the matching existing filter. Name it Staff visits, choose Exclude, set the traffic_type parameter value to internal, and set its state to Testing. Save.

3. Create Filter > Developer Traffic, or open the matching existing filter. Name it Tracking tests, choose Exclude, set its state to Testing, and save. Developer traffic means events sent with debug mode on, including tracking tests made with Tag Manager Preview.

03. Prove the filters match the right visits

Keep the staff and debug test cases on separate networks so each case tests one rule. Use a fresh non-personal test label for each run; append it with & when the URL already has a query string. Allow for the 24–36 hour filter delay in the schedule: the 45-minute estimate is hands-on work. See Google’s developer-filter test guidance and internal-traffic filtering.

A saved filter is not enough. Check the visits Analytics actually labels before discarding any data.

1. On a listed staff network, open a fresh ordinary browser tab on your website with a unique query at the end, such as ?filter_check=staff_20261013. Accept analytics consent if your banner requires it and visit another page. Keep Tag Manager Preview disconnected for this visit. In Tests, enter the URL, network, time and “staff, non-debug”.

2. From the separate visitor network, outside every listed staff IP rule, open Google Tag Manager, select the website’s container and click Preview. Connect to a website URL with a different query, such as ?filter_check=debug_20261013. Accept analytics consent, then open Admin > Data display > DebugView in GA4 and confirm the visit’s page_view event. In Tests, enter its URL, time and “debug”. End Preview when finished.

3. Using a different network, such as mobile data rather than office Wi-Fi, open the site without Preview and use a third query, such as ?filter_check=visitor_20261013. Accept analytics consent and visit another page. In Tests, enter its URL, time and “ordinary visitor”.

4. In GA4, open Explore > Blank. Name the exploration GA4 filter test and set the date range to include all three tests. Import dimensions Test data filter name, Event name, and Page location, plus metric Event count.

   1. Under Tab settings, choose Free form. Add Test data filter name, Event name and Page location to Rows; add Event count to Values. Add a Page location filter that contains filter_check=.

   2. Find each marked URL. The non-debug staff visit must be labeled Staff visits, and the debug visit must be labeled Tracking tests. The ordinary visitor must have neither filter’s name. In Tests, record each observed label and event count.

      • Warning: Filters can take 24–36 hours to apply. If a case is missing, leave both filters in Testing, check again later and send a new marked visit if needed. Do not activate a filter based only on an empty table.

5. Compare the three results with the rules. If a staff visit is unlabeled, recheck its current public IP and the exact stream’s rule. If ordinary visitors are labeled, narrow the incorrect rule before continuing. If the debug visit is unlabeled, reconnect Preview and check DebugView again. Repeat the affected visit and report check until all three cases match.

04. Activate only the filters you have checked

Activation changes future data. It does not clean up visits already in your reports.

1. Show the owner Staff networks and the three results in Tests. Explain that Active exclusions permanently discard future matching events from Analytics and BigQuery; switching them off later cannot recover discarded data. In Activation, record the owner’s confirmation, date and the two filter names.

2. Open Admin > Data collection and modification > Data filters > Staff visits. Change the state to Active and save. Read any confirmation and confirm the property and filter before accepting it.

3. Open Tracking tests, change its state to Active and save. Reopen it to confirm Active and Exclude. In Activation, enter the activation time for both filters. For future DebugView checks, use a permitted test network outside the active staff IP exclusions and verify receipt; do not assume the developer filter cancels another exclusion.

4. Give the owner GA4 filter setup and its exploration. Explain that staff IP changes require an updated rule and another Testing check. If a rule later excludes the wrong people, set its filter to Inactive to protect new visits while you investigate; lost data remains lost.