Privacy-Aware Web-to-App Measurement

Keep measurement apart from routing

A deep link answers one question: which screen should open? Measurement answers another: which campaign led to the visit or install? Mixing them is how routes break. A click-tracking redirect placed in front of a verified link moves the tap to a domain that is not associated with your app, and the platform decides on that domain, not yours. The note on routing and attribution walks through the failure and the alternatives.

Android: the Play Install Referrer

For apps installed from Google Play, the Install Referrer API returns, in Android's words:

• "The referrer URL of the installed package."
• "The timestamp, in seconds, of when a referrer click happened (both client- and server-side)."
• "The timestamp, in seconds, of when an installation began (both client- and server-side)."
• "The app's version at the time when the app was first installed."
• "Whether the user has interacted with your app's instant experience in the past 7 days."

Devices with Google Play app version 8.3.73 or later have access automatically, and you need a Play Console account. Google recommends the Play Install Referrer Client Library for Kotlin or Java. The referrer is how an Android app can learn which campaign link preceded an install and, if you choose, which page to open on first launch.

iOS: the tracking prompt

Apple's App Tracking Transparency framework asks permission to access "app-related data that can be used for tracking the user or the device." The request "is a one-time request": "The system remembers the user's choice and doesn't prompt again unless a user uninstalls and then reinstalls the app on the device." The prompt only appears while the app is active, not while another permission request is pending, and the app must include the NSUserTrackingUsageDescription key in its information property list.

For a gambling app, ask only if user-level tracking is necessary, explain why in plain words, and respect the answer across every tool in the app.

iOS: AdAttributionKit

AdAttributionKit "helps advertisers measure the success of ad campaigns while helping maintain user privacy." It covers installs and re-engagement from ads shown in other apps; it does not attribute clicks from your own website, email or QR codes. Apple decides a postback data tier to protect crowd anonymity, and "The information in the postback that Apple cryptographically signs doesn't include user- or device-specific data." Apple also says apps "don't need to use App Tracking Transparency before calling ad attribution APIs." The framework is available from iOS 17.4.

It reports at campaign level, not person by person, so it cannot open a specific screen for a specific new user. Treat it as reporting, not routing.

On the web side

• Apply your site's consent choices to any web analytics that run before the app is opened.
• Keep personal data out of link parameters. URLs end up in logs, browser history and screenshots.
• Prefer short campaign identifiers that your server maps to campaigns, rather than long chains of tracking parameters.
• If you moved off Firebase Dynamic Links, check that old campaign links no longer appear in emails and QR codes; the migration guide covers what happens to them.

Limits to state in your reports

None of these tools sees every install. Referrer data covers Play installs; AdAttributionKit covers attributable ad impressions; the tracking prompt depends on each person's choice. Report what each source covers, and do not merge them into a single figure as if they measured the same thing. Any link parameters you rely on should also pass the checks in the deep link security guide.