⏰ TL;DR — What You Need to Know
- 1. August 1, 2026 — data brokers must begin processing deletion requests from California's DROP platform. Less than 5 months away.
- 2. $200 per request, per day penalty for failure to process. No cure period. Enforcement can begin immediately.
- 3. 242,000+ Californians have already submitted deletion requests through DROP since it launched on January 1, 2026.
- 4. If your analytics platform stores user IDs, device IDs, or IP addresses, you need a deletion workflow — or you need to stop collecting personal data.
⏰ The Clock Is Ticking: August 1, 2026
On August 1, 2026, data brokers registered in California must begin retrieving and processing deletion requests from the state's Delete Request and Opt-Out Platform (DROP). The penalty for failure: $200 per request, per day. No cure period. No grace period. Enforcement begins immediately.
That deadline is less than 5 months away. And the numbers already paint a picture of what's coming.
DROP went live on January 1, 2026. Within the first 48 hours, 18,000 Californians submitted data deletion requests. By the CalPrivacy Board meeting on February 27, 2026, that number had crossed 242,000 — far exceeding the agency's own expectations. And the platform is still ramping up.
If your mobile app has California users and your analytics platform stores user IDs, device IDs, or IP addresses, this affects you. Not hypothetically. Not someday. Right now — because those 242,000 deletion requests already exist, and someone will have to process them starting August 1.
The penalty math is staggering.
CalPrivacy staff presented this scenario at an IAPP conference in October 2025: if 100,000 consumers file deletion requests and a data broker doesn't act for a full year, the failure-to-delete fines alone could exceed $7.3 billion. CalPrivacy's Tom Kemp has publicly stated that if one to two million Californians are in a data broker's database and they haven't processed the deletions, the $200 fines will quickly add up and far outweigh any prior fines.
This isn't theoretical enforcement. CalPrivacy launched a dedicated Data Broker Enforcement Strike Force in November 2025, hired its first Chief Privacy Auditor, and has already taken multiple enforcement actions — including fines against companies like Tractor Supply ($1.35 million), Todd Snyder ($345,178), and Rickenbacher Data LLC (Datamasters), which was fined $45,000 for buying and reselling names, addresses, and phone numbers of millions of people with Alzheimer's disease, drug addiction, and other health conditions — without even registering as a data broker.
🔍 What Is the DELETE Act and DROP?
The California Delete Act (Senate Bill 362) was signed into law in October 2023. It created DROP — a first-of-its-kind, state-hosted platform where California residents can submit a single deletion request that applies to all registered data brokers simultaneously.
Before DROP, if you wanted your data deleted, you had to contact each company individually. Now, one click reaches all of them.
Here's what registered data brokers are required to do starting August 1, 2026:
- → Access DROP at least every 45 days to retrieve new deletion requests
- → Delete ALL matched personal data — including inferences and derived data — within 90 days of retrieval
- → Treat unresolved requests as opt-out requests at minimum — if you can't confirm deletion, you must stop selling the data
- → Maintain suppression lists to prevent re-collecting data on consumers who have requested deletion
- → Pass deletion requests downstream to contractors and service providers who also hold the data
- → Report compliance status back through the DROP system
That's not a one-time cleanup. That's an ongoing operational obligation — every 45 days, indefinitely.
Data broker registration has surged. In June 2025, 459 entities were registered. By February 2026, that number had grown to more than 575. Annual registration costs $6,000 per entity, and failure to register itself carries penalties — S&P Global was fined $62,600 for an administrative error that left it unregistered for 313 days.
⚠️ Who Qualifies as a "Data Broker"? (The Uncomfortable Question)
Under the DELETE Act, a data broker is defined as "a business that knowingly collects and sells the personal information of a consumer with whom the business does not have a direct relationship."
A "direct relationship" requires the consumer to have intentionally interacted with the business. CalPrivacy has explicitly warned that businesses should not assume they are exempt — even consumer-facing companies may qualify if they sell or share personal information collected outside a direct relationship.
If you're a mobile app developer, you might be thinking: "I'm not a data broker. I don't sell data." And you're probably right — your app itself likely isn't a data broker.
But here's the uncomfortable question: what about your analytics vendor?
Consider this chain of events:
- Your app collects analytics data using a third-party SDK
- That SDK sends user data (device IDs, advertising identifiers, usage patterns) to the vendor's servers
- Your vendor uses that data to build cross-app profiles, sell audience segments, or share data with advertising partners
- Your app's users never directly interacted with the analytics vendor
In that scenario, the analytics vendor may well meet the definition of a data broker. And if they're processing DROP deletion requests, your data is part of what needs to be deleted.
Even if you personally aren't a data broker, the complexity cascades to you. When your analytics vendor receives a DROP deletion request, they need to delete data associated with matched identifiers — including data you sent them. If the identifiers match more than one consumer, all associated consumers must be opted out. Deletion must include inferences and derived data.
The bottom line: the more personal data your analytics pipeline collects, the deeper you're embedded in the deletion chain — even if the legal obligation technically falls on someone else.
💰 The Real-World Cost of Storing Personal Data in Analytics
Even outside of data broker classification, if your organization needs to handle data deletion requests — whether under the DELETE Act, CCPA/CPRA, or the growing patchwork of state privacy laws — storing personal data in analytics creates a concrete operational burden.
Let's look at what deletion actually looks like with the two most popular mobile analytics platforms.
Mixpanel: A Multi-Week Deletion Workflow
To delete a user's data from Mixpanel:
- Generate a GDPR OAuth token from your Personal Settings
- Submit deletion requests per
distinct_idvia the API or dashboard - Batch limit: 500 users through the UI, 2,000 via API
- Wait up to 30 days for processing to complete
- Separately opt users out of future tracking using SDK methods — server-side events are NOT affected by client-side opt-out
- Verify that the deletion was successful — because as Mixpanel's own docs state: "Deleting data from Mixpanel will remove it permanently, but it will not prevent the data from being collected moving forward"
That's per-user, manual, rate-limited, and can take weeks. Now imagine processing 10,000 California users requesting deletion simultaneously.
Firebase Analytics: The Local-Only Trap
Firebase Analytics presents a different problem — one that catches many developers off guard.
Firebase's resetAnalyticsData() method only removes data local to the device. It does not clear data from Google's servers. It changes the device's app instance ID so future data uses a different identifier, but historical data remains on Google's infrastructure.
There is documented confusion among developers about whether Firebase data can actually be fully deleted server-side. Firebase uses device identifiers (IDFV, app instance ID) which constitute personal data under many privacy frameworks.
The Operational Burden Adds Up
Across both platforms — and analytics tools generally — the pattern is the same:
- ✗ User data spreads across multiple systems — analytics, CRM, email platforms, data warehouses
- ✗ Custom properties in analytics events can accidentally contain PII — emails, names, phone numbers tucked into event properties
- ✗ You must build and maintain deletion workflows, audit trails, and suppression lists
- ✗ Each request requires identifying all data associated with a specific user across every system
- ✗ Many companies need third-party tools (like Transcend or DataGrail) just to manage deletion requests across their analytics stack
Now put a dollar figure on it. The DELETE Act's $200/day/request penalty structure means delays are catastrophic:
Penalty Scenarios for Mobile Apps
| California Users Requesting Deletion | Days Late | Potential Penalty |
|---|---|---|
| 1,000 | 30 | $6,000,000 |
| 10,000 | 30 | $60,000,000 |
| 50,000 | 30 | $300,000,000 |
| 100,000 | 365 | $7,300,000,000 |
The 100,000 × 365-day scenario was presented by CalPrivacy staff at an IAPP conference in October 2025 as an illustration of enforcement severity.
Compare those numbers to the cost of not collecting personal data in the first place.
🛡️ The Data Minimization Alternative: What If There's Nothing to Delete?
There's a fundamentally different approach to this problem. Instead of building deletion infrastructure to handle requests after the fact, you can design your analytics architecture so there's nothing to delete in the first place.
This is the principle of data minimization — and it's the only approach that scales across jurisdictions without per-regulation engineering work.
We built Respectlytics around this principle. Here's how the architecture works:
The Strict 5-Field Constraint
Every event stored by Respectlytics contains exactly 5 data fields:
- event_name — what happened (e.g., "upgrade_button_clicked")
- session_id — a hashed, rotating identifier stored only in RAM
- timestamp — when it happened
- platform — iOS or Android
- country — derived from IP lookup, IP immediately discarded
That's it. The API rejects any request containing additional fields with a 400 Bad Request error. Custom properties are architecturally blocked — not disabled by a setting, not discouraged in documentation, but rejected at the API level.
No Personal Data Stored
-
✓
No user IDs — there is no
identify()method in the SDK - ✓ No device IDs — no IDFA, IDFV, GAID, or app instance IDs
- ✓ No IP addresses stored — processed transiently for country lookup only, immediately discarded
- ✓ No device fingerprints, no cookies, no localStorage
- ✓ Zero device storage — SDKs write zero bytes to the user's device for analytics purposes
Session Rotation by Design
Session IDs rotate every 2 hours and reset on every app restart. They are stored in RAM only — never written to disk independently—meaning they're gone the moment the app closes. Before storage, each session ID is hashed with SHA-256 and a daily rotating salt. The original ID is never stored and cannot be reverse-engineered. Cross-session tracking is technically impossible.
The Compliance Implication
When a deletion request arrives — from DROP, from CCPA/CPRA, from any jurisdiction — the response is straightforward:
"We have no personal data associated with any identifiable individual."
No user profiles to purge. No persistent identifiers to look up. No cross-session data to hunt down. No suppression lists to maintain. The deletion request is trivially resolved because there was never personal data to begin with.
This isn't a workaround or a legal technicality. It's an architectural decision that makes data deletion a non-event by design.
Open Source and Auditable
Every claim above is verifiable. The SDKs are MIT-licensed. The server is AGPL-3.0 (Community Edition). Every line of code can be audited. If you need to demonstrate to a regulator or auditor exactly what data your analytics pipeline touches, you can point them at the source code — not a vendor's trust page.
App Store Privacy Labels Simplified
With only 5 fields to declare, Apple App Store Privacy Labels and Google Play Data Safety forms can be completed in minutes. No ATT prompt required. Both declared data types are "Not Linked to User Identity" and "Not Used for Tracking."
🌎 Beyond California: The 2026 Privacy Wave
The DELETE Act isn't an isolated event. It's part of an accelerating regulatory wave that makes data minimization the pragmatic default for mobile analytics.
Twenty US states now have comprehensive consumer privacy laws. Three new state laws took effect on January 1, 2026 alone: Kentucky, Indiana, and Rhode Island.
Key 2026 Deadlines for Mobile Developers
- Jan 1 California CCPA/CPRA expansions — new regulations for automated decision-making, risk assessments, and annual cybersecurity audit requirements
- Jan 1 Oregon — prohibits sale of data for consumers known to be under 16, and prohibits precise geolocation within a 1,750-foot radius
- May 7 Utah App Store Accountability — age verification requirements for app developers and stores
- Jul 1 Connecticut — broadening scope adds neural data, genetic/biometric-derived data, financial information. New transparency obligations specifically for mobile apps, connected devices, and AR/VR
- Jul 1 Louisiana App Store Accountability — additional age verification and app developer obligations
- Aug 1 California DROP processing begins — data deletion requirements with $200/day/request penalties
Internationally, the pattern is the same. Total GDPR fines now exceed €5.88 billion since 2018. In 2025, Ireland's DPC levied a €530 million penalty against TikTok for improperly transferring European users' data to China.
Each of these regulations has different requirements, different definitions, and different penalties. Building compliance infrastructure per regulation is a losing strategy. Data minimization is the architectural approach that addresses all of them at once: if you don't collect personal data, the specifics of each regulation's deletion and consent requirements become far simpler to navigate.
🔧 What You Should Do Right Now
The August 1 deadline is less than 5 months away. Whether you're directly affected by the DELETE Act's data broker provisions or not, the broader trend toward enforceable deletion rights is unmistakable. Here's what to do:
1. Audit Your Current Analytics Stack
Open your analytics platform's documentation and answer these questions:
- □ Does your analytics SDK collect device identifiers (IDFA, IDFV, GAID, app instance ID)?
- □ Does your analytics vendor store IP addresses?
- □ Can developers on your team attach custom properties to events? Have any of those properties ever contained PII?
- □ Does your vendor's privacy policy allow them to share or sell aggregated data derived from your users' behavior?
- □ Do you have a documented, tested process for deleting a specific user's data from your analytics system?
- □ How long does that deletion actually take? Can it complete within the 90-day window?
2. Evaluate Your Data Broker Exposure
Review your analytics vendor's terms of service and data processing agreements. Specifically look for:
- ⚡ Clauses allowing the vendor to use your data for "product improvement," "benchmarking," or "aggregate insights" — these could constitute data brokering
- ⚡ Whether your vendor is registered as a data broker in California
- ⚡ How your vendor handles deletion requests that involve data you sent them
3. Calculate the Cost of Deletion Infrastructure
If your current analytics platform stores personal data, you need a deletion workflow. Estimate the engineering cost of:
- → Building API integrations to programmatically delete users from your analytics platform
- → Creating audit trails to prove deletion was completed
- → Maintaining suppression lists to prevent re-collection
- → Ongoing maintenance as your analytics vendor changes their API
Then compare that to a data minimization approach — where the deletion workflow is: nothing. Because there's nothing to delete.
4. Consider the Migration Path
If you're running Firebase Analytics, we've written a detailed migration guide from Firebase to privacy-first analytics. The SDK integration is typically a single afternoon of work — because there's far less to configure when you're only sending 5 fields.
You can try the live demo to see what analysis looks like with session-based data. The SDK documentation covers Swift, Kotlin, Flutter, and React Native.
5. Talk to Your Legal Team
Share the DELETE Act timeline with your legal or compliance team. The questions you need answered are jurisdiction-specific and depend on your app's user base, your analytics vendor's data practices, and where your data is processed and stored.
⚖️ CalPrivacy Is Already Enforcing — Actively
If you're wondering whether CalPrivacy will actually enforce these penalties, look at what they've done in the past year alone:
| Company | Violation | Fine |
|---|---|---|
| Tractor Supply Company | CCPA violations | $1,350,000 |
| Todd Snyder, Inc. | CCPA violations | $345,178 |
| S&P Global, Inc. | Unregistered data broker (313 days) | $62,600 |
| ROR Partners LLC | Profiled 262M+ Americans without registering | $56,600 |
| Accurate Append, Inc. | Failed to register as data broker | $55,400 |
| National Public Data | Missing registration and fee obligations | $46,000 |
| Rickenbacher Data (Datamasters) | Sold health data without registering | $45,000 |
| Background Alert | Data broker violations | Shut down or steep fine |
These enforcement actions occurred before the August 2026 DROP processing deadline. The dedicated Data Broker Enforcement Strike Force was launched in November 2025.
And starting January 1, 2028, data brokers will be subject to independent privacy audits every three years, with the first audit results due to CalPrivacy by January 1, 2029.
This is not an agency that issues warnings and moves on. CalPrivacy has the budget, the staff, and the political mandate to enforce aggressively.
❓ Frequently Asked Questions
What is the California DELETE Act and when does it take effect?
The California Delete Act (Senate Bill 362) created the Delete Request and Opt-Out Platform (DROP), where California residents submit a single deletion request to all registered data brokers simultaneously. DROP launched January 1, 2026. Starting August 1, 2026, data brokers must begin retrieving and processing these deletion requests, with penalties of $200/request/day for non-compliance.
Does the DELETE Act apply to mobile app developers?
The DELETE Act directly regulates data brokers — businesses that collect and sell personal information of consumers with whom they don't have a direct relationship. If your analytics vendor shares or sells data collected from your app's users, the downstream implications could affect your app's compliance posture. CalPrivacy has warned that businesses should not assume they are exempt. Consult your legal team for a definitive assessment.
What are the penalties for not complying with DROP deletion requests?
$200 per request, per day. No cure period. CalPrivacy staff have illustrated that if 100,000 consumers file requests and a data broker doesn't act for a full year, fines could exceed $7.3 billion. They have also noted that for data brokers with one to two million Californians in their database, the $200 fines will quickly add up and far outweigh any prior penalty amounts.
How does data minimization help with data deletion requirements?
Data minimization eliminates the deletion problem at the source. If your analytics platform stores no personal data — no user IDs, device IDs, or IP addresses — there is nothing to delete. The compliance response becomes: "We have no personal data associated with any identifiable individual." No deletion workflow, no audit trails, no suppression lists needed.
Can Firebase Analytics or Mixpanel handle bulk deletion requests?
Both support deletion, but with significant limitations. Mixpanel caps batch requests at 2,000 users via API and processing can take up to 30 days. Firebase's resetAnalyticsData() only clears local device data — not server-side data. Neither platform eliminates the need to build and maintain deletion infrastructure, identify all data per user across systems, and verify completions.
How many states have privacy laws in 2026?
Twenty US states now have comprehensive consumer privacy laws. Three new laws took effect January 1, 2026 (Kentucky, Indiana, Rhode Island). Connecticut is broadening its law on July 1, 2026, with mobile app-specific transparency obligations. The trend toward enforceable data minimization and deletion rights is accelerating.
Legal Disclaimer
This article is provided for educational purposes and does not constitute legal advice. The DELETE Act, CalPrivacy enforcement actions, and penalty structures are described based on publicly available information as of March 2026. Privacy requirements vary by jurisdiction and change over time. Consult your legal team to determine the requirements that apply to your specific situation.
Additional Resources
- Data Deletion Guide — How Respectlytics handles deletion requests architecturally
- Migrate from Firebase to Privacy-First Analytics — Step-by-step migration guide
- Why We Killed Custom Event Properties — How architectural constraints prevent PII leaks
- Privacy Regulations and Mobile Apps — Broader context on international privacy requirements
- App Store Privacy Labels Guide — Simplified privacy declarations with data minimization
- SDK Documentation — Swift, Kotlin, Flutter, React Native implementation guides