Granular attribution compatible with iOS 14: 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.

Today, we’re excited to announce our iOS 14 compatible and compliant solution, the “Attribution Hash”. We strongly support Apple's idea of gaining explicit user consent to access users’ data and show them targeted ads, so our approach will require users to agree to access their IDFA for measurable ad engagements inside the ad publishing app. But our solution also allows for the same level of measurement our customers have previously required to conduct their business while following the new requirements set forth by Apple.

We are happy to share the details of this approach and hope to gather collective support from our partners and other MMPs to make the solution an industry standard - you’ll find details on how to join us at the end of the post.

Below, we’ve outlined the necessary steps each player in the ecosystem will need to take to make this a reality.

The Supply Side

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 Demand 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 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 AppTrackingTransparency framework.

So how do you attribute an install or re-engagement without sending data off the device that can identify the user or device?

We’ve come up with a possible solution: the Attribution Hash.

The Technical Details of the Attribution Hash

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.

In summary

Given access to the IDFA on the supply side, Adjust proposes to use a hash of IDFA and IDFV, 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.

We are excited to share this innovation with the market and welcome anyone to join us in making this the future standard for mobile app attribution.

We will be seeking approval from Apple to test this solution in the coming days and aim to have it market-ready by the launch of iOS 14 in September.

If you would like to join us or learn more about how to support, please reach out to attributionhash@adjust.com.

As usual, we will keep you posted on the blog - more to come in the following weeks.