[Privacy Policy Series 3] Managing Personal Data Across Mobile Apps, Websites, and SaaS Products
Privacy policies for digital products rarely fail because the law is unclear. They usually fail because teams underestimate how differently data is collected across web, mobile apps, and SaaS platforms—and how quickly those differences turn into legal risk when analytics and advertising tools are added on top.
This article looks at how common tracking technologies work in each environment and what that means under modern privacy laws such as the GDPR, the EU ePrivacy rules, and U.S. state privacy laws including the CCPA/CPRA. The focus is on cookies and tracking technologies, targeted advertising and retargeting, cookie banners and opt-out mechanisms, and the use of tools such as Google Analytics, Firebase, and Meta Pixel.
1. Why platform-specific data collection matters
Websites, mobile apps, and SaaS platforms are built on different technical stacks, so they collect personal data in very different ways.
Websites rely heavily on browser-based technologies such as cookies, local storage, and tracking pixels. From the moment a user lands on the site, cookies may start recording browsing behavior, time on page, and click paths—sometimes even when the user is not logged in. Under the GDPR and the EU ePrivacy Directive, most of these cookies require prior consent. Under U.S. state privacy laws, third-party cookies and cross-site tracking can be treated as a “sale” or “sharing” of personal information, triggering specific disclosure and opt-out requirements.
Mobile apps can access far more granular device and usage data: device identifiers, location data, app usage patterns, and in some cases sensors such as camera and microphone. Advertising identifiers such as Apple’s IDFA or Google’s advertising ID allow tracking across different apps. Location data can reveal detailed movement patterns. Apple’s App Tracking Transparency (ATT) framework and Google’s Privacy Sandbox are strengthening user control over such tracking and must be aligned with GDPR and CCPA/CPRA requirements.
SaaS platforms, especially in B2B settings, often process data about employees or end-users on behalf of corporate customers. This makes the controller–processor relationship critical. Under the GDPR, a data processing agreement (DPA) is mandatory. Under U.S. state privacy laws, service provider or processor contracts must meet specific criteria so that the vendor is not treated as “selling” or “sharing” personal information.
2. Cookies and tracking technologies: a legal minefield
Cookies look simple from a technical perspective but are one of the most complex areas legally.
The EU ePrivacy rules (often referred to as the “Cookie Law”) require prior consent for setting most cookies. The key point is “prior”: non-essential cookies must not be set when the page first loads. They should only be activated after the user has clearly consented.
Under the GDPR, valid cookie consent must be:
Freely given – users should not be forced to accept cookies to access basic content or services unless cookies are strictly necessary for the service.
Specific – consent should be granular by category (for example, strictly necessary, analytics, marketing), not a single “all or nothing” checkbox.
Informed – users must understand what each cookie does, what data is collected, and for what purposes.
Unambiguous – passive behavior such as scrolling does not qualify; pre-ticked boxes are not allowed.
From a CCPA/CPRA perspective, cookies are treated differently. Third-party cookies and cross-context behavioral advertising may be considered a “sale” or “sharing” of personal information. When advertising networks or social media pixels send user behavior data to third parties, that transfer can trigger requirements to disclose such practices and to offer an easy opt-out.
Different cookie types are treated differently. Strictly necessary cookies, which are required to provide a service requested by the user (for example login sessions, shopping cart cookies, certain security cookies), generally do not require consent. Functionality, performance/analytics, and targeting/advertising cookies typically do.
3. Targeted advertising and retargeting
Targeted advertising and retargeting sit at the center of modern digital marketing—and of modern privacy enforcement.
Behavioral advertising relies on detailed analysis of browsing history, search activity, and purchase patterns. Under the GDPR, this is often classified as profiling. Profiling requires a clear legal basis. Legitimate interests may be sufficient in some narrow cases, but where profiling is intrusive or derives sensitive insights (such as health, political views, or sexual orientation), explicit consent is usually required.
Retargeting tracks users from one site to another to show follow-up ads. This depends heavily on third-party cookies and pixels, making it one of the most scrutinized areas under the GDPR’s transparency and consent rules. Under CCPA/CPRA, these activities are typically treated as “sharing” personal information for cross-context behavioral advertising, and consumers must be able to opt out.
Social media–based advertising adds another layer. When a website includes Meta Pixel or TikTok Pixel, user actions on the site are transmitted to those platforms. In some circumstances, regulators have treated this as a joint controller relationship under the GDPR, which means both the website operator and the platform share responsibility for the processing. Contractual arrangements and privacy notices need to reflect that reality.
European regulators have already issued decisions finding Google Analytics and Meta Pixel deployments to violate GDPR requirements, mainly due to international data transfers and insufficient consent mechanisms. Any company targeting European users needs to be aware of those precedents.
4. Cookie banners and opt-out mechanisms in practice
Implementing a compliant cookie banner is not just about adding a pop-up. It requires careful design of user flows, technical integration, and legal content.
For a GDPR-compliant banner, key elements include:
Clear, user-friendly language without dense legal or technical jargon.
Separate controls for different cookie categories so users can accept analytics while declining marketing, for example.
Equal prominence of “Accept” and “Reject” (or equivalent) options; making “Accept all” bright and hiding “Reject” in a link is risky.
No pre-ticked boxes.
A link to a detailed cookie policy where users can review specific cookies, purposes, and retention periods.
A consent management platform (CMP) such as OneTrust, Cookiebot, or Termly can help manage consent records, cookie scans, and proof of compliance. Logged consent records often become critical evidence in regulatory investigations or litigation.
Under the CCPA/CPRA, the focus is more on opt-out mechanisms than prior consent. Businesses that “sell” or “share” personal information must provide a clear “Do Not Sell or Share My Personal Information” link (or equivalent functionality) and honor opt-out preferences. The CPRA also requires honoring Global Privacy Control (GPC) signals, which allow browsers or extensions to send a universal opt-out signal. Websites should be able to detect and respond to GPC signals by disabling relevant cookies and tracking.
5. Google Analytics: legal risks and mitigation strategies
Google Analytics is widely used but heavily scrutinized.
Key legal concerns include:
Personal data such as IP addresses and device identifiers being sent to Google servers.
Transfers of that data to servers located in the United States.
Google’s potential use of data for its own advertising ecosystem.
The profiling of users based on their behavior across pages and sessions.
Migrating to Google Analytics 4 (GA4) is often the first step. GA4 has been designed with more privacy features than Universal Analytics and generally does not store full IP addresses. However, that alone does not solve all compliance issues. GA4 still relies on cookies and tracking technologies, so consent requirements and opt-out mechanisms remain necessary for analytics and marketing cookies.
Organizations should:
Conclude a data processing agreement (DPA) with Google, including the relevant data protection terms.
Implement appropriate safeguards for international data transfers, such as standard contractual clauses (SCCs) and transfer impact assessments.
Consider privacy-focused alternatives such as Matomo, Plausible, or Fathom Analytics, which can be self-hosted in specific regions or configured with cookieless tracking, where appropriate.
6. Firebase and mobile app analytics
Firebase has become a core platform for mobile app development, but its analytics, crash reporting, and messaging features may involve extensive data collection.
Firebase can collect device information, usage patterns, in-app behavior, location data, and advertising identifiers. All of these may be personal data under the GDPR and personal information under U.S. state laws.
Apple’s App Tracking Transparency framework requires apps to obtain explicit permission before accessing the IDFA for cross-app tracking. The timing and language of the ATT prompt should be carefully designed so users understand why tracking is requested and what value they receive in return. On Android, the Google Play Data Safety section must accurately disclose what data the app collects, for what purposes, and whether data is shared with third parties. Inaccurate or incomplete disclosures can lead to removal from app stores.
To strengthen privacy when using Firebase, teams should:
Disable automatic collection features that are not strictly necessary.
Offer users an easy way to opt out of analytics wherever feasible.
Configure data retention thoughtfully. For example, Firebase/Google Analytics offers retention settings such as 2 or 14 months, while other identifiers or logs may persist until actively deleted. Retention should not default to “forever”; it should be tailored by purpose.
Use anonymization or pseudonymization wherever possible.
7. Meta Pixel and social media tracking
Meta Pixel is powerful for measuring and optimizing Facebook and Instagram advertising, but it is also one of the most legally sensitive tools.
When Pixel is active, detailed behavioral events—page views, searches, add-to-cart, purchases—are sent to Meta. If the user is logged into Facebook or Instagram, those events may be associated with their profile.
Regulators in several European countries have found implementations of Meta Pixel to violate GDPR requirements, often due to insufficient consent and unlawful international data transfers. To reduce risk:
Fire Meta Pixel only after users have explicitly accepted marketing cookies. Tag managers can be configured to conditionally load the pixel based on consent.
Be cautious with advanced matching, which transmits hashed email addresses or phone numbers to Meta. This clearly qualifies as a transfer of personal data and requires explicit disclosure and, in many cases, consent.
Consider Meta’s Conversion API as an additional or alternative integration method. It avoids some browser limitations but still involves transferring personal data and therefore must be backed by a valid legal basis and adequate transparency.
Where possible, use measurement methods that do not require sharing raw personal data with third parties, such as UTM-based tracking, server logs, or promotion codes.
8. Drafting platform-specific privacy notices
Different channels may need different privacy notices—or at least a combined notice that clearly distinguishes how each platform works.
For websites, the privacy notice should explain:
What cookies and tracking technologies are used.
The purposes and retention periods of each cookie category.
Which third-party tools are involved and how they process data.
Links to third-party privacy policies for tools such as Google Analytics, Meta, and others.
Mobile app privacy notices should cover:
Each device permission requested (location, camera, microphone, contacts, photos, etc.) and why it is needed.
Use of advertising identifiers and how users can limit tracking through device settings.
How push notifications are used and how users can manage their preferences.
SaaS privacy notices should clarify:
Whether the provider acts as a processor, a controller, or both, depending on the data and use case.
How DPAs are put in place with customers.
Whether sub-processors are used, how they are vetted, and how customers are informed about changes.
The security measures in place, including technical safeguards (encryption, access controls, logging, intrusion detection) and organizational safeguards (training, background checks, incident response).
Security certifications such as SOC 2 or ISO 27001 can be highlighted where relevant to increase customer confidence.
9. International data transfers and cloud services
Most modern products rely on global cloud infrastructure such as AWS, Google Cloud, or Microsoft Azure. That inevitably raises questions about international data transfers.
Under the GDPR, transfers of personal data from the EEA to countries without an adequacy decision require appropriate safeguards. The EU–US Data Privacy Framework currently provides an adequacy decision for certified U.S. organizations, but its long-term future is not guaranteed. Many companies still rely on standard contractual clauses and transfer impact assessments as an additional safeguard.
Teams should:
Map where data is stored and processed.
Ensure contracts with cloud providers include SCCs or equivalent safeguards where needed.
Use regional hosting options (for example, EU data centers) when possible, while recognizing that some support operations may still involve cross-border access.
Document risk assessments and any supplementary measures adopted.
10. Practical compliance checklist
For websites:
Confirm that non-essential cookies do not load before consent.
Ensure the cookie banner is clear, balanced, and easily allows both acceptance and rejection.
Keep the cookie policy up to date and aligned with actual technical behavior.
Implement and test “Do Not Sell/Share” and GPC responses where required.
For mobile apps:
Ensure app store disclosures accurately reflect data collection and sharing.
Review ATT prompts and Android Data Safety entries for clarity and accuracy.
Check that key features still work reasonably when tracking is declined.
Review Firebase configuration and retention settings.
For SaaS platforms:
Confirm that DPAs meet GDPR Article 28 requirements and U.S. state “processor/service provider” definitions.
Maintain an up-to-date sub-processor list and a customer notification process.
Provide tools or APIs that help customers honor data subject rights.
Document incident response procedures that support regulatory notification timelines.
Closing
Managing privacy across web, mobile apps, and SaaS products is not about chasing every new tool individually. It is about maintaining a consistent strategy grounded in transparency, user control, and data minimization. Cookies, pixels, and SDKs can absolutely be used in a compliant way, but only if the organization understands how each component works, how it interacts with global privacy laws, and how to keep documentation and technical implementation aligned.
Practical next steps include mapping data flows for each platform, reviewing existing tracking tools and contracts, tightening consent and opt-out mechanisms, and building a regular review cycle into product launches and marketing changes.
If you need help assessing your current setup, designing platform-specific privacy notices, or reviewing tools such as Google Analytics, Firebase, or Meta Pixel from a compliance perspective, LexSoy Legal LLC can assist with tailored privacy and data protection advice. For inquiries, please contact contact@lexsoy.com.
© LexSoy Legal LLC. All rights reserved.