The California Consumer Privacy Act, as amended by the California Privacy Rights Act (CPRA), is the closest thing the United States has to the GDPR. It reads very differently, though, and teams that have already done GDPR work often get California wrong in the same two ways: they assume they need consent (they usually do not), and they miss the one obligation that regulators have actually enforced (the opt-out signal). This guide is a practical map for a product-analytics stack. It is not legal advice: confirm your own position with counsel.
Does the CCPA apply to you at all?
Unlike the GDPR, the CCPA has a size floor. It covers for-profit businesses that do business in California, collect California residents’ personal information, and meet any one of three thresholds:
- Revenue: annual gross revenue above $26,625,000, the statutory $25M adjusted for inflation by the California Privacy Protection Agency. This is generally read as total global revenue, not your California revenue.
- Volume: buying, selling, or sharing the personal information of 100,000 or more California consumers or households in a year.
- Business model: deriving 50% or more of annual revenue from selling or sharing personal information.
You do not have to be in California, or in the United States. A European SaaS with enough Californian users is in scope. Most early-stage startups are not, which is exactly why the volume threshold is worth watching: it counts consumers, not customers, and a free product with heavy traffic can cross 100,000 long before it crosses the revenue line.
Opt-out, not opt-in
This is the structural difference from every consent-first law. Under the GDPR and India’s DPDP Act, you need a lawful basis before you collect. Under the CCPA you may collect, provided you disclose what you collect and why at or before the point of collection, and you must stop selling or sharing it when a consumer says so. Affirmative consent is required only in narrow cases, most notably for consumers under 16, where the default flips to opt-in.
The practical consequence: your compliance surface is not a cookie banner. It is an accurate notice, a working opt-out, and honest answers to access and deletion requests.
A cookie banner is not a CCPA control. California cares whether the opt-out works, not whether you asked politely before setting a cookie.
The word that decides everything: “sale” and “sharing”
“Sale” under the CCPA is much broader than money changing hands: it is disclosing personal information to a third party for monetary or other valuable consideration. The CPRA then added “sharing” to cover disclosure for cross-context behavioural advertising, whether or not anything is paid. Between them, that catches a great deal of ordinary analytics and ad-tech plumbing.
What keeps a vendor relationship out of that category is the contract. A service provider is bound by written terms restricting it to processing the data on your behalf and for your purposes only; disclosure to one is not a sale. A third party that may use the data for its own purposes, including building advertising profiles, is not a service provider, and passing data to one is a sale or a share your visitors can opt out of. The same tag on the same page can fall on either side of that line depending only on the paperwork behind it.
Both California enforcement actions to date turned on precisely this. In 2022 the Attorney General settled with Sephora for $1.2 million, alleging it had not disclosed that its use of analytics and advertising software constituted a sale, and had not processed opt-outs sent by browser signal. In July 2025 the Healthline settlement, at $1.55 million the largest to date, added a further lesson: the AG found it had failed to honour opt-outs, had let article titles that implied a medical diagnosis flow to advertising vendors, and had assumed rather than verified that its vendor contracts carried the required CCPA terms.
Honour the signal, not just the toggle
California requires businesses to treat the Global Privacy Control as a valid opt-out request. GPC is a browser-level setting that sends an opt-out signal to every site the person visits, so they do not have to find a link on each one. It is the single obligation that both public settlements had in common, and it is easy to miss, because a site can look perfectly compliant while the signal is silently ignored.
If your analytics never discloses anything to a third party, there is nothing for GPC to switch off, which is the cleanest position to be in. If it does, the signal has to reach the code that decides whether the third-party tag loads at all, not merely a preference row saved after the fact.
One more detail from Healthline worth internalising: a banner that claims to disable tracking and does not is treated as a deceptive practice in its own right, separate from the underlying sharing.
The rights you have to be able to serve
The CCPA, as amended, gives California consumers the rights to know what you have collected, delete it, correct it, opt out of sale and sharing, limit the use of sensitive personal information, and not be discriminated against for exercising any of them. For an analytics stack, deletion is the one with real engineering weight.
Serving it means being able to find every event tied to a person and remove it, which is a server-side operation
against the store you hold, not something a client-side reset() can do. In Pug that is a single call:
POST /shared.profiles.v1.ProfilesService/DeleteDataSubject
{ "externalId": "user-123" }
It erases by the external ID you assigned, or by profile ID via Delete, and returns a request ID you
can poll to confirm the erasure finished, which is what turns “we deleted it” into something you can evidence.
Events, sessions, aliases, and the profile are hard-deleted. Day-level aggregate counts are deliberately left in
place; they carry no per-person key, though the honest description of that is pseudonymisation rather than
anonymisation, and it is worth knowing which of the two you are claiming when you answer a consumer.
Personal information is broader than you think
California’s definition explicitly includes identifiers such as IP addresses and unique device IDs, plus “internet or other electronic network activity information” like browsing and search history and how someone interacts with a page. That is a description of an ordinary event stream. Assuming your analytics is out of scope because you never store a name is the most common mistake here.
Sensitive personal information gets its own tier, with a right to limit its use: precise geolocation, racial or ethnic origin, religion, health, sex life or sexual orientation, and the contents of messages. Healthline is the cautionary tale, because none of the data at issue was a health record, only article titles from which a diagnosis could be inferred. Auditing your event and property names for that kind of leakage is cheap; our free PII event auditor is a fast first pass in the browser, though it is a helper, not a sign-off.
What changed for 2026
Regulations adopted by the California Privacy Protection Agency began taking effect on 1 January 2026 and add three workstreams beyond the original law: rules for automated decision-making technology used in significant decisions, mandatory risk assessments for higher-risk processing (selling or sharing personal information and processing sensitive data are both named), and phased independent cybersecurity audits whose deadlines run by revenue band into the late 2020s.
The through-line for analytics is that selling and sharing now carry documentation overhead as well as opt-out plumbing. Not doing it remains dramatically cheaper than doing it compliantly.
Worth noting too: the 30-day window businesses once had to cure a violation before enforcement was removed at the start of 2023. Whether you get a chance to fix something before a penalty is now discretionary.
A practical CCPA checklist for analytics
- Check the thresholds honestly: count consumers and households, not paying customers.
- Disclose at collection: say what categories you collect and why, before or as you collect them.
- Classify every vendor: service provider under a compliant contract, or third party. Verify the terms; do not assume them.
- Honour Global Privacy Control: wire it to the code that decides whether third-party tags load.
- Make the banner tell the truth: if it says tracking is off, tracking must be off.
- Be able to delete: erase a person’s events from the store on request, and keep evidence that it completed.
- Watch for inferred sensitive data: page titles, URLs, and event names can imply a condition no field ever recorded.
- Minimise: data you never collected needs no notice, no opt-out, and no risk assessment.
Where self-hosting fits
Most of the CCPA’s sharpest edges are about third parties: who received the data, under what contract, and whether a consumer can stop it. Self-hosting removes that entire axis. Events go from your application to your own ClickHouse on your own servers, so there is no recipient to characterise, no contract to audit, and no downstream flow for an opt-out to interrupt. The risk-assessment obligation attached to selling and sharing does not attach to processing you do for yourself.
What self-hosting does not do is discharge your duties to the consumer. You still owe notice, access, correction, and deletion, because you are the one holding the data, and you now hold all of it. Pug is AGPL-3.0 and self-hostable for that trade: you can read exactly what the pipeline does, keep events on infrastructure you control, and erase a data subject through one API call. That is a strong starting position for California, for the GDPR, and for privacy-first analytics generally, but it is a foundation rather than a certificate.