Mobile Attribution Under GDPR: Compliance Guide

The General Data Protection Regulation applies to mobile attribution in ways that many teams underestimate. If you collect click data, device identifiers, IP addresses, or behavioral signals from users in the EU or EEA, you are processing personal data under GDPR. That processing requires a lawful basis, documented controls, and the ability to honor user rights.

This guide covers what GDPR requires for attribution specifically, the common approaches teams use to achieve compliance, and how to configure your attribution setup accordingly.

Why Attribution Is Subject to GDPR

GDPR's definition of personal data is broad: any information relating to an identified or identifiable natural person. In mobile attribution context, several types of data fall under this definition:

IP addresses: EU data protection authorities, including the European Court of Justice, have consistently held that IP addresses are personal data when combined with the ability to identify the user behind them.

Device advertising identifiers (IDFA, AAID): These are directly linked to a specific device and indirectly to the person who uses it. They qualify as personal data.

Device fingerprints: A combination of device signals used to probabilistically identify a device. Even when individual signals are not personal data, the combination may be, especially when used for tracking.

Click records with user attribution: Any click record associated with a device ID or IP address that can identify or be linked to a person.

In-app behavioral data: Events, session data, and usage patterns linked to a user account or device.

If your attribution pipeline processes any of these data types for users in the EU or EEA, GDPR applies.

The Six Lawful Bases

GDPR requires that every act of personal data processing have a lawful basis. There are six options, but for attribution purposes, only two are practically relevant:

Consent (Article 6(1)(a)): The user has given clear, specific, informed, and freely given consent to the processing. For cookie-based tracking and advertising identifiers, this is the most common basis used by ad-supported apps.

Legitimate interest (Article 6(1)(f)): The processing is necessary for the legitimate interests of the controller or a third party, provided those interests are not overridden by the individual's rights and freedoms.

The other bases (contract, legal obligation, vital interests, public task) are not appropriate for most attribution use cases.

Consent for Attribution

Using consent as your lawful basis means you must obtain it before processing attribution data, not after. This has practical implications for when you initialize your attribution SDK.

What valid consent looks like under GDPR:

• Freely given: Users must have a genuine choice. Bundling attribution consent with app functionality ("we can't show you the app without tracking consent") is not freely given consent.
• Specific: Consent must cover specific purposes. "Marketing analytics" is not specific enough if you are combining attribution data with behavioral profiles for ad targeting.
• Informed: Users must understand what they are consenting to, who processes their data, and for what purpose.
• Unambiguous: A pre-ticked checkbox does not constitute consent. The user must take an affirmative action.
• Withdrawable: Users must be able to withdraw consent as easily as they gave it.

Practical implementation:

Before initializing your attribution SDK or any tracking functionality, present a consent interface that meets these requirements. Many apps use a Consent Management Platform (CMP) to standardize this flow. The IAB Europe Transparency and Consent Framework (TCF) is widely used in the EU advertising ecosystem.

After the user makes a choice:

• If they consent: initialize attribution tracking, set the advertising identifier
• If they decline: use only essential analytics (crash reporting, performance) and do not fire attribution events

Store the consent record with a timestamp and the consent text version. You will need this documentation if your processing is ever challenged.

Legitimate Interest for Attribution

Legitimate interest (LI) is sometimes used as an alternative to consent for attribution, particularly for first-party analytics. It requires a three-part test:

1. Purpose test: Is there a legitimate interest? For attribution, this might be measuring the effectiveness of your own marketing campaigns.
2. Necessity test: Is the processing necessary for that interest? You should not collect more data than needed.
3. Balancing test: Does your interest override the individual's rights? This weighs the intrusiveness of the processing against the benefit to your business.

Legitimate interest is more defensible for first-party analytics (understanding how your own users found your app) than for third-party ad network attribution (sharing click data with ad networks for CPI billing). The distinction matters.

For cross-app tracking via advertising identifiers shared with third-party ad networks, most EU data protection authorities have rejected legitimate interest as a valid basis. The CNIL (France's DPA) and other national regulators have been explicit on this point. Consent is generally required for this type of processing.

What this means practically: If you rely on legitimate interest for attribution, document your LI assessment. If challenged, you need to demonstrate that you ran the three-part test and reached a defensible conclusion. LI assessments for third-party ad attribution are hard to defend; for first-party analytics, they are more plausible.

Data Processing Agreements

When you use an MMP, attribution platform, or analytics service, GDPR requires a Data Processing Agreement (DPA) if you are the data controller and the vendor is processing data on your behalf.

A DPA must specify:

• The subject matter and duration of processing
• The nature and purpose of processing
• The type of personal data and categories of data subjects
• Your obligations and rights as controller
• The processor's obligations (security measures, sub-processor restrictions, audit rights, data deletion)

Most major attribution platforms and MMPs provide standard DPAs. Review these for completeness before signing. Key provisions to verify:

• Sub-processors: The DPA should list all sub-processors (infrastructure providers, etc.) and require notification if sub-processors change.
• International transfers: If your vendor stores or processes data outside the EEA, the DPA must include Standard Contractual Clauses (SCCs) or another approved transfer mechanism.
• Breach notification: The vendor should commit to notifying you within 72 hours of becoming aware of a personal data breach, so you can meet your own notification obligations.
• Data deletion: The vendor should delete or return your data when the agreement ends.

Tolinku's DPA is available for all accounts processing EU user data. Contact Tolinku support to obtain a signed copy.

User Rights Under GDPR

GDPR grants EU residents several rights related to their personal data. Your attribution setup needs to be capable of honoring these rights:

Right of access (Article 15): Users can request a copy of all personal data you hold about them, including attribution data. You need to be able to query your attribution system for all data associated with a specific user and produce it in a readable format within 30 days.

Right to erasure (Article 17): Users can request deletion of their personal data. This requires being able to delete all attribution records associated with a user across your system and any sub-processors. If you share attribution data with an MMP, the deletion request must flow to them as well.

Right to portability (Article 20): For data processed with consent, users can request their data in a machine-readable format to transfer to another controller.

Right to object (Article 21): For processing based on legitimate interest, users can object. If they do, you must stop processing unless you can demonstrate compelling legitimate grounds that override the individual's interests.

Implementing user rights operationally:

Build a process for handling subject access requests (SARs) before you receive them. This means:

• Knowing which systems contain personal attribution data (your database, your MMP, your analytics platform)
• Being able to query each system by user identifier or email
• Having a defined process for aggregating responses and delivering them to the user
• Having a deletion pipeline that propagates delete requests to all relevant systems

GDPR-Compliant Attribution Setup

Here is a practical checklist for configuring attribution in a GDPR-compliant way:

Consent gate:

• Consent is obtained before any attribution SDK initialization
• Consent interface meets GDPR requirements (specific, informed, freely given, unambiguous)
• Consent records are stored with timestamp and version
• Users can withdraw consent from app settings

Data minimization:

• Attribution data collected is limited to what is necessary for the stated purpose
• IP addresses are anonymized (last octet zeroed) after device matching if full IP is not needed for ongoing purposes
• Device identifiers are not stored longer than necessary

Data retention:

• Retention periods are defined for attribution records
• Automated deletion or anonymization runs at the end of retention periods
• Retention periods are documented in your privacy policy

Third-party processors:

• DPAs are in place with all attribution vendors and MMPs
• International transfer mechanisms are in place for non-EEA processors
• Sub-processor changes trigger review

User rights:

• SAR handling process is documented and tested
• Deletion pipeline covers all systems including third-party vendors
• Privacy policy accurately describes attribution processing

Privacy-Preserving Attribution Alternatives

For users who decline tracking consent, you still have options for understanding acquisition sources without processing personal data:

Aggregated cohort reporting: Instead of individual-level attribution, report on cohorts segmented by acquisition source. If 1,000 users installed from a specific campaign, you know the campaign's contribution without needing individual records.

On-device attribution: Some attribution flows can be completed on-device with aggregated reporting, similar to how SKAdNetwork works on iOS. No individual user data leaves the device in a personally identifiable form.

Contextual signals: For campaign optimization purposes, contextual signals (the content category of the page where an ad appeared, broad geographic region, device type) can be used without individual tracking and do not require consent for processing.

First-party login data: For users who create accounts and consent to your broader terms of service, first-party attribution (knowing which campaign drove them to sign up) can be framed as part of the service relationship rather than cross-app tracking.

Key Resources

For authoritative guidance on GDPR and digital advertising, the following sources are directly relevant:

• European Data Protection Board guidelines on consent
• ICO (UK) guidance on legitimate interest
• IAB Europe Transparency and Consent Framework
• Tolinku attribution concepts documentation
• Mobile attribution developer guide
• Privacy Sandbox on Android: Attribution API guide

GDPR compliance for attribution is not a one-time setup. Data protection law and regulatory guidance continue to evolve. The most important thing is having the documentation, processes, and technical controls in place to demonstrate that you are processing personal data responsibly. The specific configuration may need to be revisited as guidance develops.