Kochava has a robust solution for customers using third party data platforms who wish to utilize Apple’s SKAdNetwork. Kochava has designed both the SDK and Server-to-Server integration to provide seamless SKAd conversion event eligibility against your SKAd conversion models created in the Kochava UI.
With their updated AppTrackingTransparency framework, Apple is giving users more visibility and power to decide whether or not they are tracked by the iOS apps on their devices. Apple ingests ad signals and conversion signals and combines that with their visibility of all IDFAs (accessible to them regardless of consent) and report back anonymized deterministic attribution data. SKAdNetwork v2.0, released with iOS14 (Sept 2020), relies on functions integrated into the source app where the ad is being displayed by an ad network, as well as the advertised app being promoted in the ad. The ad network itself must also play a role in signing ads and receiving install notifications when their ads result in campaign conversions. This means that the ad network, source app, and advertised app must play their part for the process to work end-to-end. Kochava’s iOS SDK allows an event to be instrumented through the SDK, which is then processed against Kochava’s SKAd conversion models, but will not egress from the device. This allows the user to send their S2S event (if applicable), but also create a copy in the form of an SDK event which may trigger any applicable conversion updates without actually sending the event from the SDK.
NOTE: If you are using the mParticle SDK 8.1.0 or higher, the following is unnecessary. All activity is shared client-side between our SDKs and sent to us, by us, negating the need for this redundant event code.
- Only the event_name and event_data fields are relevant to the Kochava SDK event. All other fields can be ignored, as they are not considered for SKAd conversion updates.
Please review how to create Kochava SDK events within our support documentation under Using the SDK :: Tracking Events.
Once you understand the basics of creating a Kochava SDK event, proceed with the following steps:
- Create a custom SDK event and set a custom name event_name value.
- For each top-level event_data value in your event, set a corresponding value in the SDK event’s infoDictionary.
- Set the SDK event’s serviceLocallyBool flag to true to indicate the event should be processed locally for SKAd conversion update consideration and should not egress from the device.
- Instruct the SDK that the event is ready to be processed and sent.
SDK Event Example:
// 1. create a custom event matching the S2S event_name let event = KVAEvent(customWithNameString: "eCommerce - Purchase") // 2. set equivalent top-level values from the S2S event_data event.infoDictionary = [ "action": "purchase", "transaction_id": "2382227875", "revenue": 0.99 ] // 3. indicate this event should not egress from the device event.serviceLocallyBool = true // 4. instruct the sdk to process the event event.send()
By doing so, the relevant event data from your S2S event will be considered for SKAd conversion eligibility against your SKAd conversion models created in the Kochava UI.
If an event is eligible, the SDK will automatically trigger the appropriate SKAd conversion update value from the device (you do not need to worry about the value in code).
- Always set the SDK event “serviceLocallyBool” to true, or else duplicate events will be received by Kochava.
- Developer creates and sends their S2S event data (just as they do today).
Relevant event data from your S2S event will be considered for SKAd conversion eligibility against your SKAd conversion models created in the Kochava UI.
- Always use the same keys, values, and data types from your S2S “event_data” in the SDK event.
- Omit any values from your S2S’s “event_data” which are not relevant to your SKAd conversion models.
- Omit any values from your S2S’s “event_data” which are nested objects or arrays, as they will not be considered for SKAd conversion.