Chrome’s IP Protection Masks Visitor IPs in Incognito

What IP Protection Actually Does (and Doesn’t Do)#

Chrome’s IP Protection is narrower than most coverage suggests — it applies only to Incognito mode, only to third-party domains on a specific list, and only to the IP address itself.

31.5% of global internet users already run ad blockers that strip tracking scripts entirely. Chrome’s IP Protection adds a different kind of data loss: instead of removing the tracking code, it replaces the visitor’s real IP with a coarse geolocation IP — accurate to a region but not to a city or postal code. The key constraint is that IP Protection currently applies only in Incognito mode and only for third-party domains that appear on Google’s Masked Domain List.

This is not the same as a VPN. IP Protection doesn’t hide that a user is visiting your site. It doesn’t block cookies. It doesn’t prevent first-party data collection. It specifically prevents third-party trackers from using IP addresses to identify users across different websites — a narrow but significant change for any analytics workflow that depends on IP-derived location or cross-site fingerprinting.

Chrome IP Protection masks visitor IPs in Incognito mode only for third-party domains on Google’s Masked Domain List, not for first-party requests.

The staged rollout has been progressing across Chrome milestones M137 through M142 during 2025 and 2026, expanding region by region. Google has not confirmed a timeline for extending IP Protection beyond Incognito to regular browsing sessions. But the infrastructure is being built — and for WooCommerce stores planning their tracking architecture, the question isn’t whether to prepare, but how.

You may be interested in: Your Consent Mode v2 Looks Green and Transmits Nothing: The Silent WooCommerce Conversion Loss You Can’t Get Back

The Two-Hop Architecture: How the Masking Works#

IP Protection uses a two-proxy chain that ensures no single entity — not even Google — can link a specific user to a specific destination website.

When a Chrome Incognito user makes a request to a third-party domain on the Masked Domain List, the request is routed through two proxies. Google operates the first proxy. It sees the visitor’s real IP address but not the destination URL. An external CDN partner operates the second proxy. It sees the destination URL but not the visitor’s real IP. The visitor’s real IP is replaced with a coarse-geo IP at the second proxy, and the destination server receives only that coarse IP.

IP Protection routes traffic through a two-hop proxy: Google sees the IP but not the destination, while an external CDN sees the destination but not the IP.

The coarse-geo IP preserves approximate location — typically accurate to a region or metro area but not to a city or postal code. For WooCommerce stores that use IP-based geolocation for shipping estimates, tax calculation, or local inventory display, the coarse IP may or may not be sufficient depending on how granular your location logic needs to be.

The privacy design is deliberate. By splitting knowledge between two proxies, Google prevents itself from building a browsing profile from the proxy data. The first proxy can’t profile destinations; the second proxy can’t identify users. This architectural choice makes IP Protection structurally different from a VPN — it’s not about hiding from websites, it’s about preventing cross-site IP-based tracking.

The First-Party Carve-Out That Changes Everything#

The most important detail in IP Protection’s design is what it doesn’t mask: first-party requests to your own domain.

When a visitor’s browser sends a request directly to your WooCommerce domain — your own pages, your own API endpoints, your own server — that request is a first-party context. IP Protection does not apply. Your server receives the visitor’s original IP address, exactly as it does today, even if the visitor is using Incognito mode.

First-party resources still receive the user’s original IP even if the domain appears on the MDL — the first-party carve-out is the key design principle.

This carve-out extends to subdomains grouped via Related Website Sets. If your analytics endpoint runs on a subdomain like analytics.yourstore.com and is properly configured as part of your Related Website Set, it’s treated as first-party. The visitor’s original IP reaches your analytics subdomain even when third-party analytics scripts on the same page receive only the coarse-geo IP.

The practical implication for WooCommerce stores is that your tracking architecture determines whether IP Protection affects you. Third-party tracking scripts loaded from external domains — GA4’s collect endpoint, Facebook Pixel, ad platform tags — will receive masked IPs for Incognito users. First-party server endpoints that you control will continue to receive the real IP.

What Gets Masked: The Masked Domain List#

Not every domain is affected by IP Protection — only those on Google’s Masked Domain List, which targets domains involved in advertising, targeting, and cross-site data collection.

Domains qualify for the MDL if they serve ads, conduct ad targeting, measure ad effectiveness, or collect user data for advertising and marketing purposes. The list includes the major analytics and advertising infrastructure domains — the same domains that ad blockers and privacy extensions already target.

For WooCommerce stores, the domains most likely to be on the MDL include Google Analytics collection endpoints, Facebook Pixel domains, Google Ads conversion tracking domains, and third-party retargeting services. Your own domain — yourstore.com — is not on the MDL unless your primary business is advertising or cross-site tracking.

This creates a two-tier tracking environment for Incognito users. Third-party analytics scripts see a coarse-geo IP. Your own server sees the real IP. The stores that maintain both tracking layers — first-party server-side and third-party browser-side — can compare the two to identify exactly how much data IP Protection is removing from their third-party analytics.

What This Means for WooCommerce Geo Data and Fraud Checks#

The shift from precise IPs to coarse geo affects any WooCommerce workflow that depends on visitor location accuracy — from shipping estimates to fraud scoring.

WooCommerce stores use IP-based geolocation for three critical functions: shipping cost estimation before checkout, dynamic tax calculation, and fraud detection. Shipping estimates that rely on IP-derived location to pre-populate country and region fields will receive coarse data for Incognito visitors hitting third-party geoIP services. The estimate may default to a broader region instead of a specific city.

Fraud detection systems that flag orders based on IP-to-billing address mismatches will see noisier data. A legitimate customer in Sydney might show a coarse IP that resolves to “New South Wales” rather than “Sydney,” potentially triggering a false positive on location-mismatch rules. Fraud scoring models that weight IP precision heavily will need recalibration as coarse-geo IPs become more common.

The mitigation is the same for all three: move the IP-dependent logic to a first-party context. When your WooCommerce server captures the visitor’s IP directly from the incoming HTTP request — rather than relying on a third-party geoIP lookup script loaded in the browser — the IP is real, precise, and unaffected by IP Protection.

You may be interested in: Google Is Auto-Upgrading Your DSA Campaigns to AI Max — and AI Max Amplifies Whatever Conversion Signal It Can See

Why a First-Party Server Still Sees the Real IP#

Server-side first-party tracking is structurally immune to IP Protection because the tracking request is the first-party context itself.

When a visitor loads your WooCommerce product page, their browser sends an HTTP request to your server. Your server is the destination — the first-party context. IP Protection’s two-hop proxy chain only activates for requests to third-party domains on the MDL. Your own server is not a third-party domain. The request arrives directly, with the visitor’s original IP in the HTTP headers.

The Transmute Engine™ captures this IP at the server layer, along with the full HTTP request metadata — user agent, referrer headers, and session identifiers. Because the event capture happens in the first-party server context, it’s exempt from both IP Protection’s masking and the browser-side limitations that affect third-party analytics scripts.

This isn’t a workaround. It’s the intended design. Google built IP Protection with a deliberate first-party carve-out because legitimate first-party data collection is not the problem IP Protection was designed to solve. The feature targets cross-site tracking by third parties, not a website’s own understanding of its visitors.

For WooCommerce stores, the practical takeaway is that server-side first-party tracking doesn’t need to adapt to IP Protection — it was already built for this model. Every future browser privacy change that restricts third-party contexts while preserving first-party access confirms the same architectural principle: own the endpoint, own the data.

Key Takeaways#

• IP Protection is narrower than headlines suggest: It applies only in Incognito mode, only to third-party domains on the Masked Domain List, and only replaces precise IPs with coarse-geo IPs.
• First-party requests are unaffected: Your WooCommerce server receives the visitor’s original IP for any request sent directly to your domain, even in Incognito — this is the first-party carve-out by design.
• Third-party analytics will see degraded geo data: GA4, Facebook Pixel, and ad platform tags loaded as third-party scripts will receive coarse-geo IPs for Incognito users, reducing city-level accuracy.
• Geo-dependent workflows need migration: Shipping estimates, tax calculations, and fraud checks that rely on third-party geoIP lookups should move to first-party server-side IP resolution.
• Server-side first-party tracking is structurally immune: A server-side pipeline that captures IP at the WooCommerce server layer bypasses IP Protection entirely because the server is the first-party destination.

References#

• Google Privacy Sandbox. (2025). IP Protection. https://privacysandbox.google.com/protections/ip-protection
• Google Privacy Sandbox Help. (2025). IP Protection and Related Website Sets. https://support.google.com/privacysandbox/answer/16085870
• GoogleChrome. (2025). IP Protection GitHub repository. https://github.com/GoogleChrome/ip-protection
• Statista. (2024). Ad blocker usage worldwide. https://www.statista.com/statistics/435252/adblock-users-worldwide/

If your WooCommerce store relies on third-party scripts for geo data and analytics, talk to Seresa about building a first-party server-side tracking layer that IP Protection structurally cannot touch.