Feature Summary: This document describes the recommended approach to integrate with the Kochava system to track post-install events. It is important to follow these API instructions in order to avoid data corruption and maximize the effectiveness of Kochava in your environment.

 

NOTE: For examples of post-install events, refer to our Post-Install Event Examples support documentation.

 

BEST PRACTICES: If strict authentication rules are being utilized, ensure that the procedures and policies within the Kochava Install Authentication Integration support documentation have been followed.

 

iOS14+ Event Tracking:

With iOS14 Apple introduced the App Tracking Transparency framework, requiring that all apps prompt their users for consent to be tracked. If consent is not granted, the IDFA will not available. Kochava will respect the ATT framework by collecting the end users app_tracking_transparency response and timestamp of the response with our native iOS14 SDK.

Server to Server clients will need to include the indicated key-value pairs on all event payloads for any events coming from OS version iOS14 or higher.

 

WARNING: If the app_tracking_transparency flag is not sent on events for these users, Kochava will assume that consent was not granted, and we will drop the IDFA server side.

---

Install and Startup Tracking

To track the installation and startup of your application, please refer to the Server-to-Server Install Notification Integration Guide. Once Kochava has registered an install for a device, features can be tracked via server-to-server API according to the specifications provided here.

---

Post-Install Event API

To send a usage event from your application, call the following endpoint with a POST payload containing the desired JSON elements.

http://control.kochava.com/track/json

 

WARNING: Advertisers using a Server-to-Server integration should format payloads so that Kochava can parse the OS version, either by sending the full User Agent string or sending the device_ver in accordance with our support documentation.

 

WARNING: kochava_app_id, kochava_device_id, device_ids, action, origination_ip, device_ver, device_ua, and data keys MUST be included on post-install event payloads. Otherwise, the post-install events will not be properly associated to the install, which has several implications, such as lack of attribution associated to the event and minimum time to reengagement windows not being applied.

 

NOTE: kochava_device_id can be sent as an empty string, as long as a device id is being sent and vice versa. device_ver can also be sent as an empty string. The parameters themselves indicated in the above table however, must be included in the post-install event payload.

 

BEST PRACTICES: Send the event data as a JSON object per the example below.

 

Sample Event Calls:

 

iOS14+ Sample Event Calls:

---

Device Specific Instructions

The information below details how to send data from specific devices to Kochava through the server-to-server integration.
 

---

Server-to-Server without Device UA

In scenarios where the device user agent is not able to be included on the install and event payloads, the device version can be sent instead, which will enable Kochava to manufacture a device user agent and perform fingerprint (IP + UA) attribution. (see iOS 14+ restrictions)

For more information Server-to-Server without Device UA, refer to our support documentation.

---

Update IDFA

For iOS (includes iPad) and tvOS apps, you can notify Kochava when an IDFA became newly accessible for a given device. An example scenario where this may happen is if you are not showing the AppTrackingTransparency (ATT) prompt upon install, which means the IDFA will not be available. Later, when the user is prompted, they grant permission to tracking, which makes the IDFA now accessible. At this point, you can send an Update action, which will cause Kochava to update the IDFA associated with the kochava device ID. Any subsequent post-install events will have the updated IDFA associated with them. If you do not send an Update action in this case, subsequent post-install events will not have an IDFA associated with them.

 

Sample Payload: