Get ready for the AppTrackingTransparency (ATT) framework and SKAdNetwork.
The Kochava beta SDK for iOS 14 is now available and offers a great opportunity for advertisers to work with their developers in preparation for the upcoming changes to their iOS apps.
Note to Developers: Apple’s Swift Packages allow for a simpler and more seamless integration of an SDK as an XCFramework. While Swift Packages are not new to iOS 14, Kochava will begin utilizing this as the distribution model for the iOS 14 SDK and future iterations.
Because this SDK release is a major update, it is integrated differently and some function names have changed. This will require some light lifting on your behalf. Support documentation features code examples for V3 and the new V4, allowing you to see the differences.
Key points for consideration
- IDFA collection flow in relation to the AppTrackingTransparency (ATT) framework
- SKAdNetwork readiness
- Support for App Clips
IDFA collection and the AppTrackingTransparency (ATT) framework
In prior versions of the Kochava iOS SDK, in order to gather Apple’s identifier for advertisers (IDFA) the SDK would ask the operating system (OS) for it. In the event that Limit Ad Tracking (LAT) was enabled, the IDFA was null, otherwise the IDFA was provided. This approach had virtually zero lag time, and the install was sent immediately with the provided IDFA. As of iOS 14, the SDK can no longer ask for the IDFA immediately but must wait for the user to first be prompted through the ATT framework.
The user’s response dictates whether the IDFA can be collected. This is similar to other permission-based collections, like location.
This new flow introduces several challenges which we surfaced in a previous blog post from our Lead SDK Engineer.
- Challenge #1: The Install
- Challenge #2: Attribution Results & Deferred Deep Linking
- Challenge #3: Click and Install IDFA Parity
Challenge #1: The Install
For the IDFA to be included within the install signal, the SDK must wait for both the developer to prompt the user for tracking authorization and for the user to answer that prompt (it is up to the developer to choose when to prompt the user). This means that install signal quality heavily depends on when the user is prompted for tracking authorization. Prompting too soon may result in significantly less tracking authorization while prompting too late may result in lower quality or latent install signal. Curating that experience for the user will be an important aspect of UX and design going forward.
Challenge #2: Attribution Results & Deferred Deep Linking
Attribution cannot take place until the install signal has been sent. On its own, delayed attribution is not an issue. However, it can pose significant challenges for those leveraging attribution results for time-sensitive deferred deep linking. Striking a balance between tracking authorization and timely deferred deep linking will be a challenge, but Apple’s new App Clips can be leveraged to overcome this challenge and also provide a more deterministic and seamless deferred deep link experience than before.
Challenge #3: Click and Install IDFA Parity
A significant and overarching issue with a permission-based IDFA is that tracking authorization parity between the click and install signal becomes hard to achieve. While a user may authorize tracking within an app serving an advertisement, the same user may not also authorize tracking in the app for which the advertisement was targeted. This can result in a click which contains an IDFA and install signal which does not or vice versa.
We encourage advertisers and their developers to carefully consider the best approach to handling the timing of ATT prompting and sending of the install. Here are four different options you can choose from.
Option 1 is now available with the beta SDK, and will also be included in the upcoming production SDK to be released based on Apple’s launch timing for iOS 14. Options 2-4 do not require the new SDK.
- Option #1: Await tracking authorization
- Option #2: Start immediately
- Option #3: Start after permission
- Option #4: Queue events until after permission
Option #2: SDK started immediately
Available Attribution: Probabilistic ONLY
In this typical scenario the SDK is started immediately upon app launch. As of iOS 14, the IDFA will not be included in the install payload, but if and when tracking is authorized in the future, an updated IDFA will be sent.
How it works:
- App launches
- Developer starts the SDK immediately, at which time the install signal egresses from the device without an IDFA
- Sometime in the future, the developer prompts for permission and the IDFA becomes available
- The SDK sends an updated payload with the IDFA
Option #3: SDK started after permission
Available Attribution: Deterministic with IDFA opt-in. Probabilistic without IDFA opt-in.
In this scenario, the developer does not start the SDK until after permission is given. Once started, the SDK will send the install and proceed normally.
How it works:
- App launches
- Sometime in the future, the developer prompts for permission and the IDFA becomes available
- Developer starts the SDK, and the SDK collects the IDFA
Option #4: Event queuing – Sleep SDK until after permission
Available Attribution: Deterministic with IDFA opt-in. Probabilistic without IDFA opt-in.
In this scenario, the SDK is started but is put to sleep which means events can queue, and the SDK can be used as if it had been started. However, the SDK will not proceed with the install until the developer wakes it up after the user grants or declines permission.
How it works:
- App launches
- On the first launch of the app, the developer starts the SDK but puts it to sleep, which prevents the IDFA from being collected
- Developer may queue events to be sent while the SDK is sleeping
- Sometime in the future, the developer prompts for permission
- Developer wakes the SDK, which allows the SDK to collect the IDFA
- The SDK begins sending any queued events
- On future launches, the developer does not put the SDK to sleep
SKAdNetwork readiness
The SDK for iOS 14 will handle all of the heavy lifting for SKAdNetwork on behalf of advertisers. There are no code changes required; developers will just need to include our AdNetwork SDK module in order to utilize the built-in SKAdNetwork functionality.
Action Item for Advertisers
To best take full advantage of the SKAd conversion models discussed in this blog post, now is the time to ensure that you’re tracking all of the in-app events and any revenue metrics that you would like to factor when configuring your conversion model.
For example, if you plan to leverage the User Journey conversion model, be sure you’re tracking key events down-funnel of the install. This will provide ample varieties of user journey event sequences, which can each include up to three events.
Update or add any needed events and metrics now, so you can maximize quality performance insights on your SKAdNetwork campaigns.
Support for App Clips
While you cannot yet register App Clips with the App Store, it’s important to call out how Kochava will support them. No separate SDK version will be required for App Clips. You can leverage the same SDK in both your full app and App Clip.
Two additional steps will be required when configuring App Clips with Kochava.
- Use separate Kochava app GUIDs for the app clip and full app.
- The App Clip and full app should not use the same Kochava app GUID. For an App Clip, you will need to create a separate app profile in your Kochava account with the platform type set to “iOS – App Clip.” That app GUID should be passed to the SDK during configuration of your App Clip. Your full iOS app should be a separate app profile with the platform type set to “iOS.” That is the app GUID to pass to the SDK during configuration of your full app.
- Pass the App Clip’s invocation URL to the SDK’s Process Deep Link API.
- When the App Clip is launched via a Universal Link invocation URL, pass this URL to the SDK’s existing Process Deep Link API as soon as possible, just as you would any other deep link. For complete instructions on how to use the Process Deep Link API, see this support documentation.
Stay up to date on the latest information on iOS 14 and Kochava. Visit our iOS 14 Resource Center.
If you have questions regarding, please contact your Client Success Manager or email Support@Kochava.com.
Nathan Darst – Lead SDK Engineer
Kochava
