Hierarchical IDs

Crowd Anonymity Tiers

Historically, Apple has not provided much information around the privacy threshold which determines the minimum amount of attributed volume which must be met before conversion values will be included in postbacks. With SKAN 4.0, Apple has finally defined three tiers of “crowd anonymity” based on attribution volume: low, medium, and high. With each tier, more granular data becomes available within the postback. Note that Apple still does not provide precisely what the thresholds are for each tier — only that with more attributed volume each tier is reached.

Source Identifier

SKAN 4.0 replaces the 2-digit campaign identifier field from the ad impression with a new 4-digit ‘source identifier’ field. This field should be thought of as a ‘conversion value’ equivalent for the ad impression, but should not be thought of in terms of bits, as each of the 4 digits becomes available as higher tiers of crowd anonymity are reached.

Similar to conversion values, these 4 digits could be used to represent different data. However, unlike conversion values, Apple obfuscates certain digits based on the level of crowd anonymity, which means each digit (not each bit) should represent something meaningful. Apple used the following model as an example:

Digit #4 = Ad placement bucket
Digit #3 = Date bucket
Digit #1,2 = Campaign ID

As you can see, like conversion values, models could be defined to interpret each digit differently per customer based on needs.

Coarse Value

SKAN 4.0 introduces a new value which is set along with the conversion value in the advertiser app named the ‘coarse value’. This coarse value can be set to one of three possible values (we’ll use “a”,”b”, and “c” in this blog) and is included in postbacks in place of the conversion value when the crowd anonymity tier restricts the conversion value. In other words, when the attribution volume is too low to allow the conversion value to be shared, the coarse value will be included in its place. Note that the coarse value and conversion value are mutually exclusive; the coarse value cannot be used in tandem with the conversion value in terms of the conversion model.

Example

How the tier of crowd anonymity impacts each hierarchical value in the postback:

As of SKAN 4.0, up to 3 postbacks are delivered and bucketed by time of conversion with a maximum window of 35 days since install. This is a great innovation! The time buckets are: 0-2 days, 3-7 days, and 8-35 days. In short, the last conversion to take place within a given time bucket is sent at the end of the window. This is a departure from the concept of the 24 hour timer, and it means:

• The SDK does not have to attempt to “keep the 24 hour window open” using valuable bits.
• It may no longer be necessary to allocate bits to time windows as the postback will reflect the time window, and the conversion value itself will only be available during the 0-2 day window.
  In the current implementation support for SKAdNetwork within Kochava, the Conversion Bit Modeler has been built to make up for current SKAdNetwork limitations and as a result – used valuable conversion bits. Using these new capabilities in 4.0 means that more bits can be used moving forward for optimization.

Install vs Re-engagement

Additionally, Apple stated the conversion value itself will only be available within the initial 0-2 day postback. The 3-7 and 8-35 day postbacks do not include the conversion value and instead include only the coarse value. Apple’s intent is that the 3+ day postbacks are used primarily for re-engagement. Interestingly, this suggests that the more granular conversion value is lost after the first 2 days with the trade off being that a coarse value is available up to 35 days later. It also may impact the landscape of conversion models if a conversion model is only good for day 0-2.

Note: It was mentioned that the conversion value may increase or decrease with SKAN 4.0, which suggests that the conversion value will not have to increase with each call. However, Apple did not elaborate on this.

Example

How the days since install will determine whether the coarse value or conversion value is included in the postback:

While this year’s WWDC announcements didn’t change the game as much as some had predicted, it’s clear that Apple and much of the industries are moving toward expanding privacy-first features. Kochava will support these new features to ensure that our customers don’t miss any opportunity to leverage and can maximize focus on growth.

It’s important for developers and UA managers to stay informed about these changes, so be sure to sign up for our newsletter, where we will discuss these developments and more from last year, this year, and many years to come.

This clearly leaves no ambiguity. Probabilistic and fingerprint methods of attribution that leverage IP address, device user agent, and other contextual device attributes in lieu of the IDFA are also prohibited in the absence of ATT opt-in. This means that paid media run on mobile web channels cannot be attributed by probabilistic or fingerprint methodologies if the user DOES NOT opt-in through your app’s ATT prompt. If a user DOES opt-in to ATT, then probabilistic or fingerprint methodologies can still be leveraged to attribute to media outside of an iOS app when IDFA wouldn’t be available from the source. 

Once again, owned media is an exception. Probabilistic and fingerprint methods of attribution are permitted when attributing user conversions to owned media run on mobile web channels since this would still be matching first-party data to other first-party data, and not that of another company. 

So, what will your attribution look like post-ATT enforcement? The answer depends on who your MMP is. 

How Kochava is approaching ATT

Collecting ATT status

To begin, Kochava is working with all media partners to pass ATT status on clicks and impressions coming from your marketing campaigns. 

For advertisers, Kochava has published an iOS SDK that supports seamlessly passing ATT status. Download our Native iOS SDK, or supported wrappers (Unity, Xamarin, Cordova, etc.) here. Documentation has also been published to support advertiser clients using our server-to-server (S2S) integration. View S2S support documentation here. 

Attribution eligibility based on ATT status

Once Apple begins enforcement of ATT, Kochava will start identifying advertiser and media partner traffic sent to Kochava iOS apps as consented (opt-in), non-consented (opt-out), or not subject to ATT (eg, mobile web). Traffic identified as non-consented will not be eligible for MMP attribution or any form of linking to another company’s data. SKAdNetwork will be the only form of attribution available for non-consented users. As discussed earlier in this document, owned media is the exception, since it’s comparing first-party data to other first-party data. 

The table below outlines attribution methods available based on a variety of ATT scenarios. Attribution eligibility will be dependent on the ATT status of the user in both the advertised app and the source where the ad interaction occurred (paid vs. owned media and in-app vs. mobile web). For Kochava to perform deterministic attribution on ATT opt-in users, please refer to our support documentation on configuring our SDK to handle your app’s ATT prompt timing.

Attribution hash

The Attribution hash was one of the first solutions proposed to mitigate the impact of ATT. The idea was to create a hash from the IDFA/IDFV on the demand side for both opt-in and opt-out users. The hash could then be used to attribute to ad signals of opt-in users. Unfortunately, this technique was not viable as it relied on the SDK accessing the IDFA without first obtaining the user’s ATT permission. In addition, hashed or not, the IDFA would still be sent off of the device, regardless of ATT permission status, and linked with another companies’ data, which Apple has clearly said is prohibited in instances where ATT opt-in is not present. In cases where ATT is applicable, consent must be obtained on both sides for attribution to occur. 

Aggregated attribution

Aggregated attribution seeks to take the IDFA and/or other user/device data, regardless of ATT permission status, and process attribution matching at the row-level, but then ONLY surface aggregated reporting to advertisers and their partners, not exposing the row-level/user-level data. It relies on the continued use of probabilistic attribution of users who have opted out of tracking. While the final output of data is aggregated and anonymous, the solution at its core still relies on sending user/device data off the device for linking with other companies’ data. This is out of alignment with Apple’s User Privacy and Data Use Policy, which is applicable not only to the app owner (advertisers, publishers) but any SDK activity within their app. MMPs are no exception from Apple’s point of view. 

Cross-customer identity graph

Cross-customer identity graphs work by linking device IDs, IP addresses, user agents, and browser cookies when they are available on an attributed click and install. By logging these connections, the MMP can reference it for attribution on another customer’s app where one or more of these attributes are missing, resulting in attribution that would otherwise not be possible. This can be thought of as a co-op among an MMP’s customers, where the benefit is an increased number of attributions and resulting insights. However, if this method is used for opt-out users, it is out of alignment with Apple’s User Privacy and Data Use policy due to the reliance on combining one app’s data with the data of not just one but many other companies.  

Why it matters which approach you choose

The following is an excerpt from Apple’s privacy policy Q&A: 

Q: “I have integrated an SDK from another company. Am I responsible for the data collection and tracking of users of my app by that company?”

A: “Yes. Developers are responsible for all code included in their apps. If you are unsure about the data collection and tracking practices of code used in your app that you didn’t write, we suggest contacting the developer of the SDK.”

This means you’re responsible for all data collection in your app, even the data collected by a third-party SDK, like that of Kochava and other mobile measurement providers (MMPs). You’re also responsible for how that data is used after it leaves the device. This is why Kochava is strictly adhering to both the letter and the spirit of Apple’s User Privacy and Data Use Policy. This ensures that our clients have absolute peace of mind that the data collected by our SDK and how it’s used (with ATT opt-in) or NOT used (with ATT opt-out) for advertising measurement purposes is 100% in alignment with Apple’s guidelines. 

As we look toward ATT enforcement in early spring, be sure you understand the approach your MMP is taking with ATT and how they intend to use the data collected from your apps. In the event that your MMP’s data use practices are considered to be in violation of Apple’s user privacy and data use policy, Apple reserves the right to remove your app from the App Store because of it. That’s why it’s vital to understand right now whether your MMP’s approach follows Apple’s policy.  

If you want to discuss the Kochava approach to Apple’s AppTrackingTransparency (ATT) framework, or other approaches in the space, we’re here to help. Contact us for a consultation on your ATT strategy. 

Vivian Watt – Product Manager
Kochava

Nathan Darst – Lead SDK Engineer
Kochava