GA4's IP-based internal traffic filter requires you to know your office IP, set it in GA4 Admin, and trust that the filter will catch every internal hit. In practice, remote-first teams have dozens of IPs, IPs change, and the filter only kicks in if the request reaches GA4 in a recognisable shape. Filtering at your tagging server is more reliable.

The signals that identify internal traffic

• Office or VPN IP ranges (CIDR blocks).
• A specific cookie set by your team's browser extension.
• A query parameter on internal links (?utm_source=internal).
• Specific user agents from automated testing tools.

Implementation in sGTM

Create a Custom Variable that returns true for internal traffic. Use it as an exception trigger on every tag that should not fire for internal hits.

const ip = getRequestHeader('x-forwarded-for') || '';
const cookie = getCookieValues('_internal')[0];
const internalIPs = ['203.0.113.', '198.51.100.'];
const isOfficeIP = internalIPs.some(prefix => ip.startsWith(prefix));
return isOfficeIP || cookie === 'true';

The opt-in cookie pattern

For team members working from home or coffee shops, IP filtering does not catch them. The reliable alternative: a small bookmarklet or browser extension that sets a cookie called _internal=true. Anyone who installs it is filtered out everywhere they browse.

Document the bookmarklet in your team's onboarding. Two lines of JavaScript. The cost is negligible and the data quality benefit is meaningful for small teams that browse their own site frequently.

Filter at the server, not the destination

If you filter at GA4 (via internal traffic filter) but not at Meta CAPI, your Meta reporting will still include internal traffic. Filter once at the server, and the exclusion applies to every downstream destination automatically.

What to do for QA traffic

QA testing is internal traffic that needs to fire events for verification but should not pollute production reports. The pattern: route QA traffic to a separate GA4 property by setting a different measurement ID based on the same internal flag. Both signals exist; one is for QA, one is for prod, neither contaminates the other.