What Is a Universal Opt-Out Mechanism?

How does the signal actually work?

Technically it is simple, which is part of why the obligation is enforceable.

A browser or extension that supports GPC sends the header `Sec-GPC: 1` with requests, and exposes `navigator.globalPrivacyControl` as `true` to JavaScript on the page. That is the whole mechanism.

Two properties of it drive everything that follows.

It arrives at the web layer. The signal reaches your website or web app, not your CRM. Nothing about GPC touches Salesforce on its own.

It is anonymous by default. A browser sending the header is not telling you who it belongs to. If the visitor is not logged in and has not identified themselves, you have an opt-out signal attached to a session rather than to a person.

Why is this harder than it looks?

Because an opt-out is a durable fact about a person, and the signal is a transient fact about a browser session.

The gap between those two is where implementations fail. Four specific problems:

Identity resolution. Somebody browsing anonymously with GPC enabled, who later fills in a form or logs in, has expressed an opt-out that must now attach to the identified record. If your handling stops at the web layer, that link is never made.

Multiple devices. The same person on a laptop with GPC and a phone without it. The opt-out is a fact about the person, not the device, so the stricter signal should win.

Downstream propagation. Once the opt-out reaches the CRM record it has to be honoured by everything reading that record: campaign sends, audience exports, data shares with advertising platforms, third-party integrations, and increasingly AI features grounded on customer data.

Evidence. You need to be able to show when the opt-out was received, through which mechanism, and that it was applied. "Our website respects GPC" is not evidence about a specific person.

What does honouring the signal actually require?

Four steps, and most implementations only do the first.

Detect it at the web layer. Read the header or the JavaScript property on entry.

Apply it immediately for that session. Suppress the sale and sharing behaviours it covers, including advertising tags that would otherwise fire.

Persist it against the person as soon as they are identifiable. Form submission, login, or an existing identifier. This is the step that turns a session-level signal into a record-level state, and it is the one usually missing.

Make every downstream process respect that state. The opt-out field has to be read by every system and process that would otherwise sell, share or target that person.

A useful test: pick a customer record where an opt-out has been applied and ask which processes could still include them in an audience export. If nobody can answer confidently, the state is not being honoured, whatever the website does.

Which laws require it?

Several US state privacy laws mandate honouring universal opt-out signals, and the specifics differ by state: whether it is required or merely permitted, which processing it covers, and what the deadlines are. The set of states changes as new laws take effect and as regulations are issued under them.

Because that list moves, it is maintained in one place rather than repeated here. See US state privacy laws and your Salesforce org for the current position and what each state requires.

The design implication is stable even though the list is not: build the mechanism once, to the strictest applicable standard, and treat which-states as configuration.

Is a universal opt-out the same as consent withdrawal?

No, and conflating them causes real problems.

A GPC signal does not withdraw GDPR consent for email marketing, and withdrawing email consent does not opt someone out of data sale. They are separate states with separate triggers, and they need separate fields. Storing them in one flag loses information you will later be asked to produce.

What does this mean in Salesforce?

Salesforce is where the opt-out has to land and be honoured, even though the signal never touches Salesforce directly.

Store it as a first-class state on the person. Not as a marketing preference checkbox that only the campaign team knows about. Consent Management makes opt-out and consent state explicit fields with a record of when and how each was captured.

Wire the web layer to the record. Your site detects GPC. Something has to carry that into the CRM at the moment the visitor becomes identifiable, typically through the same integration that handles form submissions.

Enforce it on every read path. Campaign membership, list exports, integration payloads, data shares and AI grounding all need to respect the state, not just the marketing tool that happens to own the field.

Keep the evidence. When it arrived, through which mechanism, and what changed as a result.

The honest scope limit: the detection half of this happens on your website, and that is not something a Salesforce-native package touches. If your site does not read the signal, nothing downstream can honour it. Consent tooling in the CRM solves the second half of the problem, which is the half that usually gets skipped, but it does not solve the first.