The "Do Not Sell or Share" link: what has to happen after the click
The link is the half anyone can see. California gives you 15 business days to actually stop, and requires you to tell every third party you already shared with.
On this page
- The statute names the link, the words on it, and where it has to appear
- A cookie banner is not an opt-out mechanism, and the regulation says so in as many words
- Recording an opt-out and acting on one are different jobs
- Suppression has to land in four places downstream
- Google and Meta suppress customer lists in opposite geographies
- A green dashboard is not evidence, and there is a fine that says so
- Over-gating is a defect too, with a bill attached
- How to check yours in about ten minutes
- What to fix first
Short answer: the "Do Not Sell or Share My Personal Information" link is the half of an opt-out that anyone can see, and the half that gets audited is the other one. California's regulations give you no more than 15 business days from the request to stop selling or sharing that person's data, and require you to notify every third party you already sold or shared it to and direct them to do the same. A consent platform recording the opt-out does neither of those things. The suppression has to land in four places: your web container, your server container, the Conversions API payload, and whatever query builds your customer-list uploads.
None of this is legal advice, and the area moves. What follows is the regulator's own text with the dates we checked it, and the platform behaviour we can verify from vendor documentation.
The statute names the link, the words on it, and where it has to appear
Cal. Civ. Code § 1798.135(a)(1) is specific: a business that sells or shares personal information must provide a clear and conspicuous link on its homepages, titled "Do Not Sell or Share My Personal Information", leading to a page where someone can opt out. Subsection (a)(2) adds a second link, "Limit the Use of My Sensitive Personal Information", where sensitive data is used beyond the permitted purposes.
You can collapse the two. Subsection (a)(3) allows a single clearly labelled link instead, and 11 CCR § 7015 sets the terms: title it "Your Privacy Choices" or "Your California Privacy Choices", put the opt-out icon next to the title, and place it in the header or footer of your homepage. The icon has to be roughly the same size as the other icons around it.
Two details get missed. The links also belong in your privacy policy, alongside a description of the rights, under § 1798.135(c)(2). And under § 1798.135(d), a business that runs a separate California-facing homepage can put the links there instead of on the general one, provided Californians are actually directed to it.
There's also an exemption almost nobody uses. Under § 1798.135(b)(1), a business that honours an opt-out preference signal isn't required to post the link at all, and (b)(3) confirms you may elect either route. In practice most businesses do both, which is fine. What isn't fine is doing neither properly and assuming the browser signal covers you when nothing downstream reads it.
A cookie banner is not an opt-out mechanism, and the regulation says so in as many words
11 CCR § 7026(a)(4) addresses this directly: a cookie banner or cookie controls are not by themselves an acceptable method for submitting an opt-out request, because cookies concern the collection of personal information rather than its sale or sharing.
That single sentence invalidates a lot of what gets sold as US privacy compliance. The banner your CMP renders manages collection. An opt-out of sale and sharing is a different request about a different thing, and the regulation refuses to let one stand in for the other.
What § 7026(a)(1) actually requires of a business collecting personal information online is two methods at minimum: an opt-out preference signal, plus at least one of an interactive form reachable from the link, the Alternative Opt-out Link, or your privacy policy if you process the signal frictionlessly. A banner satisfies neither of those on its own.
Recording an opt-out and acting on one are different jobs
§ 7026(f) sets out what compliance consists of, and it's two obligations rather than one.
First, stop. Cease selling to and sharing with third parties as soon as feasibly possible, and no later than 15 business days from receipt. Service providers and contractors operating under the required written contract don't count as a sale or sharing, which is the distinction that decides whether a given vendor needs suppressing at all.
Second, propagate. Notify every third party you sold or shared that person's data to between the request arriving and you complying, direct them to comply, and direct them to forward the request onward to anyone they passed it to. That is an outbound obligation, and no consent platform performs it for you.
The intake side has rules too, and they're the ones businesses tend to over-engineer. You cannot require an account (§ 7026(c)). You cannot require a verifiable consumer request (§ 7026(d)): you may ask for what's needed to identify whose data to suppress, but where you can comply without it, you must. And once someone opts out, you wait at least 12 months before asking them to opt back in (§ 7026(k)).
Suppression has to land in four places downstream
The click sets a state. The state is worth nothing until something reads it. These are the four surfaces where that happens, and they fail independently.
| Surface | What carries the opt-out | What happens if it's missing |
|---|---|---|
| Web container | Google's restricted_data_processing parameter on the tag, the Enable Restricted Data Processing field in the GTM Google Ads tags, or fbq('dataProcessingOptions', ['LDU'], 1, 1000) for Meta | The browser keeps sending identifiers for personalised use, with the opt-out recorded one layer above |
| Server container | The same flags, set on the outbound payload the server builds | The server container re-emits a clean event. Suppression applied in the browser does not travel with it |
| Conversions API | data_processing_options, data_processing_options_country and data_processing_options_state, inside each event in the data array | Meta processes the event with no restriction. The field is per-event, so one unflagged path leaks all of it |
| Customer-list exports | Nothing platform-side you can rely on. See below | An opted-out person is uploaded on the next scheduled run, days after you stopped serving them ads |
The server container is the one that catches people out. It's a separate dispatch that builds its own payload, so a flag set in the browser reaches it only if you deliberately pass it through and deliberately re-apply it. If you run a split client and server dispatch, that's two places to set the same flag, not one.
Meta's requirement to put the fields inside each event is worth reading twice. It isn't an account setting or a container setting. Every event your server sends either carries it or doesn't.
Google and Meta suppress customer lists in opposite geographies
This is the part that has no clean answer, and pretending otherwise is how people end up uploading opted-out customers.
Google's position, on its own advertiser help page: as of 1 July 2023 Google no longer acts as a service provider in California for cross-context behavioural advertising, and restricted data processing is therefore not offered for Customer Match there. The same page notes that restricted data processing doesn't extend to onward disclosure to third parties you've enabled, and that an audience exported into another product picks up the recipient product's terms.
Meta's documentation, updated 21 May 2026, runs the other way. Limited Data Use is available for Customer List Custom Audiences in California and, per its own state table, in none of the other thirteen states where LDU applies to Business Tools. California is the only state where the customer-list route works.
So Google's customer-list suppression excludes California, and Meta's applies only to California. Neither gives you a switch that covers a US-wide list. The consequence is unglamorous and hard to argue with: suppression for list uploads belongs in the query that builds the export, before anything leaves your systems. An opted-out record should not be in the file. This is the same discipline that consent-gating a Customer Match upload demands in the UK, arrived at from the opposite direction.
A green dashboard is not evidence, and there is a fine that says so
In May 2025 the California Privacy Protection Agency issued a decision requiring the retailer Todd Snyder, Inc. to pay $345,178 and overhaul its practices. The allegations are worth reading as a checklist: the company failed to oversee and properly configure the technical infrastructure of its privacy portal, which meant opt-out requests went unprocessed for 40 days. It required more information than necessary to process privacy requests. And it required consumers to verify their identity before they could opt out, which § 7026(d) does not permit.
The portal existed. The link existed. For 40 days neither did anything, and the dashboard presumably looked fine throughout. Michael Macko, who heads the agency's enforcement division, put the principle plainly: "Using a consent management platform doesn't get you off the hook for compliance."
Four months later the agency announced a joint investigative sweep with the Attorneys General of California, Colorado and Connecticut, contacting businesses that appeared not to be processing opt-out requests submitted by browser signal. The enforcement attention is on whether the mechanism works, not whether it's installed.
Which is why the thing worth keeping is a record of what your system did with each request and when, rather than a vendor's summary of it. Logging the consent state yourself is the same argument applied to the other half of the problem.
Over-gating is a defect too, with a bill attached
An opt-out regime is not an opt-in regime, and treating it as one costs real money.
The default under CCPA is that you may sell or share until someone tells you not to. Suppression applies to the people who clicked the link and the people arriving with an opt-out preference signal. It applies to nobody else. A container configured to gate everyone in the US, or everyone whose consent state is merely unknown, is broken in the direction that looks responsible and reports as lost conversions.
Google's own documentation is explicit that restricted data processing is not the same as switching measurement off: with it enabled, conversion tracking and campaign measurement continue to function normally. What changes is the personalisation, the remarketing list additions, and the related audience functionality. If someone tells you honouring opt-outs means going dark on reporting, they've described a misconfiguration rather than a requirement.
How to check yours in about ten minutes
Do each step in a fresh private window, because a stored opt-out from an earlier visit will hand you a false pass.
- Find the link from the homepage without searching. Header or footer. If it takes you more than a few seconds, it isn't conspicuous.
- Submit an opt-out and watch what it asks for. An account requirement or an identity check before the opt-out is the exact pattern the Todd Snyder decision penalised.
- Reload and read the network, not the confirmation. Filter for your ad platform endpoints. You're looking for the restriction flags on the requests that still fire, not for the requests to disappear.
- Check the server container separately. Inspect the payload it builds and sends onward. This is the step that gets skipped, and the one where suppression usually stops.
- Open your customer-list export and search for the opted-out record. If it's still in the file, nothing above matters.
For the parts of that you'd rather not do by hand, the Consent Mode v2 detector loads your live site and reports what fires before any consent interaction and whether the consent signals are genuinely present, which covers steps three and four's browser half.
What to fix first
Start with the export query, because it's the only one of the four surfaces where a mistake keeps running on a schedule after everything else is fixed. Then the server container, then the browser tags, then the link itself.
That order is deliberately the reverse of how this work usually gets done. The link is the visible artefact, so it gets built first and audited never. The export is invisible, runs weekly, and will happily upload someone who opted out in March.
If you want the whole path checked rather than assumed, from the click through to what your platforms actually received, that's the work we do.
Sources
- 1.Cal. Civ. Code § 1798.135 — methods of limiting sale, sharing and use of personal information · Checked 2026-09-17
- 2.Cal. Code Regs. Tit. 11, § 7026 — Requests to Opt-Out of Sale/Sharing · Checked 2026-09-17
- 3.Cal. Code Regs. Tit. 11, § 7015 — Alternative Opt-Out Link · Checked 2026-09-17
- 4.CPPA — decision requiring Todd Snyder, Inc. to change its practices and pay a $345,178 fine · 6 May 2025
- 5.CPPA — joint investigative sweep with the Attorneys General of California, Colorado and Connecticut · 9 September 2025
- 6.Google Ads Help — Helping advertisers comply with the U.S. states' privacy laws in Google Ads · Checked 2026-09-17
- 7.Meta for Developers — Data processing options for US users, Marketing API (Limited Data Use) · Updated 21 May 2026; checked 2026-09-17