Granular attribution compatible with iOS 14

This blog post was updated on 29th July 2020 to include more detail on how Adjust will be supporting clients and partners post iOS 14, other possible scenarios for a reliable on-device solution, and our stance on the Attribution Hash.

As outlined in our last blog post, Adjust has been extensively researching options to provide accurate and granular attribution under the new proposed rules that will be introduced on iOS 14.

Adjust will support our clients and partners using three different methods:

• Opt-in deterministic attribution using the AppTrackingTransparency framework
• Probabilistic measurement fueled by several non-deterministic signals
• SKAdNetwork as an additional set of data

Our attribution solution is fully compliant with Apple’s guidelines even for users who do not opt-in. However, regardless of attribution, we support and recommend app developers to implement a consent flow that leverages the AppTrackingTransparency framework Apple introduced at WWDC2020 in their app to gain a competitive advantage, both on the supply and demand side.

This post presents the research we have been conducting, specifically around a proposed solution we call the “Attribution Hash”. With this blog, we want to initiate discussions and collect feedback about what device attribution could be. Its long-term purpose is to prompt Apple to validate a reliable on-device solution that the industry can leverage while respecting Apple’s guidelines.

We believe that Apple should be the only party controlling device IDs, as well as the API for on-device attribution as per the definition of privacy on iOS14, and hope the solution will evolve into that direction.

Below are the necessary steps from respective players in the ecosystem.

First off, let’s begin with the ad publishers. This includes every app, from social media to games, that generates its revenue from ads and the ad networks they use to monetize.

If app users themselves must actively decide to share their IDFA under iOS 14, then it will now be on the app publishers to demonstrate the value or benefit they can provide to consumers. Apple has not prescribed any limitations on how to communicate this value exchange with users, which opens up new opportunities.

App publishers could, for example, offer users the choice between a free, ad-supported version, and a paid, ad-free version of their app.

Social media apps could simply make it part of their terms and conditions that a user would allow them to show ads and share the IDFA, in order to fully use the app.

In the end, as long as the demand exists, supply will be incentivized to innovate. Publishers who can prove the value of their apps will gather more user consent - and these publishers will be rewarded with more valuable inventory.

We believe this basic economic principle will drive the supply side.

The biggest challenge of providing IDFA-based attribution under iOS 14 is that you would need the IDFA for every device that installs an advertiser’s app, as soon as the app opens.

There is no logical way to get the users’ permission this early on, especially for apps that don’t even show ads and monetize instead through subscriptions and in-app purchases.

This is the central problem and one of the main reasons why some in the industry have proclaimed it as the “death of the IDFA”.

But Apple has outlined one crucial exception in its App Tracking Transparency (ATT) framework.

The idea is fairly simple: once opened, the advertiser's app reads the IDFA and the IDFV.

It then calculates a SHA256 (Secure Hash) of the IDFA and IDFV to something we will call the “attribution hash”.

For example if the IDFA is 236A005B-700F-4889-B9CE-999EAB2B605D and the IDFV is C305F2DB-56FC-404F-B6C1-BC52E0B680D8, then the attribution hash becomes a5a884a5dd3758ae7f0d333f56933df76d4a609a77e54ecc5db51ac8651fb5658.

So what is the nature of this hash?

First off, let’s refresh what a hash is. Simply put, it is a one-way function that always produces the same output for a certain input but does not allow to reverse the output back to the input. This video shares a simple explanation of what hashing is, and how it works.

The input of the attribution hash inherits the nature of the most volatile input. This means our hash is going to behave a lot like the IDFV: it will never be the same between two different apps on the same device, unless they are from the same app publisher, just like the IDFV.

This, in turn, means you cannot use it to retarget or build a profile of a user across different apps. It also means that it is not a user or device identifier, just like the IDFV.

Now let’s imagine an MMP SDK takes this hash and the IDFV, and sends it to the MMPs backend.

No user or device identifier has left the device and the IDFA was only used locally to calculate the hash.

In order to attribute using this hash, an MMP would look at all the IDFAs they received from the supply side for ad engagements that might have driven this app activity. And remember - all those IDFAs were sent to the MMP with consent collected in the ad publishing app.

The MMP then calculates all the SHA256 hashes of each potential matching IDFA and IDFV it received. If one of those hashes equals the attribution hash of the device, you have an exact match - and can attribute almost as you would match IDFAs today.

The beauty of this solution is that even the combination of IDFV and attribution hash does not allow you to reverse the IDFA without already knowing it. Unless you have received a user-approved IDFA, there is no way you can do anything with the attribution hash.

Due to its limited nature, the attribution hash would only be used internally by MMPs.

Given access to the IDFA on the supply side, Adjust proposes to use a hash of IDFA and IDFV (or any other random salt), calculated locally in the demand-side app, to be used for attribution. This means there is no need for user permission to transfer IDFA off the device, solving the demand-side consent problem.

This Attribution Hash has several advantages:

• Privacy: No device or user ID is sent from the device and the IDFA is acquired with consent, in accordance with Apple’s new regulations.
• Transparency: For those responsible for technical implementation across the industry, this solution is easily understandable and communicated.
• Accuracy: This method provides the same level of matching as pure IDFA matching. In some cases, it may even provide a better level considering Apple has deprecated LAT, and reading the IDFA in the advertiser app will always work.
• Security: It is impossible to brute force the IDFA, even when knowing half the input of the hash.
• Simplicity: This solution will only require minor changes to MMPs SDKs. All MMPs should be able to adapt their backend for this type of matching without investing significant resources.

There are other possible scenarios for on-device:

• An analog to the Google Referrer on Android: it could even require supply-side consent where only if the user opts into tracking on the supply side, the demand side app receives a delegate callback upon installation that our SDK can read. The payload could be a click ID (our internal Adjust reftag for example), the campaign information or the IDFV from the source app.
• Matching IDs on the device itself: instead of the IDFAs going from the SDK to the Adjust servers, the servers would send all the IDFAs received on engagement to the SDK along with the click tracker, which is an aggregated datapoint. The SDK matches the IDFA and returns only the tracker.
• Attribution Hash generated by Apple: our SDK would not even read the IDFA, we would just receive the hash and salt from Apple.

Ultimately, the bottom line is that there are many solutions for on-device attribution that can be researched and investigated, and some of these could be made available as a part of upcoming SKAdNetwork enhancements.

We are in constant communication with Apple, app developers, and marketing partners to find a solution that can push the industry forward without compromising on user privacy.

If you would like to join us or learn more about how to support, please reach out to ios14@adjust.com. We are very happy to share insights and hear feedback from the industry!