Test and launch

Privacy and store forms

What the SDK collects, and how to answer Play's Data safety and Apple's privacy questions.

The SDK collects only what it needs to match installs to taps. It doesn't use advertising IDs, contacts, location or anything that identifies a person.

What the SDK sends#

Data	Why
A random install ID, created by the SDK	Tells launches of the same install apart. It isn't the advertising ID, the Android ID or the IDFV.
App version and SDK version	Shown in the Install debugger.
Device model, OS version, locale, time zone, screen size	Used to match an install to a tap.
Android only: the Play install referrer, until the install is attributed	Contains the `click_id` of the tap that led to the Play Store.
Events you track: name, time, properties and revenue	Reporting what users do after installing, per link and creator. Properties that look like an email or phone number are dropped.
Your user ID, if you call `identify`	Crediting a user's revenue across reinstalls and devices.
SHA-256 hashes of email and phone, only if you pass them to `identify`	Matching the same person across devices. The plain values never leave the phone.

The phone's IP address is seen by the server, as with any request. It's used for matching, then stored only as a salted hash that rotates daily.

What the SDK stores on the phone#

The install ID, the last attribution and the tracking setting. On Android they're in the app's no-backup folder, so a phone restored from backup gets a new install ID. On iOS they're in the app's UserDefaults.

Events waiting to be sent, and the last user ID, are kept in a small file next to them (excluded from backups) until the server has them. Email and phone are never stored, not even hashed. The SDK never stores your key's secret.

If a user declines tracking, call setTrackingEnabled(false): it deletes waiting events and stops events and identify. To delete a user's data from Dropplink, use DELETE /v1/s2s/users/:userId.

Google Play: Data safety#

In the Data safety form, declare Device or other IDs as collected, for Analytics, not shared with third parties.

If you use events and identify, also declare, for Analytics:

User IDs, linked to the user (your user ID);
App interactions (the events you track);
Purchase history, if you track revenue;
Email address and Phone number, only if you pass them to identify. They're hashed on the device, but Google still counts hashed identifiers as collected.

If you send the attribution to your own analytics, linked to user accounts, declare that use as well.

Apple: privacy manifest and App Store#

The iOS SDK includes a privacy manifest (PrivacyInfo.xcprivacy) with:

NSPrivacyTracking set to false, so no tracking domains;
UserDefaults access, reason CA92.1 (the app's own data);
the install ID declared as a Device ID used for Analytics, not linked to the user and not used for tracking;
since 0.2.0, for events and identify: User ID, Email Address, Phone Number, Product Interaction and Purchase History, each linked to the user, used for Analytics, not for tracking.

Apple merges the SDK's manifest into your app's privacy report. If you don't use identify with email or phone, you can leave those two out of your App Store answers.

Answer the App Store privacy questions to match. The SDK doesn't use the IDFA, so it doesn't need the App Tracking Transparency prompt.

This page describes the SDK only. Your app's own answers depend on what else it collects. Check them with whoever owns privacy at your company.