AppsFlyer and Data Protection – What Website Operators Need to Know

When a website operator or app operator uses AppsFlyer, it processes user and attribution data for the purpose of mobile marketing attribution and app analytics on the basis of consent (for tracking) or partly on the basis of legitimate interests (for server-side attribution) under the GDPR. This information is based on provider information and publicly accessible sources.

A. Purpose and Function of AppsFlyer

AppsFlyer is a mobile marketing attribution and app analytics platform headquartered in Israel (Tel Aviv) with offices in the USA, Europe and Asia. The company helps app developers, advertisers and marketing agencies understand which advertising channel (e.g. Facebook, Google Ads, in-app advertising networks) generated which app download, which in-app action (e.g. registration, purchase) and which revenue – the so-called "attribution".

Primarily: AppsFlyer is used as a Mobile Measurement Partner (MMP), i.e. it is primarily integrated into mobile apps as an SDK (Software Development Kit). The SDK records in-app events, installations and user interactions.

Secondarily: AppsFlyer also offers web attribution – i.e. it can also be integrated on websites in order to track web-to-app or web-to-web conversions.

Technically with mobile apps: The AppsFlyer SDK is embedded in the source code of the app. With every app launch and on certain events (e.g. registration, purchase), the SDK sends data to AppsFlyer's servers. This data includes device identifiers (e.g. IDFA on iOS, Google Advertising ID on Android), device and app information as well as event details.

Technically on the web: AppsFlyer also provides a web pixel that works similarly to Google Analytics or other tracking pixels and is embedded on websites. The pixel records website visits and user interactions.

Attribution logic: AppsFlyer uses device identifiers, IP addresses, timestamps and cookie data to connect an advertising action (e.g. click on a Facebook ad) with a later app installation or in-app action (last-click attribution or multi-touch attribution).

B. Mandatory Disclosures in the Privacy Policy regarding AppsFlyer

The GDPR requires app and website operators to transparently explain the following points:

• Processing purposes (Art. 13(1)(c)): Why is data processed?
• Legal bases (Art. 13(1)(c)): On what legal basis is the processing carried out?
• Legitimate interests (Art. 13(1)(d), if relevant): If legitimised through legitimate interests
• Recipients or categories of recipients (Art. 13(1)(e)): To whom is data disclosed?
• Third-country transfers (Art. 13(1)(f)): Is data transferred to countries outside the EU/EEA?
• Retention period (Art. 13(2)(a)): How long is data stored?
• Data subject rights (Art. 13(2)(b) and (c)): Rights of access, erasure and objection

Common error: Tool-specific text templates from providers' privacy policies contradict the transparency requirement. A topic-oriented approach is better: structure by processing purposes (e.g. "Mobile Attribution", "App Analytics"), not by individual tools.

C. Provider of AppsFlyer: AppsFlyer Ltd.

Note: Israel is not a third country within the meaning of the GDPR; an adequacy decision by the EU Commission exists. Data transfers to Israel are GDPR-compliant under certain conditions.

D. Data Processing by AppsFlyer – Sequence

E. Data Collected when Using AppsFlyer

AppsFlyer collects a wide range of user and attribution data:

For mobile apps (SDK):

• Device identifiers (IDFA on iOS, Google Advertising ID on Android, Android ID)
• IP address
• Device type, operating system, operating system version
• App version and app name
• Installation date and time
• In-app events (e.g. registration, purchase, content view)
• Event parameters (e.g. product name, price, category, revenue)
• Advertising source and campaign parameters
• Time zone and language

For web (web pixel):

• IP address
• Cookie IDs
• Referrer and visited URLs
• Browser and device information
• Conversion events

This data can be classified into the following standardised data categories:

• Web server log data: IP address, date/time/time zone, referrer, browser/OS/device, technical metadata
• Device data: Device type, operating system, screen resolution/size, orientation
• Browser information: Browser name, browser version
• Device identifiers: IDFA, Google Advertising ID, Android ID
• Conversion events: App installation, in-app action, registration, purchase
• Usage profiles: Advertising source, campaign attribution, usage histories

F. Purposes of Use when Using AppsFlyer

AppsFlyer processes data with the following purposes:

• Attribution and measurement: Mapping of advertising actions to app installations and in-app conversions
• General marketing: Measurement of campaign success, ROI optimisation, benchmarking
• User profile creation: Segmentation by user properties, cohort building
• Security and abuse protection: Fraud detection (e.g. fake installations), bot detection
• General product improvement: Optimisation of the measurement and platform on the basis of aggregated data
• User-individual marketing: Remarketing lists, audience export to advertising networks

G. Legal Bases for AppsFlyer

Category 1 – Web tracking via AppsFlyer pixel: AppsFlyer is a tracking tool similar to Google Analytics. It requires consent.

Legal basis (web tracking): Consent pursuant to Art. 6(1)(a) GDPR in conjunction with Section 25(1) TDDDG. The website operator must obtain the visitor's consent before loading the AppsFlyer pixel.

Category 2 – Mobile SDK and server-side attribution: Here it can be more differentiated. AppsFlyer itself is mainly legitimised through consent (Apple and Google require this for device identifiers). However, parts of the data processing (e.g. server-side attribution after deletion of device identifiers) can also be based on legitimate interests (Art. 6(1)(f) GDPR).

Case-by-case review required: The exact legal basis depends on which data is processed in which context. A blanket statement is not possible.

Consent mechanism (web): A cookie banner or CMP must ask for consent before AppsFlyer is loaded. The consent must be specific and documented.

H. Special Features and Notes on AppsFlyer

• Primarily mobile, secondarily web: AppsFlyer is originally and primarily a mobile measurement tool (SDK). Web attribution is an additional feature. Website operators should be aware that AppsFlyer is not the primary target group.
• Israel as country of registered office: AppsFlyer is based in Israel. An adequacy decision by the EU Commission exists. Data transfers to Israel are legally compliant; however, current developments should be monitored.
• EU representative: AppsFlyer has appointed an EU representative in Berlin pursuant to Art. 27 GDPR.
• Further legal bases for mobile apps: With mobile apps, device identifiers (IDFA, Google Advertising ID) can only be processed under iOS and Android with consent. This consent is obtained via the operating system, not via the app privacy policy. Website operators should communicate this.
• Opt-out/privacy settings: Users can deactivate ad tracking on their device (iOS: "tracking refused", Android: "deactivate personalised advertising"). AppsFlyer should respect these preferences.
• Contact: AppsFlyer's data protection officer can be reached at privacy@appsflyer.com.

I. FAQ on AppsFlyer

J. Conclusion and Recommendation on AppsFlyer

Summary: AppsFlyer is a tracking and attribution tool that is used primarily in mobile apps and secondarily on websites. It requires explicit consent for web use.

Why text templates are problematic: The privacy policy should not simply copy AppsFlyer's privacy policy. This contradicts Art. 12(1) GDPR. Users should understand which data is collected and for what – not be confused by technical jargon.

Recommended approach: A topic-oriented privacy policy that is structured by processing purposes (e.g. "Mobile Marketing Attribution") is clearer and more legally sound. Name AppsFlyer as one of the recipients in a recipient list.