Meaningful differences that exist in attribution between the web and app worlds. While it’s not always the case, a primary motivation of in-app advertising is app installs, and for the sake of this Lift Letter, we will discuss attribution for app installs. Overall, mobile app attribution is challenging but generally solved by third parties, including Kochava, Appsflyer, Tune, and Adjust.
On the web, when a user sees an ad, a third-party attribution pixel is generally dropped. This tells a third party that a particular ad was shown to the user. When a user clicks, the attribution company sees the click, and can tie it to the user through the cookie that it has for the user. Finally, when the user converts, another pixel is sent to the attribution company. The attribution company looks at all the ads that were shown to that user (for that campaign), all the clicks, and the conversion event, and applies some algorithm to determine which vendor or vendors get credit for driving the conversion. This is possible because the conversion attribution company has visibility through the entire chain of events.
The major difference in mobile app is that the installation of the app itself - the event for which the attribution would be given - does not always provide attribution heuristics. This is because both Apple and Google block at least some third-party attribution from happening directly in their app stores. So if ad vendor X shows an ad to user U1, the user clicks on the ad and then installs the app, the install itself won’t drop a conversion pixel. Thus there needs to be some way to tie U1 to vendor X, to the installation of the app when it is subsequently opened.
Android, as is typically the case, is slightly easier for the advertiser from an attribution perspective. Specifically, Android allows a referrer URL parameter to be included in download links. This information is fed via the Google Analytics SDK as a tracking id, which may be passed to a third-party attribution provider upon the app’s first open - but clearly only applies to click-based attribution. On Apple, no information makes it past the App Store. Amazon has an app store as well, and it functions similarly to Apple’s in that no information may pass through the download. In every event, more sophisticated (non-last-click) attribution models, or any attribution generally - in the case of Apple or Amazon - requires some attribution technology. There are three main concepts that are employed, which are discussed below:
Unique Identifier Matching - this is probably the most straightforward methodology. When the user clicks on an ad, or otherwise is exposed to that ad, information that includes that user’s mobile device ID (e.g. the device’s advertising ID) is sent to the attribution provider, along with some information about whether it’s an impression or a click. When the user installs the app and opens it, that same mobile device ID is sent to the attribution provider. The various IDs preceding the install are analyzed and the vendors are given attribution based on the attribution company’s methodology.
Fingerprint Matching - this is a non-deterministic method where device characteristics are sent instead of the device ID above. Information such as the IP address, location, HTTP headers, and more are included when the ads are clicked. These are then sent again when the installed app is first opened, which would allow the attribution company to match the device to the best degree possible. When Unique Identifier Matching is available, it is always preferred because it is deterministic whereas this is probabilistic.
Open URL on Click ID - some ads are for re-engagement, rather than install. In these events, for both app-to-app and web-to-app events, the app is opened through a “deep link,” which is a URL that works internally to the device and opens an app with parameters included. One such parameter can be a tracking ID - parameters are allowed to be passed on both Android and Apple for deep links. Like Unique Identifier Matching, the tracking ID can be measured. When the app is opened and compared to provide proper attribution.
Some of the complexity from the above derives from the fact that IFA, for example, is generally only available to in-app advertising, but many app-install ads are in a mobile web context. This requires some form of fingerprint matching (though Google Play could support an install referrer, Apple and Amazon will not). Thus post-install, some apps may open a background browser window to access potential fingerprint information to send back to the attribution company.
When doing mobile ad app-install buying, the DSP itself has no real insight into the conversion events. Only the conversion attribution company is installed in the app that is buying the ads (to buy installs). Thus the information about the installations must make its way back into the DSP through an offline process, after the conversion attribution has happened, to enable the DSP to optimize. This is a fairly different process than web, where the DSP can have its own pixel dropped on a conversion event, and use some adjustment factor for conversions it doesn’t get credit for - in app, it can’t see any conversions.