First-party mobile app measurement & install tracking
Privacy related developments such as tracking prevention mechanisms impacts web measurement. But what about mobile apps? Next to advertising and ad attribution (e.g. Apple's App Tracking Transparency), it also impacts first-party app measurement, campaign and install tracking. This article will shed some light on app measurement in general and how to optimize first-party measurement of mobile apps and campaigns (both Android as iOS).
- Impact of recent privacy related updates and changes (such as iOS 14.5)
- What user identifiers are used to measure cross-app (device) and in-app behavior.
- How to measure in-app activity & engagement.
- How to track campaigns when opening or installing an app.
Technical solutions and architecture.
Note: This article does not express my opinion about companies like Google or Apple and their approach to privacy. I'll stick to the facts and consequences of decisions they made, but I certainly do recognize the underlying motives; an increased need and focus for privacy and transparency.
The Advertising (Device) Identifiers (IDFA / GAID)
So, let's start with the user identifier that is (or was) used for cross-app, device tracking and received the most impact recently; the Advertising Identifier. The Advertising Identifier can be seen as the third-party cookie of the mobile app ecosystem. When enabled, the IDFA is able to track the same user (mobile device) over different apps. For example:
- Ad networks can track and (re)target users
- Attribution of ad impressions / clicks from an publishers app to conversions in your own app.
- Install tracking, by using the IDFA as an identifier before and after the redirect to an app store.
As mentioned, the IDFA can be used to track and target users cross-app and is an unique identifier for a device.
Both iOS (Apple) and Android (Google) use a variant of the advertising identifier;
| Platform | Identifier | Description | Remarks |
|---|---|---|---|
| Android | GAID | Google Advertising ID. Identifies the unique device | User consent needed in most cases. |
| iOS | IDFA | ID For Advertisers. Identifies the unique device | User consent needed trough the AppTransparencyFramework and additionally your company specific consent. |
Recently, as of iOS version 14.5, Apple basically disabled the use of the IDFA by introducing the App Tracking Transparency (ATT) framework. This heavily impacted platforms like Facebook that depended on the IDFA for ad targeting and cross-app user tracking.
iOS App Tracking Transparency (ATT)
Introduced in iOS 14.5, a user needs to give explicit permission though the iOS AppTransparencyFramework (ATT) when certain types of (user) data is collected in an app and shared with third-party vendors. The framework basically is an iOS "native" consent popup which can't be altered a lot (design or inner workings). You also need to document the data collected in your privacy details.
In their documentation, Apple is mentioning situations (important!) where where permission through the AppTransparencyFramework is necessary. Mostly related to sharing data with third-parties that is used for ad targeting or to track users (cross-app and device). Not adhering to these rules can result in your app being deleted from the iOS App Store.
When talking about first-party measurement, the last situation they mention is important:
- Placing a third-party SDK in your app that combines user data from your app with user data from other developers’ apps to target advertising or measure advertising efficiency, even if you don’t use the SDK for these purposes. For example, using an analytics SDK that repurposes the data it collects from your app to enable targeted advertising in other developers’ apps.
Apple allows you to collect first-party data for analytics purposes without a user consenting to the ATT popup. (but, make sure you don't use this data for retargeting for example and also make sure you are compliant to local privacy rules).
Without an Advertising-ID, it's perfectly possible to measure (first-party) in-app user engagement and campaign performance, and in some cases install tracking.
First-party measurement: The App Instance Identifier
To measure first-party app activity, you will need some sort of identifier that can identity activity of the same user over different app "sessions" (probably not the right term when talking about apps). In contrary to the advertiser-ID, the instance-ID doesn't identify the same user over different apps, so it can't be used to recognize the same user of different apps. You could compare this with a first-party cookie on web. In general:
- The instance identifier uniquely identifies an app installation on a specific device.
- Doesn't track a user over different apps (third-party context).
- In most cases, when app or device cache is reset or an uninstall occurs, the instance identifier is deleted.
As an app developer, one could create such an instance identifier yourself but many app measurement and (campaign) attribution tools can handle this for you. Some pretty random examples of app measurement tools and how they're handling the app instance-ID:
| Framework | Instance Identifier | Description | Docs |
|---|---|---|---|
| Firebase / Google Analytics 4 | Firebase installation ID (FID) | Previously FirebaseInstanceId. FID is reset on uninstalls, clearing device or app cache or after 270 days of inactivity. Used for the Google Analytics 4 client-ID / user_pseudo_id. | docs |
| AppsFlyer | AppsFlyer ID | Automatically created on every install | docs |
| Adjust | Adjust Device Identifier | Created on install | docs |
| MixPanel | Distinct-ID | Reset on uninstalls or clearing app or device cache. | docs |
Using these tools, first-party measurement can be implemented (such as GA4 or Singular). Think of measuring first-opens, screen views, events, purchases. Most of these tools will handle some default events (app opens, first opens / installs or uninstalls) and implement other functionality (like Google's Install Referrer API) out-of-the-box.
When picking a first-party app measurement tool, make sure collection of Advertising Identifiers (see the first chapter) is disabled without user consent. Additionally, using iOS, when you want to leverage the IDFA, you need to enable to the Transparency Framework popup.
In general, implementation of these tools is roughly the same, you have to implement an SDK and set up screen and event tracking within your app. Depending on the tool of choice, they will provide an (reporting) interface and in most cases provide the option to access the data through an API or dump the data in analytical database (think of Google BigQuery when talking about Firebase).
But what about measuring campaign performance? How did users find and install your app? And if they already installed your app, how did you reactivate those users? For this, deep links come in handy.
Deep linking
It's convenient to open a specific screen within your app directly. For example when a user is searching for a specific product on the web, already has your app installed, clicks the product link and the app opens the specific product screen (instead of the home screen). For this, deep links can be used. When your app is already installed, this is commonly referred to as direct deep linking.
Deep linking is closely related to campaign (and install) tracking, since you can add campaign info to the deep links such as the campaign source, name or ad content (think of the well-known ?utm_xx= parameters), so campaign performance can be measured.
There is no industry standard regarding deep linking, so every platform handles it slightly different. Under the hood, iOS and Android are using the methods mentioned below (and by default only works when the app is already installed).
- iOS: Universal Links
- Android: Android App Links
But what if:
- A user clicking the deep link doesn't have your app installed?
- How to pass the deep link and campaign parameters to your app when a user is redirected to one of the app stores to install your app?
- A user is on a desktop device?
In the first two cases, deferred deep linking can be used. Basically, the deep link is "deferred" after the app is installed (deep linking with memory). For this to work, most likely you will like need a tool or framework that is handling this for you (like Firebase, Singular or Branch). Additionally (in most tools), you can customize flows that handle the different situations mentioned above.
A simple flow could like like this:
Next to deep link flows , most vendors are offering related features like app measurement, monitoring, attribution, deep linking (flows) and/or error logging in one product suite.
Deferred deep linking / app-to-app / web-to-app flows
As mentioned, deep links can be used to track campaigns and traffic sources (by adding campaign information to the deep link URL so that these are passed to the app). One problem: what if the app isn't installed and the user gets redirected to one of the app stores? Can we still pass the deep links and campaign parameters?
Yes, but seen the recent developments (e.g. iOS 14.5) options are limited.
Some of the most used mechanisms for deferred deep linking (and used by most tools in one form or another):
| Method | Type | Description |
|---|---|---|
| IDFA / GAID | Deterministic | The IDFA / GAID is used to identify the same user between a (deep link) click and a first-open (install). This way the deep link and campaign parameters can be retrieved on app open. Limited used due to user consent necessary / iOS 14.5. |
| Install Referrer API (Android) | Deterministic | Leveraging the Install Referrer API of the Play Store, campaign parameters used to visit the Play Store (before install) can be passed to the app on first-open. |
| Pasteboard "hack" | Deterministic | Saving the deep link on click in the iOS pasteboard and reading the value when (first) opening the app. Not possible after recent iOS update. |
| Use the app store analytics reports | Deterministic | Leveraging the reporting interfaces of the app stores to get (aggregated) information about campaign effectiveness |
| SKAdNetwork (iOS) | Deterministic | (privacy-first) mechanism for aggregated install attribution statistics. Cannot be used for deep linking, is not on user level and is not real-time (24-48 hours). Also see this article. |
| Fingerprinting | Probabilistic | Using identifiers like IP address to match the same user when clicking a deep link and opening the app after install. Not as accurate as the methods described above. Limited use duo to user consent needed in most cases. |
Install measurement
So which methods are left? The App Store and Play store have their own (simplified) analytics / measurement interface. Both app stores accept campaign tracking (URL) parameters when referring users to the stores, so app installs and other metrics can be attributed to campaigns.
App / Play Store campaign parameters
| Platform | Campaign tracking | Docs |
|---|---|---|
| Android | ?utm_...= parameters (like ?utm_source= and utm_medium=, same as Google Analytics) can be used to label traffic to the Google Play Store and viewed in the Play Store reports. | docs |
| iOS | The ?pt= (provider) and ?ct= (campaign code) URL parameters can be used to label traffic to the Apple App store. Reports available within Apple App Analytics. | docs |
This is nice and will give you some insights, but can we retrieve these values within the app and therefore your own, first-party measurement system? In iOS, no. Android? Yes. By using the Playstore's Install Referrer API to request the install referrer (campaign parameters used when visiting the Play Store) on the app's first open.
To summarize the available options for install tracking;
- Heavily depending on the tool you use to create deep links (or a framework developed in-house)
- Within Android, the Install Referrer API can be used
- On Android, the GAID linking method can be used, but usage is limited due to user consent. This method in iOS is practically deprecated after iOS 14.5.
- For both Android and iOS probabilistic methods (fingerprinting) can still be used, but make sure you know how this works exactly and have the necessary user consent.
- On iOS, the SKADNetwork can be leveraged for aggerated statistics (mostly for app-to-app flows)
Summary & closing thoughts
Overall, it's still perfectly possible to perform app measurement, including campaign measurement. The use of cross-app identifiers (IDFA/GAID) is limited nowadays due to developments related to privacy and tracking prevention. This is a good thing, but it does impact attribution, deep linking and install tracking. So you have to rethink your setup (boot technically as your privacy setup) and be aware of the impact on your analytics.
