SDK
Privacy labels
What the Appy SDK collects, and how to answer Apple’s App Privacy questions and Google Play’s Data safety form with strict and with standard attribution.
Apple and Google ask every app to declare the data that it and its SDKs collect. This page lists what the Appy SDK sends, what Appy keeps on your behalf, and the answers that follow from it in each attribution mode. You submit the answers and remain responsible for them. Your own code and your other SDKs add to them. For apps for children, health or finance, go through them with whoever owns privacy in your company.
Strict or standard attribution
The SDK sends the same requests in both modes. What differs is what Appy’s servers do with them. Strict attribution is a per-app setting in the dashboard and the API.
| Strict attribution | Standard attribution | |
|---|---|---|
| How an install gets its link | Only from evidence that names the link: the link that opened the app, a click id, the store install referrer, Meta’s install referrer, a Google Ads click, or Apple Ads. | The same, then a recent tap on one of your links that fits the install. |
| Device signals used to match | None. | A daily-changing keyed hash of the network address, the OS version and the device model. |
| Taps on your links | When every app in the account is strict: link, parameters, platform and time. No OS version, no device model, no network hash. | Link, parameters, platform, time, OS version, the device model on Android, and a network hash kept for two hours. |
| iOS installs after a link tap | Organic, unless Apple Ads attributed them. The App Store passes nothing from the tap to the app. | Attributed when a fitting tap is found; verified is false. |
| Android installs after a link tap | Attributed through the Google Play or AppGallery install referrer. | The same. |
| Opens through a link | Added to the link’s click statistics with the IP address and a user agent built from the OS version, device model and SDK version. | The same. |
Standard attribution and Apple’s fingerprinting rule
Apple does not allow apps to derive data from a device to identify it, whether or not the user allowed tracking, and says apps that use attribution services doing so may be rejected. Standard attribution compares a network hash, the OS version and the device model to connect a tap with an install. Decide with your privacy counsel before you use it in an iOS app. Strict attribution does not use these signals.
What the SDK sends
| Data | Sent with | Kept by Appy |
|---|---|---|
| Install id: a random UUID created on the first launch, in the app’s own storage | Every open and event | With the install, until you delete it |
User id, only if you call setUserId and tracking is on | Opens, events | With the install and events, until you delete them |
| Platform, OS version, device model, locale | Every open | With the install |
| App id, version, build; on Android the installing store | Every open | With the install |
| The Appy link that opened the app, with its parameters | Opens through a link | With the install on the first launch, and in the link’s statistics |
| Store install referrer (Android, first launch) | First open | The link and parameters it names |
Meta install referrer (Android, only with metaAppId) | First open | The campaign it names |
| Apple Ads token (iOS 14.3 and newer, first launch) | First open | Up to 7 days, only when the app’s Apple Ads setting is on; the campaign Apple returns stays with the install |
| Events: name, properties, revenue, currency, time | Events | Until you delete them |
- The SDKs do not read the IDFA, the IDFV, the Android advertising ID, the Android ID, hardware serials, location, contacts, the clipboard or the list of installed apps, and do not show the App Tracking Transparency prompt.
- Every request uses HTTPS. Install records do not contain an IP address.
- When an Appy link opens the app, in both modes, Appy adds the open to that link’s click statistics like a tap in a browser. The record holds the IP address as received and a user agent built from the platform, OS version, device model and SDK version. Appy uses the pair to count unique opens. The record stays until the link or the account is deleted.
- With
isTrackingEnabledset tofalse, the SDK sends no events and no first-launch request, and Appy stores nothing for that device. - Your backend can delete one install or every install and event of a user id: see Deleting a user’s data.
Apple: App Privacy in App Store Connect
Add these to the answers for your own code. The types use Apple’s names. Appy does not combine your app’s data with other companies’ data and does not pass it to data brokers.
| Apple data type | Collect it? | Linked to the user | Used for tracking | Purposes |
|---|---|---|---|---|
| Identifiers › Device ID | Yes: the install id | Yes | No | App Functionality, Analytics |
| Identifiers › User ID | Only if you call setUserId | Yes | No | App Functionality, Analytics |
| Usage Data › Product Interaction | Yes: launches, opens through links, the events you track | Yes | No | App Functionality, Analytics |
| Purchases › Purchase History | Only if your events carry revenue | Yes | No | Analytics |
| Usage Data › Advertising Data | Only with the Apple Ads setting on | Yes | No | Analytics |
| Other Data › Other Data Types | Yes: device model, OS version, locale | Yes | No | App Functionality, Analytics |
- Strict attribution: the answers above apply as they are.
- IP address: Apple asks you to declare a stored IP address by what it is used for. Install records hold none. Opens through a link are stored with the IP address and the device user agent and used to count unique opens, so declare them under Device ID (and Product Interaction for the open itself). Appy does not derive a location from them.
- Standard attribution: the data types are the same. The difference is the use of the network hash, OS version and device model to match a tap with an install; see the warning above before you answer the tracking question.
- Event properties are whatever your app sends. If they contain other data, such as health or financial details, declare those types too.
The SDK’s privacy manifest
The Swift package ships PrivacyInfo.xcprivacy. Xcode adds it to the privacy report of your archive (Product › Archive, then Generate Privacy Report in the Organizer).
| Key | Value |
|---|---|
NSPrivacyTracking | false |
NSPrivacyTrackingDomains | Empty |
NSPrivacyCollectedDataTypes | Device ID, User ID, Product Interaction, Purchase History, Advertising Data and Other Data Types; each linked, not used for tracking |
NSPrivacyAccessedAPITypes | UserDefaults with reason CA92.1, for the SDK’s own to.appy.sdk suite |
Google Play: Data safety
| Google data type | Collected | Shared | Purposes |
|---|---|---|---|
| Device or other IDs | Yes: the install id | No | App functionality, Analytics |
| Personal info › User IDs | Only if you call setUserId | No | App functionality, Analytics |
| App activity › App interactions | Yes: launches, opens through links, the events you track | No | App functionality, Analytics |
| Financial info › Purchase history | Only if your events carry revenue | No | Analytics |
- Purposes: Google counts measuring ad performance as Advertising or marketing. If you use Appy to measure campaigns or ads, add that purpose to the Device or other IDs and App interactions rows.
- Shared: Google does not count a transfer to a service provider that processes data on your behalf as sharing. Appy processes the data on your behalf. Postbacks you set up to send installs or events to an ad network or another company are your own sharing; declare them.
- IP address: Google asks you to declare IP addresses by how they are used. Opens through a link are stored with the IP address and the device user agent to count unique opens; declare them under Device or other IDs. Appy does not derive a location from SDK requests, so Approximate location is not part of the answers for the SDK.
- Is all user data encrypted in transit: yes.
- Can users request deletion: provide your own way, and erase their data with
DELETE /v1/apps/{appId}/installs?userId=. - Is collection optional: answer yes only if your app asks first and sets
isTrackingEnabledfrom the answer. - Strict and standard attribution: the answers are the same. The install referrer the SDK reads on the first launch is used to find the link and is not kept as a separate value.
Apps for children
- Turn on strict attribution, so that no device signals are used to match installs.
- Do not call
setUserIdwith anything that identifies the child. - If your app needs parental consent before any data leaves the device, keep
isTrackingEnabledoff until you have it. Links that open the app still work. - The install id is a persistent identifier. Whether your use of it needs consent is for your counsel to decide.
Checklist
- 1
Pick the mode
Turn on strict attribution for each app that should only count installs Appy can verify.
- 2
Decide on consent
Set
isTrackingEnabledtofalsebefore the SDK starts if your app asks first, and to the answer afterwards. - 3
Fill in App Store Connect
Add the Apple rows above to your App Privacy answers, then compare them with the privacy report of your archive.
- 4
Fill in Google Play
Add the Google rows above to your Data safety form, plus any postbacks you send to other companies.
- 5
Wire up deletion
Call the delete endpoint from your backend when a user closes their account or asks to be forgotten.