California CIPA and Website Tracking in 2026: Consent, GPC, and the “Do Not Sell or Share” Rule

California website privacy can no longer be handled as a generic “show a cookie banner and continue” task. This review separates the California Invasion of Privacy Act (CIPA) from the CCPA/CPRA, explains what actually changed in 2025–2026, and turns the legal distinctions into a practical, location-aware Cookiebot/Usercentrics implementation for analytics and advertising teams.

Practical default: do not treat a visible banner, a stored consent value, or a green status in a tag manager as proof that a California implementation works. First map what each technology transmits. Then block high-risk third-party capture before the required consent exists, honor Global Privacy Control before optional sale or sharing occurs, and verify the result in the browser’s Network panel and in downstream platforms.

Status date: this article reflects California statutes, regulations, enforcement materials, and the status of Senate Bill 690 reviewed on 22 August 2026. SB 690 was still an active bill in the Assembly floor process and had not become law on that date.

Executive summary

The Usercentrics partner message that prompted this review is directionally useful but legally compressed. It describes a California-specific configuration that combines true opt-in blocking with a “Do Not Sell or Share” control. That can be a sensible product architecture, but those two controls come from different legal questions.

CIPA is an older anti-wiretapping and anti-eavesdropping law. Its website risk does not come from a newly added cookie-banner clause. It comes from litigation applying existing provisions—especially California Penal Code Section 631—to real-time website communications observed or received by third-party technologies. In the influential but unpublished Javier v. Assurance IQ decision, the Ninth Circuit concluded that Section 631 applies to internet communications and predicted that California law requires consent before the communication is recorded. The court did not decide every remaining issue, including whether the vendor was legally a third party.

The CCPA, as amended by the CPRA, is the source of the right to opt out of the sale or sharing of personal information, the Global Privacy Control requirement, and the familiar “Do Not Sell or Share My Personal Information” link or an allowed alternative. The California privacy rules effective in 2026 expressly state that a cookie banner or cookie-control tool is not, by itself, an acceptable sale/sharing opt-out mechanism. A cookie control focuses on collection; a valid opt-out must also stop the relevant sale or sharing.

The most discussed CIPA bill, SB 690, changed substantially during the legislative process. Earlier versions proposed a broad “commercial business purpose” exclusion across several CIPA provisions. The version amended on 2 July 2026 removed that broad approach. As of the status date, the bill would instead limit private website and app claims under the pen-register provision, Section 638.51, by reserving those actions to the Attorney General. It would not eliminate private Section 631 website-tracking claims.

The correct operational conclusion is therefore not “California has become another GDPR.” It is more precise:

• some technologies may need prior blocking because of CIPA interception risk;
• covered CCPA businesses that sell or share personal information must implement a valid opt-out architecture and honor Global Privacy Control;
• a location-aware CMP can avoid applying the strictest rule indiscriminately to every US visitor;
• the CMP must control the real data flows, not merely display a compliant-looking interface;
• the exact legal position remains fact-specific and should be reviewed with privacy counsel.

What the Usercentrics message gets right—and what needs clarification

Vendor message	More accurate interpretation	Implementation consequence
California now needs specific CIPA handling.	CIPA was not newly rewritten to prescribe a website banner. The urgency comes from the continued application of existing interception rules to websites, plus a large volume of private litigation.	Audit the actual tracker behavior instead of applying a generic “California cookies” label.
A normal opt-in or opt-out banner is not enough.	This is operationally correct. CIPA risk depends on what transmits before consent, while CCPA compliance depends on whether sale/sharing and GPC requests are actually honored.	Test network requests, vendor receipt, server-side forwarding, and downstream use—not only the banner state.
The California template combines opt-in blocking with “Do Not Sell or Share.”	That is a practical combination of two regimes. Prior blocking addresses a CIPA risk posture; “Do Not Sell or Share” is a CCPA/CPRA control.	Keep the purposes and legal records separate even if one interface presents both.
The stricter experience appears only for visitors who need it.	Regionalization can reduce unnecessary measurement loss, but IP geolocation is imperfect and privacy signals can carry obligations beyond a simple state lookup.	Define a conservative fallback for unknown locations, VPNs, logged-in accounts, and conflicting signals.
The configuration protects campaign performance.	A regional model can avoid applying blanket EU-style opt-in rules across the United States. It cannot justify firing prohibited tags or ignoring an opt-out.	Preserve measurement through lawful first-party design, data minimization, and approved modeling—not by bypassing user choice.

A “CIPA template” is therefore best understood as a vendor implementation pattern, not a government-approved safe harbor. California law does not certify CMP templates, and no template can classify every script, contract, data field, or downstream vendor use automatically.

CIPA and CCPA solve different privacy problems

Question	CIPA	CCPA/CPRA
Primary legal source	California Penal Code, including Sections 631, 637.2, and 638.51.	California Civil Code Section 1798.100 and following, plus California Privacy Protection Agency regulations.
Core concern	Unauthorized interception, reading, recording, or related use of communications.	Collection, disclosure, sale, sharing, sensitive-information use, notices, contracts, and consumer rights.
Website trigger	A third-party technology may receive or observe a communication in real time, potentially including its contents or meaning, before valid consent.	A covered business sells or shares personal information, uses sensitive personal information beyond allowed purposes, or otherwise engages in regulated processing.
Typical control	Prior notice and consent, plus technical blocking where the relevant data flow must not begin before consent.	Notice at collection, opt-out of sale/sharing, GPC processing, privacy-choice links or permitted alternatives, contracts, and downstream suppression.
Does a “Do Not Sell or Share” link come from this law?	No.	Yes, where the statutory conditions apply, unless the business qualifies for and correctly implements an allowed alternative.
Private litigation risk	Section 637.2 currently permits statutory damages of $5,000 per violation or three times actual damages, and actual damages are not a prerequisite.	Sale/sharing and opt-out obligations are primarily enforced by California regulators; the CCPA private right of action is much narrower and mainly associated with specified data-security incidents.
Business thresholds	CIPA does not use the CCPA’s business-coverage thresholds.	Applicability depends on the statutory definition of a covered business and the particular data practice.
Technical proof	Timing, request destinations, payloads, vendor role, and whether the transmission occurred before consent.	Whether the opt-out propagates across browser, profile, account, APIs, advertising partners, and other sale/sharing paths.

This distinction matters because a site may face a CIPA theory even when its team concludes that the business is outside CCPA scope. The reverse is also possible: a business may have clear CCPA sale/sharing duties even where a particular tracker presents a weak CIPA interception theory. A single banner category cannot answer both questions.

Why CIPA became a website-tracking issue

Section 631 was written broadly

Section 631 predates modern websites. Among other things, it addresses a person who, without the consent of all parties or in an unauthorized manner, reads or attempts to learn the contents or meaning of a communication while it is in transit. Plaintiffs have applied that language to the modern browser flow:

The legal outcome can depend on details that a cookie inventory often misses:

• whether the transmitted data is merely routing or device information, or reveals the contents or meaning of a communication;
• whether the vendor receives the data contemporaneously or only after the website receives and stores it;
• whether the vendor is an independent third party, uses the data for its own purposes, or functions only as a tightly controlled service provider or extension of the website;
• whether the visitor received sufficiently clear notice before the transmission;
• whether consent was express, implied, or absent;
• whether the relevant communication occurred “within” California for the statute’s purposes;
• which clause of Section 631 is actually alleged.

These are reasons to avoid statements such as “all analytics are illegal without opt-in” or “a service-provider contract automatically solves CIPA.” Both are too broad.

The practical importance of prior consent

In Javier v. Assurance IQ, a third-party tool allegedly captured the visitor’s interactions with an insurance questionnaire in real time, including demographic and medical information. The privacy-policy acceptance appeared later. The Ninth Circuit rejected the idea that later acceptance necessarily supplied retroactive consent and predicted that the California Supreme Court would require prior consent under Section 631.

The decision must be read carefully. It was unpublished and is not precedential except under the relevant Ninth Circuit rule. It also did not decide whether the technology provider was a third party, whether implied consent existed, or whether other defenses applied. Nevertheless, it shaped the operational question that website teams can control: did the data flow begin before the visitor’s choice?

For a risk-sensitive implementation, “consent recorded at 10:00:05” does not repair a third-party request sent at 10:00:01. The gate must sit before the script, iframe, pixel, beacon, SDK initialization, or other transmission that the policy is intended to prevent.

Why the exposure can become disproportionate

Section 637.2 allows an injured person to seek the greater of $5,000 per violation or three times actual damages, and says actual damages are not a necessary prerequisite. This statutory structure helps explain why a seemingly small implementation mistake can attract class-action claims.

It does not mean that every request automatically produces a valid $5,000 claim. Courts still examine standing, statutory elements, consent, the vendor’s role, jurisdiction, and other defenses. It does mean that “the tracker collects only a little data” is not an adequate risk assessment.

What actually changed in California in 2025–2026

SB 690 was narrowed and was still pending

SB 690 generated headlines because earlier versions proposed broad CIPA amendments for processing performed for a “commercial business purpose.” Those versions would have affected Sections 631, 632, 632.7, 637.2, and the pen-register definitions. That broad language is visible as deleted text in the Legislature’s official version comparison.

The 2 July 2026 amended text is much narrower. It would amend Section 637.2 so that an action against a private actor for a Section 638.51 violation arising from conduct on a website, online application, or mobile application could be brought only by the Attorney General. The limitation would apply retroactively to certain pending claims filed within two years before the bill’s operative date.

As of 22 August 2026, the official bill status showed SB 690 as an active bill in the Assembly floor process, ordered to third reading. It was not enacted. More importantly for website owners, the current version did not amend Section 631. Even if enacted without further changes, it would not make Section 631 tracker litigation disappear.

SB 690 question	Answer as of 22 August 2026
Is SB 690 already law?	No.
Does the current bill create a broad exemption for ordinary commercial tracking?	No. That approach was removed from the current text.
Would the current bill affect website/app pen-register claims under Section 638.51?	Yes. It would reserve the specified private-actor action to the Attorney General.
Would it remove private website claims under Section 631?	No, not in the current version.
Should implementation be postponed in expectation of the bill?	No. The bill may still change, fail, or be enacted in a different form, and it does not currently solve Section 631 risk.

The CCPA rules in force in 2026 make the technical distinction explicit

Civil Code Section 1798.135 requires a covered business that sells or shares personal information to provide the prescribed opt-out control, subject to the statute’s alternative mechanisms. The consolidated CCPA statute and regulations effective 1 January 2026 add practical detail:

• a business that sells or shares personal information online must process a qualifying opt-out preference signal;
• the request applies to the browser or device and associated pseudonymous profiles, and may extend to a known consumer or account;
• the site must display whether it processed the signal as a valid opt-out request;
• posting a “Do Not Sell or Share” link does not give the business permission to ignore Global Privacy Control;
• a cookie banner or cookie controls are not, by themselves, an acceptable sale/sharing opt-out method;
• the process must be easy, require minimal steps, and avoid unnecessary identity verification;
• the business must stop the relevant sale or sharing as soon as feasibly possible and no later than the regulatory deadline, although real-time advertising flows may require an immediate technical response.

The law allows a business to omit the standard link in a qualifying frictionless opt-out-preference-signal model. That is a conditional alternative, not a general permission to hide privacy controls. Many businesses will still use a clear “Do Not Sell or Share My Personal Information” or combined privacy-choices link because it gives visitors without GPC a direct method and makes the implementation easier to explain.

California is pushing browser-level opt-out signals into the mainstream

Assembly Bill 566, sometimes called the California Opt Me Out Act, was signed on 8 October 2025. Beginning 1 January 2027, the law prohibits a covered business from developing or maintaining a browser that lacks a consumer-configurable function capable of sending an opt-out preference signal as prescribed by the statute.

This change does not turn GPC into CIPA consent. It does make universal opt-out signals more important for advertising, audience, and data-sharing architectures. A CMP that detects GPC only after ad tags fire, or stores the signal only in a browser cookie without propagating it to the known account and downstream systems, is increasingly difficult to defend.

Enforcement now tests whether the controls work, not whether they exist

Recent CCPA enforcement actions are not CIPA cases, but they show how California regulators evaluate implementation quality:

Action	What regulators alleged or required	Operational lesson
Healthline, 1 July 2025	A $1.55 million settlement addressed allegations that consumers were not properly opted out of targeted advertising, data was shared without required protections, and a consent banner did not disable tracking as represented.	Banner wording and toggles must match the real tracker behavior, especially for sensitive page context.
Disney, 11 February 2026	A $2.75 million settlement addressed incomplete opt-outs across devices, services, account-linked activity, embedded ad-tech companies, and GPC handling.	A privacy choice cannot stop at one device, one streaming property, or one internal ad platform when the business can associate the user more broadly.
Ford, 5 March 2026	The California Privacy Protection Agency imposed a $375,703 fine and required changed practices after Ford added an email-verification step to the opt-out process. Ford was also required to audit website tracking technologies and ensure GPC compliance.	Do not treat an opt-out as a verified access or deletion request. Remove unnecessary steps and audit every tracker path.

Why a normal cookie banner can still fail

A banner is only the interface. A functioning privacy architecture has at least five separate layers:

1. Notice: what the visitor is told, when it is shown, and whether it is understandable.
2. Choice: what the visitor can accept, reject, opt out of, or limit.
3. Technical gating: which scripts, requests, pixels, iframes, beacons, and SDKs can run in each state.
4. Downstream use: what the receiving vendor, advertising platform, CRM, or data warehouse may do with the data.
5. Proof: logs, request captures, configuration records, contracts, and repeatable tests showing that the choice was honored.

A site can display a polished California banner and still fail at any of the remaining layers. Common examples include:

• a session-replay script is hardcoded in the theme and starts before the CMP initializes;
• GTM shows a tag as “blocked,” but an equivalent pixel is injected by a plugin;
• the browser tag is blocked, while the application server forwards the same lead or page data to the vendor;
• the “Do Not Sell or Share” toggle changes a cookie but does not suppress advertising APIs or audience uploads;
• GPC is read after the first page-view requests are sent;
• the choice applies only to the current domain and not to associated brands or an authenticated account;
• the banner says tracking is disabled, but requests continue with identifiers or content-rich parameters;
• consent is obtained after the tracker has already captured form entries, clicks, chat text, or replay data.

A “denied” signal is not always the same as no transmission

This distinction is particularly important in Google Consent Mode and similar systems. A tag can receive a denied consent state yet still send a limited or cookieless request in an advanced implementation. That may be appropriate for a particular product and legal policy, but it is not the same as preventing all communication with the vendor.

Where the site’s CIPA risk policy requires that a specific third party receive nothing before affirmative consent, the implementation must use true blocking for that technology. For a deeper explanation of defaults, updates, built-in checks, and tag re-triggering, see metricfixer’s guide to Consent Mode v2 diagnostics.

GPC is a separate privacy input

Global Privacy Control can be exposed as an HTTP request header and through a browser API. A technically complete implementation should evaluate the signal before optional sale/sharing activity begins and should not rely only on a later JavaScript callback.

HTTP request header:
Sec-GPC: 1

Browser API:
navigator.globalPrivacyControl === true

The GPC specification also defines an optional /.well-known/gpc.json resource through which an origin can state its support. Publishing that file does not, by itself, prove that every downstream system honors the signal.

Reference architecture for a California-aware Cookiebot/Usercentrics setup

The following pattern treats geolocation, CIPA-oriented prior blocking, and CCPA opt-out rights as related but distinct controls.

Step 1: inventory data flows, not cookie names

A cookie scanner is useful, but the audit should begin with every path that can disclose visitor or customer information:

• hardcoded scripts and tags;
• GTM and other tag-manager containers;
• session replay, heatmaps, and form analytics;
• chat, call tracking, lead-routing, and appointment widgets;
• advertising pixels and conversion APIs;
• embedded video, maps, social posts, and review widgets;
• fraud, security, payment, and identity tools;
• server-side GTM clients and tags;
• backend webhooks, CRM automations, offline conversion uploads, and audience synchronization;
• mobile or web SDKs loaded alongside the website;
• plugins that inject code outside the CMP or tag manager.

For each flow, record the trigger, destination, timing, fields, identifiers, retention, contract role, vendor’s independent uses, and whether the flow supports sale, sharing, cross-context behavioral advertising, or another regulated purpose.

Step 2: classify the technology by legal and technical risk

Technology	CIPA-focused review	CCPA-focused review	Practical default pending review
Security, fraud prevention, load balancing	Does it inspect communication contents beyond what is needed to operate or protect the service?	Is the use within a permitted business purpose and covered by the correct contract?	Allow only the minimum necessary flow; document purpose and fields.
Audience measurement and analytics	Does it transmit full URLs, search terms, click text, form values, user IDs, or replay-like interaction data in real time?	Does the vendor use the data only as a service provider/contractor, or for its own advertising and cross-context purposes?	Do not assume “analytics” is automatically low risk. Minimize payloads and gate where required.
Advertising pixels and remarketing	What page context, form state, identifiers, or event details are sent before a choice?	Does the flow constitute sale/sharing or cross-context behavioral advertising, and does GPC suppress it?	High-priority candidate for California-specific blocking and opt-out enforcement.
Session replay and form recording	Does the vendor capture interactions or entries contemporaneously, even if some fields are masked later?	What personal information is disclosed, and may the vendor use it beyond the service?	Treat as high risk; block until the required prior choice and validate masking before production.
Chat, lead forms, call tracking	Can the third party receive message text, typed-but-not-submitted fields, phone details, or health/financial context?	Are leads shared onward, used for advertising, or uploaded to audiences and ad platforms?	Use explicit notice close to the interaction and prevent premature capture.
Embedded media, maps, and social widgets	Does merely loading the embed disclose the page and visitor details to the third party?	Does the provider combine the visit with data from other contexts?	Consider click-to-load placeholders or a consent gate for optional embeds.
Server-side tagging and conversion APIs	Did the browser communicate only with the first-party site before a later server disclosure, or is a third party still involved contemporaneously?	Does the server transfer constitute sale/sharing, and are opt-out and consent states included and enforced?	Do not treat server-side delivery as an exemption. Use it for control and minimization, not concealment.

Step 3: build the California regional rule

A defensible California rule set usually needs more than one binary variable:

• Jurisdiction state: California, another US state, EEA/UK/Switzerland, or unknown.
• CIPA gate: whether each high-risk third-party communication may begin before affirmative consent.
• CCPA sale/sharing state: allowed, opted out through the site, opted out through GPC, or not applicable after documented analysis.
• Sensitive-information limitation: whether a separate limitation applies.
• Purpose state: analytics, advertising, personalization, functional, security, and other defined purposes.
• Identity scope: current browser/device, pseudonymous profile, known account, and offline records.

Geo-IP should not be the only source of truth. It can be wrong because of VPNs, corporate gateways, mobile networks, travel, and database lag. Define what happens when location is unknown, and retain the more privacy-protective signal when a known user’s account choice conflicts with a later location guess.

Step 4: place the gate before every relevant request

“True opt-in blocking” should mean that the restricted third-party request does not leave the browser before the required choice. Review all of the following:

• <script> tags and dynamic script loaders;
• tracking pixels implemented as <img> requests;
• third-party <iframe> elements;
• fetch, XMLHttpRequest, and sendBeacon calls;
• SDK initialization and automatic page-view collection;
• hardcoded preloads or preconnects to optional third parties;
• plugin- or CMS-injected tags outside GTM;
• requests made by a service worker;
• server-side events triggered automatically from the same page interaction.

Do not wait for DOMContentLoaded, a normal GTM page-view event, or a delayed CMP callback if the restricted tag can run earlier. In GTM, the consent default and any required region logic should be established at the earliest supported stage, and tags that require complete blocking should have an actual firing gate rather than a reporting-only consent parameter.

Step 5: honor GPC end to end

A complete GPC implementation should:

1. read the incoming header where server infrastructure permits;
2. read the browser property before optional tags execute;
3. set the sale/sharing state to opted out without asking the visitor to repeat the request;
4. show that the request was honored;
5. apply it to the browser/device and associated pseudonymous profile;
6. apply it to the known account or consumer where the business can associate them, subject to the precise regulatory rules;
7. suppress affected browser tags, server-side forwarding, audience creation, activation, and advertising-partner disclosures;
8. preserve the opt-out after cookies are cleared when an account-level record is available;
9. avoid treating a later absence of the signal as automatic opt-in.

California’s Attorney General describes GPC as a valid request that covered businesses must honor. The practical scope is broader than hiding a single pixel on the landing page.

Step 6: propagate the privacy state beyond the browser

Many implementations fail after the CMP has done its job correctly. The browser blocks an advertising pixel, but the same data reaches the platform through another route. Propagate the state to:

• server-side GTM and custom collection endpoints;
• Meta Conversions API, Google enhanced conversion workflows, and other conversion APIs where used;
• CRM lead enrichment and audience exports;
• offline conversion uploads;
• data warehouses and reverse-ETL activation;
• email, personalization, and recommendation platforms;
• account-level privacy settings and associated services;
• vendors that previously received data and must be notified under applicable rules.

The state should be enforceable, not merely informational. A field such as sale_sharing_opt_out=true is useful only if every relevant job, connector, and destination checks it before processing.

How to protect measurement without treating privacy as a tracking error

The performance concern in the Usercentrics message is real. Applying an EU-style opt-in model to every visitor in every US state can reduce measured sessions, conversions, remarketing audiences, and platform feedback more than the applicable US rules require. A correctly configured regional model can reduce that unnecessary loss.

However, “preserving performance” must not become a reason to send prohibited data first and ask questions later. Better mitigation includes:

• collecting only the fields required for measurement;
• removing sensitive query parameters, form values, page titles, and free text from analytics and ad payloads;
• using first-party identifiers and server-controlled routing only where the legal basis and contracts permit it;
• separating service-provider measurement from cross-context advertising uses;
• configuring platform consent parameters accurately;
• using aggregated or modeled reporting where the platform supports it and where the implementation does not circumvent the visitor’s rights;
• measuring consent and opt-out rates by region so stakeholders understand the expected data gap;
• keeping business reporting capable of distinguishing “no conversion occurred” from “the conversion was not observable for this purpose.”

Server-side tagging can improve governance because the business controls fields and destinations centrally. It does not legalize a disclosure that the browser would not be allowed to make, and it does not erase a CCPA sale/sharing opt-out. For broader context on regional consent design, see Website Consent Signals Around the World.

Testing matrix: prove that the implementation works

Use a fresh browser profile and preserve HAR files or equivalent evidence for each scenario. Tag Assistant, CMP debug panels, and platform diagnostics are supporting tools; the browser Network panel and downstream receipt are the primary technical evidence.

Test state	Expected behavior	What to inspect
California, no GPC, no choice yet	Strictly necessary services may run. Technologies classified for prior blocking remain silent. Applicable privacy-choice controls are visible.	Requests from the first byte through CMP display; hardcoded scripts, iframes, preconnects, and server-triggered events.
California, affirmative consent	Only the approved categories and vendors load. The consent record contains the correct version, region, purposes, and timestamp.	New requests after the choice, payload minimization, duplicate tags, and downstream receipt.
California, reject or opt out	Restricted tags remain blocked or stop as required. Sale/sharing paths and audience activation are suppressed.	Browser requests, server-side tags, CRM connectors, advertising APIs, and scheduled exports.
California, GPC enabled	The site treats GPC as an opt-out request, displays the honored status, and suppresses relevant sale/sharing without requiring extra verification.	Sec-GPC, navigator.globalPrivacyControl, browser/device state, profile/account propagation, and partner calls.
California, logged-in user across services	The opt-out is applied across the account and associated services to the extent the business knows the relationship and the rules require.	Other domains, apps, devices, internal advertising systems, and account settings.
Returning visitor after withdrawal	The withdrawn consent is not silently restored. Previously allowed optional tags no longer run.	Persisted cookies/local storage, server profile, CMP state, cache, and tag-manager variables.
Other US state	The relevant state rule is applied without automatically inheriting or weakening California controls.	Geo rule selection, universal opt-out signals, state-specific notices, and fallback logic.
EEA/UK visitor	The separate prior-consent regime and applicable Google/vendor signals are applied.	Regional template selection, default consent, tag blocking, and CMP record.
Unknown location or VPN	The documented fallback is used and does not silently choose the least protective state.	Geo lookup failure, CDN headers, consent defaults, and account-level choices.

Implementation checklist

• [ ] Inventory every browser-side and server-side destination, not only cookies.
• [ ] Capture the clean-page network sequence before any interaction.
• [ ] Identify technologies that can receive form fields, chat text, full URLs, page titles, search terms, clicks, replay data, or other communication content.
• [ ] Document vendor role, contract restrictions, independent uses, and subprocessor paths.
• [ ] Decide which technologies require prior blocking for California after legal review.
• [ ] Configure the Cookiebot/Usercentrics regional rule and a documented unknown-location fallback.
• [ ] Read GPC before optional sale/sharing or advertising flows start.
• [ ] Display the processed GPC/opt-out status to the visitor.
• [ ] Provide the “Do Not Sell or Share” or allowed alternative control where applicable.
• [ ] Make accept, reject, and privacy-choice paths similarly clear and easy.
• [ ] Prevent hardcoded tags, plugins, service workers, and embeds from bypassing the CMP.
• [ ] Distinguish Consent Mode signaling from complete network blocking.
• [ ] Propagate consent and opt-out states into server-side tagging, CRM, APIs, audiences, and offline uploads.
• [ ] Test account-level and cross-device behavior for known users.
• [ ] Verify withdrawal and returning-visitor behavior.
• [ ] Preserve configuration versions, screenshots, HAR files, logs, and test results.
• [ ] Re-audit after tag-manager publications, CMS/plugin updates, CMP changes, and new marketing vendors.
• [ ] Track the final status and text of SB 690 instead of relying on summaries of its earlier version.

Cookiebot implementation support from metricfixer

Open questions and limitations

CIPA website litigation remains fact-dependent and not fully settled. Federal and state courts may differ on the vendor-as-party or extension analysis, the meaning of communication contents, jurisdiction, implied consent, standing, and other defenses. Javier is influential for prior consent but unpublished and nonprecedential except under the applicable rule.

A strict California opt-in gate for selected technologies is therefore a risk-management architecture, not a statement that California law universally requires prior consent for every nonessential cookie or analytics request. Conversely, labeling a vendor “analytics,” “service provider,” or “server-side” does not automatically remove CIPA or CCPA risk.

SB 690 may change after the article’s status date. If enacted, its final text, operative date, retroactivity, and any litigation over its application must be reviewed before changing production controls.

Geo-IP is inherently imperfect. Businesses with authenticated accounts, multiple brands, apps, connected devices, or offline data should not assume that a one-page regional banner can satisfy account-wide privacy obligations.

Related metricfixer reading

• Website Consent Signals Around the World: Where a Banner Is Required—and Where GPC Matters More
• Consent Mode v2 Is Configured—but Google Still Says It Is Not
• Google Ads Data Processing Terms: What Advertisers and Agencies Need to Know

Methodology and sources

This article is based on a review of the Usercentrics partner communication received by metricfixer in August 2026, the current California Penal Code and Civil Code, the consolidated CCPA statute and regulations effective 1 January 2026, official California legislative records for SB 690 and AB 566, the Ninth Circuit’s Javier memorandum, California Attorney General and California Privacy Protection Agency enforcement materials, and the Global Privacy Control technical specification. Product claims from the vendor communication are identified as vendor statements; they are not presented as statutory language or regulatory certification.

• California Penal Code Section 631
• California Penal Code Section 637.2
• California Penal Code Section 638.51
• Javier v. Assurance IQ, LLC, Ninth Circuit memorandum, 31 May 2022
• California Legislature: SB 690 status
• California Legislature: SB 690 current text
• California Legislature: SB 690 version comparison
• California Civil Code Section 1798.135
• CCPA statute and regulations effective 1 January 2026
• California Attorney General: Global Privacy Control
• California Legislature: AB 566 status
• California Legislature: AB 566 chaptered text
• California Attorney General: Healthline CCPA settlement, 1 July 2025
• California Attorney General: Disney CCPA settlement, 11 February 2026
• California Privacy Protection Agency: Ford enforcement action, 5 March 2026
• Global Privacy Control technical specification
• Usercentrics partner communication received by metricfixer, August 2026.

This article is for technical and operational information only and is not legal advice. metricfixer is not a law firm. CIPA, CCPA/CPRA, consent, sale/sharing, and opt-out obligations depend on the business, visitor, data flow, tracker behavior, vendor role, contracts, current case law, and the final text of pending legislation. Cookiebot and Usercentrics are third-party services; product features, partner-program eligibility, subscription pricing, and discount terms may change after publication.