The California Attorney General's January 27, 2023 investigation into mobile apps in the retail, travel, and food sectors raises a pressing question: where should consumer opt-out mechanisms be integrated within your app?
Some teams embed opt-out controls directly in the app interface, while others use web-based privacy centers accessible through external links. The AG's focus on "failing to offer a consumer opt-out mechanism for sales" indicates that this choice carries real enforcement risk.
The Case for Web-Based Privacy Centers
Many development teams manage CCPA rights through a centralized web portal instead of building native app controls. This approach simplifies maintenance, as you only need one privacy interface across iOS, Android, and web platforms.
There are clear technical benefits. Your privacy center can update instantly without app store approval delays. It ensures consistent consent records across all touchpoints. When regulations change, you modify one codebase instead of three.
Centralization also aids the authorized agent workflow. CCPA allows consumers to designate agents to submit rights requests. Verifying these agents involves document review and identity confirmation, often requiring manual intervention. A web-based system lets your privacy team handle these requests efficiently without integrating complex verification flows into mobile SDKs.
From a compliance standpoint, proponents note that CCPA doesn't mandate in-app controls. It requires a "clear and conspicuous link" titled "Do Not Sell or Share My Personal Information" but doesn't specify its location or interface.
The Case for Native App Controls
The counterargument focuses on user experience: if users interact with your brand solely through your app, directing them to a browser for privacy rights can seem obstructive.
Enforcement signals support this view. The AG's investigation targets apps that "allegedly are not in compliance with the CCPA by failing to offer a consumer opt-out mechanism for sales." This suggests that investigators are checking not just for the existence of an opt-out, but its accessibility to app users.
Consider the practical scenario. Your app collects location data, tracks behavior, and shares Mobile Advertising IDs with ad networks. When users want to stop that sharing, directing them to a browser feels evasive.
Native controls also address the authorized agent issue differently. Instead of forcing agents into a web workflow, you can integrate verification into the app. Agents can submit requests through the same interface consumers use, with backend systems handling verification. This approach avoids the confusion of "download our app, then leave it to submit your request."
The technical argument against centralization is valid: modern app development already handles platform-specific implementations for payments and notifications. Privacy controls aren't more complex than Apple Pay integration. If you can build a cross-platform checkout flow, you can build an opt-out mechanism.
Where Practitioners Actually Land
Most marketing technology teams adopt a hybrid model: prominent in-app controls for common actions like opting out of sales, with a link to the full web-based privacy center for complex requests like deletion or correction.
This compromise acknowledges that not every CCPA right fits mobile UI. Deletion requests require confirmation workflows and waiting periods that don't align with app interactions. But opting out of sales is binary and immediate, making it suitable for native implementation.
The authorized agent question remains contentious. Some teams route agent requests to web portals for manual verification. Others build agent verification into app flows, reasoning that if consumers trust your app with their data, it should handle their privacy requests.
Industry-specific factors matter. Travel apps often include account management screens where privacy controls fit naturally. Retail apps with loyalty programs have existing preference centers for opt-out toggles. Food delivery apps may have simpler data flows, making web-based management sufficient.
Our Take
The AG's investigation focuses on retail, travel, and food industries because these sectors built mobile-first consumer relationships and then added privacy controls as an afterthought. If your app is the primary way customers interact with your brand, your privacy controls should be there too.
Build the "Do Not Sell" mechanism directly into your app settings. Don't make users switch to a browser. The technical effort is manageable, and the compliance stance is defensible.
For authorized agent requests, the approach differs. These requests need verification steps that benefit from web-based tools and manual review. An in-app submission form that routes to your privacy team is acceptable, but verification can happen outside the app.
The broader principle: meet users where they are. If someone downloaded your app to book travel or order food, they shouldn't need a browser to stop you from selling their location history. The CCPA's "clear and conspicuous" standard isn't just about visibility; it's about removing barriers to exercising rights.
The enforcement risk isn't theoretical. The AG's office is actively investigating this gap. If your mobile app lacks native opt-out controls, you're betting that investigators will accept "but there's a link to our website" as sufficient. That's not a bet we'd recommend.
