Have Questions about iOS 14? Visit our Resource Center Have Questions about iOS 14? Visit our Resource Center

Kochava SDK Updates for iOS 14

By August 12, 2020August 26th, 2020Blog

Important decisions advertisers need to make.

The impending iOS 14 update has turned the industry on its side. Everyone inside the digital marketing arena has a growing list of questions. As we all work our way through this time of change, our SDK engineers have highlighted some key elements marketers should pay attention to when upgrading to our new SDK in order to continue to make the right decisions for their digital marketing efforts.

What is the biggest change?

Tracking Capabilities
With iOS 14, iPadOS 14, and tvOS 14, you will need to receive the user’s permission through the AppTrackingTransparency (ATT) framework in order to track the user or access their device’s identifier for advertising (IDFA). Tracking in this context refers to the act of linking a user or device data from your app with user or device data collected from other companies’ apps, websites, or offline properties, for targeting or advertising measurement purposes. Tracking also refers to sharing user or device data with data brokers. Apple’s new catch-all permission for any sort of user tracking is referred to as the AppTrackingTransparency framework, and IDFA collection in iOS 14 is subject to this permission.

What are the SDK implications?

IDFA Collection and Tracking Authorization Timing
As of iOS 14, the IDFA is gated behind the opt-in tracking authorization permission of Apple’s ATT framework. This means that a user must explicitly grant permission before the IDFA becomes available within the app. Apart from the larger ramifications of a permission-based IDFA, this is a significant change architecturally for any SDK that collects the IDFA because what was once an on-demand, synchronous collection is now asynchronous in nature.

To tackle this new collection requirement, our upcoming SDK release will provide the developer with much more granular control over the SDK’s startup behavior. This can be through setting a desired wait time in combination with a real-time authorization signal or by leveraging the SDK’s unique sleep functionality which already exists today.

IMPORTANT: It is highly recommended that you update your app before the launch of iOS 14 to optimize the timing of the ATT prompt and control the “permission requested” flag. This will enable you to curate the best user experience for higher opt-in rates. Keep in mind that the SDK will easily plug into your tracking authorization flow, and you can make those design decisions now independent of the SDK.

What are the biggest challenges with the Kochava SDK for iOS 14, and how does this affect my advertising efforts?

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 not only overcome this challenge but also provide a more deterministic and seamless deferred deep link experience than ever 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 very 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.

So, what are your options?

Option #1: Probabilistic attribution: SDK started immediately  
Recommended for most apps

Available today, in this typical scenario the SDK is started immediately upon app launch. As of iOS 14, the IDFA would 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:

  1. App launches
  2. Developer starts the SDK immediately, at which time the install signal egresses from the device without an IDFA
  3. Sometime in the future, the developer prompts for permission and the IDFA becomes available
  4. The SDK sends an updated payload with the IDFA
Option #2: Deterministic attribution: SDK started after permission

This option is available today. 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:

  1. App launches
  2. Sometime in the future, the developer prompts for permission and the IDFA becomes available
  3. Developer starts the SDK, and the SDK collects the IDFA
Option #3: Deterministic attribution with event queuing: Sleep SDK until after permission

This option is available today. 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:

  1. App launches
  2. On the first launch of the app, the developer starts the SDK but puts it to sleep, which prevents the IDFA from being collected
  3. Developer may queue events to be sent while the SDK is sleeping
  4. Sometime in the future, the developer prompts for permission
  5. Developer wakes the SDK, which allows the SDK to collect the IDFA
  6. The SDK begins sending any queued events
  7. On future launches, the developer does not put the SDK to sleep
Option #4: Deterministic/Probabilistic hybrid: SDK awaits tracking authorization

This option will be available in our upcoming SDK release. It will allow for the collection of the IDFA following a time-based wait interval or upon receipt of an update to the tracking authorization status.

How it works:

  1. App launches
  2. Developer starts the SDK with a set maximum wait interval
  3. SDK awaits tracking authorization prompt results
  4. Once tracking authorization results are known (or the wait interval is reached), the SDK will proceed with IDFA collection
  5. If the user ever changes their tracking authorization status, the SDK will send an updated IDFA accordingly

What about advertisers using a server-to-server integration?

Advertisers transmitting data server to server will need to add a new parameter within both install and event data payloads. The parameter key will be “ATT” and the value will need to be set to “0” or “1”. A value of “0” will indicate that the user has not consented to be tracked and the IDFA will not be available. A value of “1” will indicate that the user has consented to be tracked and the IDFA will be available.

If consent is not known when the install is sent to Kochava because the user has not been prompted, ATT should equal “0” until we are informed otherwise by an updated ATT flag on a post-install event.

Advertisers with a server-to-server integration who want to run with SKAdNetwork will need to manually integrate the SKAdNetwork framework and interpret the results on their end. Our upcoming SDK with iOS compatibility will be a much cleaner solution. Stay tuned for more updates on the timing and full scope of enablement on our iOS 14 resource center.

What level of support will the SDK update for iOS have with SKAdNetwork?

Aggregate level reporting, not viable for device-level attribution
SKAdNetwork provides a means to anonymously attribute an install to a given ad network. By design, SKAdNetwork only allows aggregate reporting of ad network performance. It is not possible to use SKAdNetwork to attribute an individual click to an install at the device level. For this reason, SKAdNetwork should not be thought of as a replacement for device-level or IDFA-based attribution.

Our upcoming SDK release is tightly integrated with SKAdNetwork and will handle all of the heavy lifting for you, requiring virtually no code changes.

How can Kochava help with SKAdNetwork reporting?

Kochava will provide two different reports for advertisers to analyze SKAd performance.

SKAd Install Summary
Once SKAd conversion postbacks have been received and validated, Kochava will generate a SKAd Install Summary report, which will include counts of SKAd installs by network and campaign next to a count of installs Kochava received and attributed to that same network and campaign. This will give advertisers insights into the directional accuracy of their real-time Kochava attribution in relation to latent SKAd attribution data.

SKAd Conversion Summary
The SKAd Conversion Summary report will provide insights into the quality of conversions by network and campaign. The report will include a breakdown of all conversions by conversion ID and the correlating conversion event within our dashboard. All conversion event mapping will be handled by Kochava server-side giving flexibility to the advertiser to update the conversion event mapping without any code changes or SDK updates required.

Are you ready for iOS 14?

Get the support and updates you need.

What about App Clips?

To learn more about App Clips and how the SDK will interact with them, read our detailed blog where we break down what an App Clip is, and how Kochava will facilitate attribution. 

Kochava SDK for iOS 14 and Swift Packages

In short, Apple’s Swift Packages allow for simpler and more seamless integration of our SDK as an XCFramework. While Swift Packages are not new to iOS 14, we will begin utilizing this as the distribution model for the SDK going forward.

iOS 14 and Apple silicon

Apple has been using its own proprietary silicon for its mobile devices for many years now. They are now moving away from Intel’s x86 processors to their own proprietary silicon for Macs, using the term “Apple silicon,” which describes a family of system-on-chips (SoCs) to be used in Apple’s soon-to-be-released line of Macs (including laptops and desktops and eventually all devices). While this won’t impact mobile devices directly, it will impact apps designed to be cross-platform and include mobile devices and newer Macs running on Apple silicon. Our updated SDK will support this new architecture.

When will iOS 14 be released?

Apple announced it would release the iOS 14 update in September but did not specify a date.

When will Kochava release the iOS 14 SDK?

A beta release of our iOS 14 SDK is currently scheduled for early September. A final production release is dependent on Apple’s iOS 14 release schedule and finalized Xcode documentation.

Is there an opportunity to wrap or curate the new permission collections?

No. While the developer chooses when to prompt, by design, Apple handles prompting the user for permission, and whether or not a prompt is displayed at all. The information displayed in the prompt is hard-coded into the app’s manifest when the app is built. It’s not something that can be changed in any way or provided from an external source.

Enable push functionality with your SDK update

Your next SDK update is the perfect time to enable the built-in push notification capabilities provided with Kochava Engagement. iOS 14 will mean IDFA scarcity and poses greater challenges to paid reengagement that relies on the IDFA for targeting. Push notifications rely on push tokens, not the IDFA, and are a great method to reengage your users to improve user retention and lifetime value (LTV). Push campaigns can be built around custom events, engagement funnel drop-off, and other dynamic trigger points. Deterministic uninstall tracking is also included. All push campaign performance can be visualized alongside your omni-channel media mix. Talk to your Client Success Manager about the benefits of Kochava Engagement and how you can add it to your plan.

Still have questions? Contact your Client Success Manager or fill out our contact form for more information.

Nathan Darst – Lead SDK Engineer
Kochava

Talk to an Expert

Required Fields*