The CCPA Deletion Problem: Why Wiping Rows Isn't Enough for Personalization Engines

TL;DR.

• CCPA's right-to-delete applies to every derivative of a user's data — embeddings, feature vectors, cached scores, and model weights trained on that signal.
• Deleting a row from your events table does not delete the user from your recommendation model; machine unlearning is an active research area, not a solved engineering primitive.
• Most personalization teams misclassify vendor relationships — sending user signals to a third-party analytics or A/B testing vendor likely qualifies as "sharing" under CPRA.
• CPRA's sensitive personal information (SPI) category, enforced since mid-2023, creates a separate opt-out right that most consent UIs still haven't implemented correctly.
• If you only remember one thing: build your deletion pipeline as a DAG that fans out from raw events all the way to derived artifacts before you collect a single byte of behavioral signal.

Most personalization teams treat privacy compliance as a legal checkbox — add a consent banner, wire up a delete endpoint, call it done. That framing is the bug. CCPA and its 2023 successor CPRA define "deletion" as removal from all systems, including derived data, which in a modern personalization stack means your feature store, your offline embedding index, your cached recommendation lists, and — most painfully — any model whose weights were shaped by that user's behavior. The gap between what engineers implement and what the law requires is wide, and CPPA enforcement actions in 2025 and 2026 have started closing it.

This post is for engineers and ML practitioners building recommendation or personalization systems who want to understand what compliance actually demands technically, not just contractually.

What CCPA and CPRA Actually Require From a Personalization Stack

The four rights that matter for personalization engineers are: right to know, right to delete, right to correct, and right to opt-out of sale or sharing (CCPA, Cal. Civ. Code § 1798.100–1798.199). CPRA (Proposition 24, effective Jan 1 2023) added a fifth: the right to limit use and disclosure of sensitive personal information.

"Delete" under CCPA is not limited to your primary database. The statute says businesses must delete from their records and direct service providers to delete from theirs — the Attorney General's guidance has been consistent that this includes backups and analytics systems, not just production tables. "All records" means derived records too. An embedding that encodes a deleted user's behavior is a derived record. A collaborative filter that adjusted its weights based on that user's click history is a derived artifact.

CPRA added data minimization and purpose limitation as affirmative requirements, not just opt-in rights. You are only permitted to collect personal information reasonably necessary for the disclosed purpose. That is a direct constraint on the ambient signal collection that powers most cold-start personalization.

The sensitive personal information carve-out

SPI under CPRA is a materially stricter category: precise geolocation, health data, racial or ethnic origin, contents of messages, biometrics, and — relevant for some apps — inferences drawn to create profiles about behavior relating to health or finances (CPPA Regulations, 11 Cal. Code Regs. § 7001). Users have a right to direct a business to limit its use of SPI to "what is necessary to perform the services." Most personalization systems that use location as a signal, or that infer health-adjacent preferences from content consumption, are processing SPI and need a separate consent layer for it.

Why Right-to-Delete Is Harder Than Your Infra Team Thinks

The naive implementation: delete the user row from your users table, drop their event rows from your events table, invalidate their session cache, done. This satisfies the letter of the delete request for transactional data. It does not satisfy it for the derived artifacts that power personalization.

Consider what a typical ML-backed personalization stack actually writes from a single user's behavioral signal:

Raw events. Clickstream, dwell time, explicit ratings. These are the easy part.

Derived features. Your feature pipeline reads raw events and writes computed features — rolling 7-day genre affinity, recency-weighted content embeddings, inferred demographic buckets — to a feature store. These are separate rows, often in a different system, with their own TTL. Most teams forget them.

Pre-computed embeddings. Offline jobs compute a user embedding nightly and write it to a vector index (Pinecone, Weaviate, pgvector). The embedding is derived from the raw events but lives in a completely different store. Deleting the events doesn't touch the index.

Cached recommendation lists. Your serving layer pre-computes top-N lists and writes them to Redis or Memcached. If a user requests deletion, their pre-computed lists may continue serving until TTL expiry — potentially days later.

Model weights. The hardest problem. If you trained a matrix factorization, two-tower neural model, or gradient-boosted ranker on your user's behavioral history, their preferences are now encoded across every weight in that model. Deleting their training data and retraining isn't free.

A compliant deletion pipeline is a DAG, not a single delete query. It has to reach every artifact in every system that received user signal, in the right order.

The Machine Unlearning Problem

If your personalization model was trained on a deleted user's data, are you required to retrain it? This is the question that keeps ML platform engineers awake.

The honest answer: yes, under a strict reading of CCPA deletion requirements. The practical answer: approximate unlearning methods are emerging as a defensible middle ground, provided you can demonstrate the removed user's influence is negligible in the resulting model.

The field of machine unlearning — making a trained model forget specific training examples — has matured significantly since Cao and Yang's foundational formulation. The most practical production approach is SISA training (Sharded, Isolated, Sliced, and Aggregated), proposed by Bourtoule et al. (arXiv:1912.03817). The idea: partition your training data into shards, train isolated sub-models on each shard, and aggregate at inference. When a deletion request arrives, you only retrain the shard that contained that user's data — typically a fraction of the full training cost.

For ranking models specifically, influence functions (Koh & Liang, 2017, arXiv:1703.04730) provide an approximation: estimate the effect a training point had on model parameters and apply a counter-update. This is O(1) in training time but requires storing or recomputing second-order derivative information. In 2026, most large-scale personalization teams doing approximate unlearning use some variant of influence function approximation or SISA; a full survey of the landscape is available in (arXiv:2209.02299).

Neither approach is a clean legal answer. They're engineering defenses. The defensible position for an enforcement conversation is: (1) you have documented that approximate unlearning bounds the deleted user's residual influence below a measurable threshold, and (2) you have a hard-retrain schedule for models that accumulate enough deletion requests to exceed that threshold.

What this means in practice

For recommendation models retrained on a daily or weekly cycle, the simplest compliant strategy is often: mark the user deleted, exclude them from the next training run, and accept that the current deployed model contains some of their influence for one cycle. Document this explicitly in your privacy policy as "up to [X] days." This mirrors how CCPA's 45-day deletion response window gives you operational room. The window isn't a free pass to never delete — it's time to propagate the deletion correctly.

The Knowledge Graph Cascade Problem

Knowledge graph-backed personalization has a specific deletion challenge that flat-schema systems don't: your graph has edges.

A user node connects to item nodes via interaction edges, to inferred preference nodes via derived edges, and potentially to community or cohort nodes via aggregation edges. A CCPA deletion requires removing the user node and all edges attached to it. That part is straightforward. The harder question: what do you do with nodes that were created because of this user?

If your system inferred a genre preference node ("ambient electronic") from a user's listening behavior, and that node now connects to many other users' graphs, removing the deleted user's edges doesn't remove the node. That's correct — the node represents a concept, not a person. But if you created an inferred preference node specifically for this user — for instance, a hyper-specific taste cluster derived from their unique combination of signals — and that node now only connects to this user, it should be deleted as well.

The implementation pattern: tag every graph node and edge at creation time with provenance — which user signals contributed to its creation, and whether it's a shared concept node or a user-specific derived node. Deletion traverses:

1. All direct interaction edges from the user node.
2. All user-specific derived nodes (nodes whose provenance is exclusively this user).
3. The user node itself.
4. Optionally: re-compute aggregate nodes whose statistics were influenced by this user, if the user contributed significantly enough that their removal would change the node's value beyond a defined threshold.

Step 4 is where most graph deletion implementations stop being practical. The usual engineering judgment: rebuild aggregate statistics periodically anyway (nightly batch jobs), so a single user deletion doesn't require on-demand recomputation. The key is documenting this in your retention schedule and ensuring your periodic rebuild respects deletion flags.

The Sale and Sharing Misclassification

CPRA's definition of "sharing" is the most underappreciated compliance gap in the personalization industry. Sharing — distinct from sale — covers "communicating, disclosing, transferring, making available, or otherwise disclosing a consumer's personal information" for the purpose of cross-context behavioral advertising, even with no money changing hands (Cal. Civ. Code § 1798.140(ah)).

Most personalization stacks send behavioral signals to multiple third-party vendors:

• Analytics platforms (Amplitude, Mixpanel) to measure engagement
• A/B testing platforms (Optimizely, Statsig) to bucket users
• Marketing automation (Braze, Iterable) to personalize push
• CDPs (Segment, mParticle) as a transit layer

Whether each of these constitutes "sharing" under CPRA depends on one question: does the vendor use the received data only to provide the contracted service back to you, or do they also use it to build models, profiles, or benchmarks that benefit their other clients?

If the answer is the latter, the vendor is a Third Party under CCPA, not a Service Provider. Data sent to a Third Party requires opt-out rights. Data sent to a Service Provider doesn't — but only if your contract with them explicitly prohibits any use beyond the contracted service, and they actually honor it.

This matters practically: if you're sending user-level events to an analytics vendor that trains cross-customer models on your data (even for benchmarking or anomaly detection), you need a "Do Not Sell or Share My Personal Information" opt-out path before that data leaves your system. The consent banner that says "accept analytics cookies" is not sufficient.

What a Compliant Personalization Architecture Looks Like in 2026

No architecture is perfectly compliant out of the box — compliance is a property of processes, not just systems. But there are structural choices that make compliance dramatically easier.

1. Consent at the write boundary

Before any behavioral signal is written to any store, check consent state. Not as an async job that catches up later — at the write boundary. Your event ingestion layer should carry consent context, and any event from a user who has opted out of data collection or sharing should be dropped (or written to an anonymized aggregate-only store).

This is harder than it sounds in streaming architectures. Most Kafka or Kinesis pipelines don't carry per-user consent state inline. The pattern: a low-latency consent cache (Redis hash keyed on user ID) that your event enrichment step reads from before the event lands in your warehouse.

2. User state machine with deletion propagation

Model user consent and deletion state explicitly:

• active: full data collection and personalization
• sharing_opt_out: local personalization allowed, no third-party sharing
• spi_limited: SPI processing restricted to contracted service only
• deletion_requested: deletion pipeline triggered, serving from cold fallback
• deleted: no data in system, hard fallback to non-personalized defaults

Transitions between states trigger async jobs that propagate the change through every derived artifact store.

3. Deletion pipeline as a first-class DAG

Build the deletion DAG before you need it. Nodes:

1. Mark user deleted in primary DB (blocks new feature computation)
2. Delete raw events (warehouse, data lake)
3. Delete feature store entries (Feast/Tecton offline + online stores)
4. Delete embedding vectors (vector index)
5. Invalidate cached recommendation lists (Redis/CDN edge)
6. Propagate deletion to all service providers via their APIs
7. Log completion of each step with timestamp for audit trail
8. Schedule next model retrain run to exclude user

Steps 1–6 should complete within your stated deletion window (typically 45 days, best practice is 10). Step 7 is your audit defense.

4. Separate SPI data stores with stricter controls

Don't mix SPI signals (precise location, health-adjacent inferences, financial behavior) into your general feature store. Maintain a separate, access-controlled store with explicit purpose tags and stricter retention. This makes right-to-limit-SPI requests tractable — you scope the deletion or processing restriction to one store rather than rebuilding your entire data model.

5. Right-to-know and right-to-correct APIs

Right-to-know means you must be able to export, in a portable format, all personal information you hold about a user. For a personalization system this includes raw events, derived features, and the inferences you've drawn. This is usually the hardest part operationally — it requires a reverse-ETL from your feature store back to something human-readable.

Right-to-correct means if the user disputes an inference ("I haven't listened to country music in three years, why does my profile say that?"), you need a path to correct or delete that specific derived attribute. This is a strong argument for storing your inferred preferences in a mutable, user-readable graph structure rather than in opaque embedding space — embeddings are nearly impossible to correct in response to a user dispute.

Where to Start

Audit your data flow end-to-end. Map every system that receives user behavioral signal — not just your primary DB, but your feature store, your vector index, your A/B testing vendor, your analytics platform. Most teams haven't done this since their stack grew. The output is a data flow diagram with every system labeled as Service Provider or Third Party.

Classify your vendor contracts. Pull every data processing agreement and check whether it explicitly prohibits the vendor from using your users' data for their own model training or cross-client analytics. If it doesn't, that vendor is a Third Party, and you need opt-out infrastructure before sending user-level signals to them.

Build the deletion DAG before you're under a 45-day clock. Deletion requests from attorneys general or individual users don't come with runway. A team that has to build deletion infrastructure in response to a request is already late. The DAG also forces you to enumerate every derived artifact store, which is itself a useful privacy audit.

Implement SPI consent separately from general consent. If you're using location, health, or financial signals in your personalization model, add an explicit SPI opt-out path — not just a checkbox in your general privacy settings, but a separate control that limits processing to contracted-service-only. The CPPA has been specific about this in enforcement guidance.

Adopt approximate unlearning for batch-trained models, document the method. You don't need to retrain a 200M-parameter model every time a user submits a deletion request. You do need to be able to demonstrate that the deleted user's influence on the deployed model is bounded and that a full retrain is scheduled within a defined horizon. Write this down in your privacy policy and your model cards.

CCPA compliance for personalization is an engineering problem, not a legal one. The law is clear about what's required; the gap is in the infrastructure to actually do it. Teams that treat deletion as a DAG and consent as a write-boundary check are already mostly there. Teams that added a "delete account" button to a monolithic user table have a full sprint of work ahead.