Global Privacy Control (GPC) started life as a browser-sent “do not sell or share my data” header, mostly relevant to web publishers under California’s CCPA. As of January 2026, that’s changed: Kentucky, Rhode Island, and Indiana have all added explicit requirements to recognise and honour GPC signals, joining California and Colorado on a growing list of US states with binding opt-out-signal laws. For any product with a web presence — including a marketing site sitting in front of a mobile app — this is no longer a niche compliance detail one legal team in one state cares about. It’s a multi-state floor that keeps rising.
The tracking gap most teams have is simple: they built consent banners that respond to a button click, but nothing that listens for a GPC signal arriving silently in the request headers before the user does anything at all. If your analytics and ad tags fire before that signal is checked — or don’t check it in the states that now require it — you’re out of compliance the moment a covered visitor loads the page, with no interaction needed to trigger the violation.
Data Points to Track
- GPC signal presence: whether
Sec-GPC: 1was present on the request, logged per session before any tracking tag fires - State jurisdiction match: whether the visitor’s inferred state falls under a law that currently mandates GPC recognition (CA, CO, KY, RI, IN, and growing), since the signal itself is state-agnostic but your obligation isn’t
- Pre-consent tag fire count: any analytics, ad, or personalisation script that fired before the GPC check completed — this should be zero
- Opt-out honoured confirmation: an explicit event logging that sale/share-related processing was actually suppressed for that session, not just that the signal was received
- Signal-to-suppression latency: time between the GPC header arriving and downstream tags being blocked, for pages using deferred or async tag managers
Setup Steps
- Detect the GPC header server-side, before your tag manager loads anything, rather than relying on a client-side script that runs after third-party tags have already fired.
- Map GPC recognition to jurisdiction, since not every US state currently requires honouring it — build this as a maintained list, not a one-time hardcode, given how fast the state count is growing.
- Wire GPC-positive sessions into the same suppression path your cookie-banner opt-out already uses, so you’re not maintaining two separate consent code paths that can drift out of sync.
- Log a suppression-confirmed event for every GPC-honoured session, giving you an audit trail if a regulator or user ever asks whether the signal was actually respected.
- Add a recurring check to your release process that re-verifies no tag fires ahead of the GPC check, since a single tag-manager update can silently reintroduce a pre-consent fire.
Actionable Insights
The suppression-confirmed event is the one piece of data that actually protects you: a signal received without a corresponding suppression action is a compliance gap you can’t see without it, and a regulator’s first question after “did you receive the signal” is “what did you do about it.” Teams that can answer both from their own logs are in a materially different position than ones relying on a vendor’s word that GPC is “handled.”
Treat the jurisdiction list as a living document rather than a launch-day decision — three states added this requirement in the same month, and the pattern suggests more will follow. Building the detection and suppression logic to be state-agnostic from the start (honour GPC everywhere, rather than maintaining a per-state toggle) is usually less engineering effort long-term than re-litigating the jurisdiction map every time a new state passes a law.
Related Resources
Need help tracking this in your app?
Our team sets up analytics pipelines for mobile and web teams every day. Talk to us and get your first events flowing in under an hour.
Talk to an expert