Privacy regulations and platform policies have fundamentally changed how mobile analytics work. GDPR in Europe, CCPA in California, Apple's App Tracking Transparency (ATT), and Google's Privacy Sandbox mean that the old approach of tracking everything about every user is no longer legal, possible, or advisable.
This guide covers how to build deep link analytics that give you the data you need while respecting user privacy and complying with regulations.
The analytics dashboard with date range selector, filters, charts, and breakdowns.
The Privacy Landscape
GDPR (EU/EEA)
The General Data Protection Regulation requires:
- Legal basis for processing: You need a lawful reason to collect and process personal data (consent, legitimate interest, contract performance, etc.)
- Data minimization: Collect only what you need
- Purpose limitation: Use data only for the stated purpose
- Right to erasure: Users can request deletion of their data
- Right to access: Users can request a copy of their data
- Data Protection Impact Assessment: Required for high-risk processing
For deep link analytics, the key question is: does your tracking involve personal data? IP addresses, device IDs, and behavioral data linked to an individual are personal data under GDPR.
CCPA/CPRA (California)
The California Consumer Privacy Act (as amended by CPRA) gives California residents:
- Right to know what data is collected
- Right to delete personal information
- Right to opt out of the sale or sharing of personal information
- Right to non-discrimination for exercising privacy rights
"Sharing" under CPRA includes sending personal information to third parties for cross-context behavioral advertising, which includes many attribution and analytics platforms.
Apple ATT (iOS)
Apple's App Tracking Transparency framework requires apps to request user permission before tracking them across apps and websites owned by other companies.
ATT applies when you:
- Share device-level data (IDFA) with third-party ad networks
- Use third-party SDK fingerprinting for attribution
- Link user data from your app with data from other companies
ATT does not apply to:
- First-party analytics (tracking user behavior within your own app)
- Attribution that uses your own deep links and doesn't share data with third parties
- Aggregated, non-identifiable analytics
Google Privacy Sandbox (Android)
Google is rolling out Privacy Sandbox for Android, which replaces GAID (Google Advertising ID) with privacy-preserving APIs:
- Topics API: Interest-based advertising without individual tracking
- Attribution Reporting API: Measures ad effectiveness with limited cross-app data
- FLEDGE: On-device ad auctions without sharing user data
What You Can and Can't Track
Always Allowed (First-Party Analytics)
You can always track user behavior within your own app using your own systems:
- Click counts on your own deep links
- Conversion rates through your own funnel
- Retention metrics for your own users
- Revenue from your own transactions
- Aggregated demographic data
- Device type, OS version, country (aggregated)
This is first-party data collected for your own legitimate business purposes. It doesn't require ATT consent and is covered by legitimate interest under GDPR (though you should still disclose it in your privacy policy).
Requires Consent
Activities that typically require explicit consent:
- Sharing user-level data with third-party ad networks
- Using IDFA or GAID for cross-app tracking
- Building cross-app user profiles
- Retargeting users on third-party platforms using device IDs
- Sharing personal data with MMPs (Mobile Measurement Partners) that aggregate across apps
Privacy-Friendly Alternatives
For tracking that normally requires consent, privacy-friendly alternatives exist:
| Traditional Approach | Privacy-Friendly Alternative |
|---|---|
| IDFA-based attribution | First-party deep link attribution |
| Cross-app fingerprinting | Apple's SKAdNetwork / Google Attribution Reporting |
| User-level ad reporting | Aggregated campaign reporting |
| Third-party cookies | Server-side attribution with first-party data |
| Device ID matching | Probabilistic modeling with aggregated data |
Building Privacy-Compliant Deep Link Analytics
1. Use First-Party Attribution
The simplest way to comply with privacy regulations is to handle attribution yourself using your own deep links.
When a user clicks your deep link:
- Your deep linking platform records the click (first-party data)
- The user installs/opens your app
- Your SDK matches the open to the click using first-party data
- All attribution stays within your own systems
This doesn't involve third-party tracking, doesn't require ATT consent, and is covered by legitimate interest under GDPR. Your analytics dashboard shows you which links drive clicks, installs, and conversions without sharing data externally.
2. Implement Consent Management
For activities that require consent, implement a consent management platform (CMP):
Before first data collection, show a consent dialog that:
- Clearly explains what data you collect and why
- Lists each purpose separately (analytics, advertising, personalization)
- Provides granular opt-in/opt-out per purpose
- Doesn't use dark patterns (pre-checked boxes, confusing language)
- Records the consent decision with a timestamp
Based on consent status, enable or disable tracking:
- Full consent: Enable all analytics, including third-party attribution
- Analytics only: Enable first-party analytics, disable third-party data sharing
- No consent: Disable all non-essential tracking, use only aggregated server-side metrics
3. Minimize Data Collection
Collect only what you need. For most deep link analytics, you need:
Essential:
- Click timestamp
- Link/route identifier
- Platform (iOS/Android/web)
- Whether the user had the app installed (for routing)
Useful but not essential:
- Country (derived from IP, not stored)
- Device type (for debugging and optimization)
- Referrer (which page or app the click came from)
Probably unnecessary:
- Exact IP address (use geo lookup, then discard the IP)
- Full device fingerprint
- User agent string (beyond basic parsing)
- Persistent cross-session identifiers for non-logged-in users
4. Anonymize and Aggregate
Where possible, work with aggregated data instead of individual records:
- Report click-to-install rates per campaign, not per user
- Show conversion funnels as percentages, not individual paths
- Aggregate geographic data to country level (not city or zip code)
- Use cohort analysis (group behavior) instead of individual user tracking
Aggregated data is generally not considered personal data under GDPR, which simplifies compliance significantly.
5. Honor Data Deletion Requests
Under GDPR and CCPA, users can request deletion of their data. Your analytics system must support:
- Identifying all data associated with a user (by account, device, or other identifier)
- Deleting or anonymizing that data within the legally required timeframe (typically 30 days)
- Confirming deletion to the user
For deep link analytics, this means being able to remove or anonymize individual click and conversion records when requested.
SKAdNetwork and Privacy Sandbox
Apple SKAdNetwork (SKAN)
For iOS, SKAdNetwork is Apple's privacy-preserving attribution framework. It provides:
- Campaign-level attribution (which ad network and campaign drove the install)
- Conversion value (a 6-bit value you define, typically mapping to post-install events)
- No user-level data (attribution is aggregated and delayed)
Limitations:
- Attribution is delayed (24-48 hours minimum)
- Only 64 possible conversion values
- No view-through attribution in early versions
- Limited campaign ID count per ad network
How to work with SKAN: Use it for paid campaign attribution on iOS alongside your first-party deep link attribution. SKAN handles the ad-network-side attribution; your deep links handle everything else.
Google Attribution Reporting API
Google's Privacy Sandbox equivalent provides:
- Event-level reports (limited, with noise added)
- Aggregate reports (summary statistics across many users)
- Attribution without cross-app user tracking
How to use it: Similar to SKAN, use it for paid campaign attribution while relying on first-party deep link attribution for organic, referral, and owned channels.
Privacy Policies and Disclosures
What to Include
Your privacy policy should clearly state:
- What deep link data you collect (clicks, device type, timestamps)
- Why you collect it (to route users, measure campaign performance, improve the app)
- How long you retain it (set and enforce retention periods)
- Who you share it with (ad networks, analytics providers, or "nobody" if first-party only)
- How users can exercise their rights (access, deletion, opt-out)
Cookie and Tracking Banners
If your deep links resolve through a web page (fallback page, landing page, smart banner), that page may set cookies. If so, you need a cookie consent banner for EU visitors that:
- Blocks non-essential cookies until consent is given
- Provides clear accept/reject options
- Doesn't block access to the page (soft consent walls)
Practical Tips
Default to privacy: When in doubt, collect less. You can always add tracking later with proper consent; removing tracking after a privacy violation is much harder.
Separate first-party from third-party: Keep your own analytics data separate from third-party ad platform data. Your first-party data has fewer restrictions and is more durable as privacy regulations evolve.
Audit regularly: Review what data your analytics SDKs collect. Third-party SDKs sometimes add new data collection in updates. Audit each SDK update for privacy implications.
Document your decisions: Maintain a record of what you track, why, and what legal basis you rely on. This is both a GDPR requirement (accountability principle) and good practice for when privacy laws change.
For the technical setup of deep link analytics, see Deep Link Analytics: Measuring What Matters. For a specific focus on GDPR and attribution, see Attribution and GDPR Compliance.
Get deep linking tips in your inbox
One email per week. No spam.
