Confirming the SDK Integration:
Ensure the SDK has been properly integrated.
After integrating the SDK or creating a new App GUID, we suggest performing these tests to ensure the SDK has been integrated successfully and is functioning as expected within your app.
Validate the Install:
The SDK will send an install for the app once, after a fresh install. This test ensures the SDK was configured properly and successfully sent the install to Kochava.
- Double check the SDK configuration in code, ensuring the correct App GUID.
- Run the app for approximately 30 seconds, which will allow more than enough time for the SDK to start and send an install to Kochava under typical conditions.
- Wait a minute or two and visit the Install Feed Validation page for your app within the Kochava dashboard, under Apps & Assets > Install Feed Validation. Within that page, look for the Integration Success! message which indicates integration was successful and that Kochava did receive an install from the SDK. At this point you have confirmed a successful SDK integration and can move ahead to Validate Post Install Events below.
- If instead you see a Integration Not Complete! message, wait a few more minutes and refresh the page. After refreshing, if the Integration Not Complete! message persists, double check the following, then repeat this test:
- Correct App GUID is used within SDK code configuration.
- Ensure the SDK configuration and startup code is being reached.
- Ensure the network connection from the test device is not limited behind a firewall or otherwise.
Validate Event Tracking:
If you are tracking user events, you can use this test to ensure the SDK was configured properly and is successfully sending these events to Kochava.
- Double check the SDK configuration in code, ensuring the correct App GUID.
- Double check your event tracking code and ensure it is reachable.
- Launch the app and perform necessary actions within the app to trigger the event(s) you wish to test. After performing these actions, wait 60 seconds to allow more than enough time for the SDK to send these events.
- Wait a minute or two and visit the Event Manager page for your app within the Kochava dashboard, under Apps & Assets > Event Manager. Within that page, ensure the tested event names are displayed here, in which case you have confirmed the SDK is successfully tracking these events.
- If your event names are not displayed here after waiting a few minutes, double check the following, then repeat this test:
- Correct App GUID is used within SDK code configuration.
- Ensure the SDK configuration and startup code is being reached prior to any event code.
- Ensure the SDK event code is being reached.
- Ensure the network connection from the test device is not limited behind a firewall or otherwise.
Supporting SKAdNetwork:
Kochava’s SKAdNetwork support is seamlessly integrated with standard event tracking.
NOTE: This feature is applicable to iOS platforms only.
No special code is needed to support SKAdNetwork, beyond tracking your existing events which are eligible for conversion. However, events which are to be considered for SKAdNetwork conversion updates must be built using standard parameters, rather than using an existing serialized/stringified json object for event data. See the topic “Tracking Events” for more detail on using standard parameters.
After setting up SKAdNetwork in your Kochava dashboard, the SDK will automatically:
- Call Apple’s SKAdNetwork registration at the first opportunity following launch.
- When an eligible conversion event is triggered on iOS 14, the SDK will calculate the appropriate conversion value based on the event’s properties and automatically call Apple’s SKAdNetwork conversion update.
Subscribe to SDK Notifications:
Optionally, you may subscribe to notifications triggered when the SDK calls Apple’s registerAppForAdNetworkAttribution() and updateConversionValue() API. Subscribing to these notifications is NOT required, and is necessary only if you wish to do something with the latest conversion value or understand the timing of these calls.
NOTE: Requires Unity SDK version 4.3.2 or higher.
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 |
// Subscribe to all Kochava Platform Events including SKAdNetwork events. // Subscribe as early as possible during the Awake phase to avoid missing any events. Kochava.Tracker.SetPlatformEventHandler(KochavaPlatformEvent); // Subscribed Method public void KochavaPlatformEvent(Kochava.PlatformEvent platformEvent) { // conversionDidUpdateValueBlock if(platformEvent.name == "adNetworkConversionDidUpdateValue") { Debug.Log("updateConversionValue called with a value of " + platformEvent.value["value_int"]); } // didRegisterAppForAttributionBlock if(platformEvent.name == "adNetworkDidRegisterAppForAttribution") { Debug.Log("registerAppForAdNetworkAttribution"); } } |
Generating SKAdNetwork Postbacks:
While the SDK automatically makes the necessary Apple API calls for you, a SKAdNetwork postback will only be generated if requirements are met for both the source app and advertised app. The advertised app must have been reviewed and available for download in the App Store, while the source app (where the ad is displayed) can be one that you are currently developing and run from Xcode or through TestFlight. Be sure to use the correct SKStoreProductParameterAdNetworkSourceAppStoreIdentifier per your case.
For testing purposes, you can cut down on the 24 hour postback wait by using the “SKAdNetwork Profile” from the Apple developer console here: https://developer.apple.com/download/more/ (search for “skad”).
For more information ensuring that your SKAdNetwork conversion model will produce the results you expect, refer to our Confirming the SKAdNetwork Conversion Model support documentation.
AppTrackingTransparency and IDFA Collection:
Method for handling Apple’s new IDFA collection model.
NOTE: This feature is applicable to iOS platforms only.
As of iOS 14, IDFA collection is gated behind Apple’s new AppTrackingTransparency (ATT) permission-based authorization. This means that when an app is running on iOS 14, the IDFA is not available for collection until after the user grants permission, similar to any other iOS permission-based collection. However, Apple is delaying enforcement of ATT, which is discussed below.
About ATT Non-Enforcement
In order to allow developers more time to adjust to the changes surrounding IDFA collection, Apple announced that tracking authorization via the ATT framework would not be required to collect the IDFA on iOS 14, until at least 2021. The IDFA will continue to be available for collection on iOS 14 no differently than it was on iOS 13 and prior. However, once an ATT request for authorization is made, IDFA availability then becomes subject to the results of tracking authorization from that point on. This means that you must decide whether to start prompting users for tracking authorization now or wait for Apple to provide a concrete timeline on when they will begin requiring tracking authorization at some time in the future.
If you do not yet wish to prompt the user for tracking authorization and enforce ATT, you do not need to take any additional steps and the SDK will continue to gather the IDFA until Apple begins requiring tracking authorization sometime in 2021.
If you wish to enforce ATT and begin prompting users for tracking authorization, continue reading below.
Enforcing ATT for IDFA Collection
The SDK makes this very simple for you. All you need to do is tell the SDK you want to enable ATT enforcement during configuration.
As a tracking requirement by Apple, you must include in your info.plist the key NSUserTrackingUsageDescription and a string value explaining why you are requesting authorization to track. This text will be included in the prompt displayed by the operating system when tracking authorization is requested.
Configure the SDK
During SDK configuration, tell the SDK you wish to enable ATT enforcement. By default, the user will be prompted for tracking authorization one time, upon launch, and the SDK will allow up to 30 seconds for the user to answer the tracking authorization prompt. You may adjust this behavior if you wish.
Example Enabling ATT with default settings (recommended):
-
123Kochava.Tracker.Config.SetAppTrackingTransparency(true, 30, true);Kochava.Tracker.Config.SetAppGuid("YOUR_APP_GUID");Kochava.Tracker.Initialize();
Example Allow more than the default 30 seconds for the user to respond:
-
123Kochava.Tracker.Config.SetAppTrackingTransparency(true, 90, true);Kochava.Tracker.Config.SetAppGuid("YOUR_APP_GUID");Kochava.Tracker.Initialize();
At this point you are done. The user will be prompted for tracking authorization one time, during the first launch of the app, and the IDFA will be gathered if authorization is granted.
For purposes of testing, you will need to uninstall and reinstall the app each time you wish for the tracking prompt to appear, as Apple will only allow this to be displayed once.
Optionally, if you wish to prompt the user for tracking authorization at a specific moment or you do not want the SDK to trigger the prompt, continue reading below.
Custom Prompt Timing (Optional)
Follow these steps only if you wish for the tracking authorization prompt to be displayed at a time other than when the app is first launched or you do not want the SDK to trigger the prompt.
In order to accomplish this, first configure the SDK so that it does not automatically request authorization and allows enough time for the user to reach the point where tracking authorization will be requested at the moment of your choosing. In this example, we are allowing up to 120 seconds for the user to provide an answer to the tracking authorization request.
Example Configure the SDK:
-
123Kochava.Tracker.Config.SetAppTrackingTransparency(true, 120, false);Kochava.Tracker.Config.SetAppGuid("YOUR_APP_GUID");Kochava.Tracker.Initialize();
Secondly, add code which requests the tracking authorization at the time of your choosing and then notifies the SDK when the authorization request completes. It is your responsibility to ensure your tracking authorization request code is reached. If it is not, the timeout will be reached and the SDK will proceed without collecting the IDFA.
NOTE: Regardless of how many times you request tracking authorization, the user is only prompted once. This means you can repeatedly request tracking authorization at a specific moment per app launch and the user will only be prompted once, the first time the code is reached.
Example Request authorization and notify the SDK upon completion:
|
1 2 |
// notify the Kochava SDK that it may proceed with tracking authorization Kochava.Tracker.EnableAppTrackingTransparencyAutoRequest(); |
Tracking Events:
Track user behavior and actions beyond the install.
Examples include in-app purchases, level completions, or other noteworthy user activity you wish to track. Events can be instrumented either by using the standard format provided by the SDK or using your own custom event name and data.
Standard Events:
Standard events are built by first selecting a standard event type and then setting any applicable standard parameters you wish to include with the event. For example, you might choose a Purchase standard event type and set values for the Price and Name parameters. There are a variety of standard event types to choose from and dozens of standard parameters available. When creating a standard event, you only need to set values for the parameters you wish to track. A maximum of 16 parameters can be set.
- Create an event object using the desired standard event type.
- Set the desired parameter value(s) within the event object.
- Pass the event object to the tracker’s Send Event method.
Example (Standard Event with Standard Parameters) —
|
1 2 3 4 |
Kochava.Event myEvent = new Kochava.Event (Kochava.EventType.Purchase); myEvent.name = "Gold Token"; myEvent.price = 0.99; Kochava.Tracker.SendEvent (myEvent); |
Custom event parameters (which can also be serialized JSON) may also be set within a standard event.
Example (Standard Event with Standard and Custom Parameters) —
|
1 2 3 4 5 |
Kochava.Event myEvent = new Kochava.Event (Kochava.EventType.LevelComplete); myEvent.name = "The Deep Dark Forest"; myEvent.SetCustomValue ("attempts", 3); myEvent.SetCustomValue ("score", 12000); Kochava.Tracker.SendEvent (myEvent); |
For a detailed list of standard event types and parameters, see: Post Install Event Examples
Custom Events:
For scenarios where the standard event types and standard parameters do not meet your needs, custom events can be used. To instrument a custom event, pass the event’s name and data (which can also be serialized JSON) to the tracker’s Send Event method.
Example (Custom Event with Custom Parameters) —
|
1 2 3 4 |
Kochava.Event myEvent = new Kochava.Event ("Enemy Defeated"); myEvent.SetCustomValue ("enemy", "The Angry Ogre"); myEvent.SetCustomValue ("reward", "Gold Token"); Kochava.Tracker.SendEvent (myEvent); |
Example (Send a Custom Event with Only a Name, no Event Data) —
|
1 |
Kochava.Tracker.SendEvent ("Player Defeated"); |
Example (Send a Custom Event with Event Data) —
|
1 |
Kochava.Tracker.SendEvent ("Player Defeated", "Angry Ogre"); |
Example (Send a Custom Event with Serialized JSON Data) —
|
1 |
Kochava.Tracker.SendEvent ("Player Defeated", "{\"enemy\":\"Angry Ogre\"}"); |
NOTE: No custom event name pre-registration is required. However, a maximum of 100 unique event names can be tracked within the Kochava dashboard (including any standard event types also used), so keep this in mind as you create new custom event names.
Developer API Reference:
Kochava.Tracker.SendEvent(String)
Kochava.Tracker.SendEvent(String, String)
Kochava.Tracker.SendEvent(Kochava.Event)
Kochava.Event
Purchases:
Track in-app purchases and revenue.
In-app purchases and subscription can be easily tracked and attributed by creating a purchase event. To accomplish this, simply create an event of type Purchase and include the total amount of revenue as the price value within the event data parameters.
Purchases:
Example (Standard Purchase Event) —
-
12345Kochava.Event myEvent = new Kochava.Event (Kochava.EventType.Purchase);myEvent.price = 4.99;myEvent.name = "Loot Box";myEvent.setReceiptFromGooglePlayStore (receiptOriginalJson, receiptSignature);Kochava.Tracker.SendEvent (myEvent);
-
12345Kochava.Event myEvent = new Kochava.Event (Kochava.EventType.Purchase);myEvent.price = 4.99;myEvent.name = "Loot Box";myEvent.setReceiptFromAppleAppStoreBase64EncodedString (receiptBase64EncodedString);Kochava.Tracker.SendEvent (myEvent);
-
1234Kochava.Event myEvent = new Kochava.Event (Kochava.EventType.Purchase);myEvent.price = 4.99;myEvent.name = "Loot Box";Kochava.Tracker.SendEvent (myEvent);
Example (Custom Purchase Event with Serialized JSON Data) —
|
1 |
Kochava.Tracker.SendEvent ("Purchase", "{\"price\":4.99,\"name\":\"Loot Box\"}"); |
Developer API Reference:
Tracker.sendEvent(String, String)
Tracker.sendEvent(Event)
Tracker.Event
Tracking Subscriptions and Trials:
Track user subscriptions and free trials.
In order to effectively track user subscriptions and free trials, an event should be instrumented at the time of the subscription purchase or start of the free trial along with an accompanying identity link.
When a subscription or free trial begins, first set an identity link for this subscriber and then instrument a standard Subscription or Trial event populated with the following values:
- Price
- Currency
- Product Name
- User or Subscriber ID (hash suggested)
- Receipt (if available)
Example (Identity Link with Subscription):
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 |
// first set an identity link for this user Dictionary<string, string> identityLink = new Dictionary<string, string> (); identityLink.Add ("Subscriber ID","ABCDEF123456789"); Kochava.Tracker.SetIdentityLink (identityLink); // next, instrument the subscription event Kochava.Event myEvent = new Kochava.Event (Kochava.EventType.Subscribe); myEvent.price = 9.99; myEvent.currency = "usd"; myEvent.name = "Monthly Subscription"; myEvent.userId = "ABCDEF123456789"; myEvent.setReceiptFromGooglePlayStore (receiptOriginalJson, receiptSignature); // Android Only myEvent.setReceiptFromAppleAppStoreBase64EncodedString (receiptBase64EncodedString); // iOS Only Kochava.Tracker.SendEvent (myEvent); |
A free trial is handled in a similar way, although the price should be set to 0 and the event type should indicate Trial rather than Subscription. The product name should remain the same, as the event type indicates whether this was free trial or subscription.
Example (Identity Link with Free Trial):
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 |
// first set an identity link for this user Dictionary<string, string> identityLink = new Dictionary<string, string> (); identityLink.Add ("Subscriber ID","ABCDEF123456789"); Kochava.Tracker.SetIdentityLink (identityLink); // next, instrument the trial event Kochava.Event myEvent = new Kochava.Event (Kochava.EventType.StartTrial); myEvent.price = 0.0; myEvent.currency = "usd"; myEvent.name = "Monthly Subscription"; myEvent.userId = "ABCDEF123456789"; myEvent.setReceiptFromGooglePlayStore (receiptOriginalJson, receiptSignature); // Android Only myEvent.setReceiptFromAppleAppStoreBase64EncodedString (receiptBase64EncodedString); // iOS Only Kochava.Tracker.SendEvent (myEvent); |
Deeplinking:
Track deeplink related actions and user activity.
Tracking deeplinks is accomplished similar to any other type of event. In order to track a deeplink event, create a standard event of type Deeplink and set the uri parameter along with any other relevant parameters to the values provided when the deeplink occurred.
Example (Standard Deeplink Event):
|
1 2 3 4 |
Kochava.Event myEvent = new Kochava.Event (Kochava.EventType.DeepLink); myEvent.uri = "some_deeplink_uri"; myEvent.source = "some_source_application"; Kochava.Tracker.SendEvent (myEvent); |
Example (Custom Deeplink Event with Serialized JSON Data):
|
1 |
Kochava.Tracker.SendEvent ("_Deeplink", "{\"uri\":\"some_deeplink_uri\"}"); |
Developer API Reference:
Kochava.Tracker.SendEvent(String, String)
Kochava.Tracker.SendEvent(Kochava.Event)
Kochava.Event
Enhanced Deeplinking:
Enhanced deeplink actions.
Example (Acquire the Deeplink):
|
1 2 3 |
// acquire a deeplink whenever one is available and pass it to the SDK. string deeplinkUrl = "todo"; Kochava.Tracker.ProcessDeeplink(deeplinkUrl, DeeplinkProcessed); |
Example (Wait for the Callback):
|
1 2 3 4 5 6 7 |
public void DeeplinkProcessed(Kochava.Deeplink deeplink) { if(!string.IsNullOrEmpty(deeplink.destination)) { // deeplink exists, parse the destination as you see fit and route the user } else { // no deeplink to act upon, route to a default destination or take no action } } |
Developer API Reference:
Kochava.Tracker.ProcessDeeplink(string, Action
Kochava.Tracker.ProcessDeeplink(string, double, Action
Kochava.Deeplink
Identity Linking:
Link existing user identities with kochava devices.
Setting an Identity Link provides the opportunity to link different identities together in the form of key and value pairs. For example, you may have assigned each user of your app an internal ID which you want to connect to a user’s service identifier. Using this feature, you can send both your internal ID and their service identifier to connect them in the Kochava database.
In order to link identities, you will need to pass this identity link information in the form of unique key and value pairs to the tracker as early as possible. This can be done during tracker configuration if the identity link information is already known, or it can be done after starting the tracker using the Set Identity Link method.
Example (Set an Identity Link During Tracker Configuration):
|
1 2 3 4 5 6 7 8 |
// An Identity Link cannot be set in the configuration object. Instead it must be set directly after starting the Kochava SDK. // This can be done during the Start lifecycle stage // or during the Awake lifecycle stage if the KochavaConfiguration.cs occurs first in the Script Execution Order list. Dictionary<string, string> identityLink = new Dictionary<string, string> (); identityLink.Add ("User ID","123456789"); identityLink.Add ("Login","username"); Kochava.Tracker.SetIdentityLink (identityLink); |
Example (Set an Identity Link After Starting the Tracker):
|
1 2 3 4 |
Dictionary<string, string> identityLink = new Dictionary<string, string> (); identityLink.Add ("User ID","123456789"); identityLink.Add ("Login","username"); Kochava.Tracker.SetIdentityLink (identityLink); |
Developer API Reference:
Kochava.Tracker.SetIdentityLink(Dictionary
Retrieving Attribution:
Access the attribution results within the app.
Install attribution results can be retrieved from Kochava servers if you wish to use these results within your app. Be aware that attribution results are always determined by Kochava servers; this feature simply provides the app with a copy of whatever the results were.
For example, you may wish to present a user with a different path if you have determined they installed the app from a certain advertising network or source.
Attribution results are fetched by the tracker as soon as requested and returned to the app asynchronously via a callback. This process usually takes about 3-4 seconds but can take longer depending on network latency and other factors. Once attribution results have been retrieved for the first time, they are not retrieved again and the results are persisted. From that point on they can be queried synchronously by calling the attribution data getter which always provides the persisted attribution results from the original retrieval.
NOTE: For purposes of deferred deeplinking, care should be taken to act upon the attribution results only once, as the original results will continue to be reported after the first retrieval, and are not refreshed on a per-launch basis.
Example (Requesting Attribution Results):
- Your attribution listener can be configured using the Unity Event Inspector UI. When using this method ensure that you select your method with the “Dynamic string” setting in the UI and that the targeted GameObject cannot be destroyed.
-
12345678Kochava.Tracker.Config.SetAppGuid ("_YOUR_APP_GUID_");Kochava.Tracker.Config.SetRetrieveAttribution (true);Kochava.Tracker.SetAttributionHandler ((attribution) => {// got the attribution results, now we need to parse it.Dictionary<string, object> attributionDictionary = JsonFx.Json.JsonReader.Deserialize<Dictionary<string, object>>(attribution);// do something with attributionDictionary...});Kochava.Tracker.Initialize ();
Example (Using the Getter After Attribution Results Have Been Retrieved):
|
1 2 3 4 5 6 |
string attribution = Kochava.Tracker.GetAttribution(); if (attribution.Length > 0) { // got the attribution results, now we need to parse it. Dictionary<string, object> attributionDictionary = JsonFx.Json.JsonReader.Deserialize<Dictionary<string, object>>(attribution); // do something with attributionDictionary... } |
Once you have the attribution results, you will need to parse and handle them in some meaningful way. A variety of data exists within this json object and you will need to determine which data is meaningful for your purposes. For an overview of the attribution dictionary contents, see: Attribution Response Examples.
NOTE: If you wish to send attribution results to your own server, this should be done directly through Kochava’s postback system, rather than retrieving attribution in the app and then sending the results to your own server.
Developer API Reference:
Kochava.Tracker.Config
Kochava.Tracker.SetAttributionHandler(AttributionCallbackDelegate)
Kochava.AttributionCallbackDelegate
string Kochava.Tracker.GetAttribution()
Getting The Kochava Device ID:
Obtain the unique device identifier assigned by Kochava.
If at any time after starting the tracker you would like to get the unique identifier assigned to this device by Kochava, this string (represented as a GUID) can be obtained by calling the device id getter.
Example (Getting the Kochava Device ID):
|
1 |
string myKochavaDeviceId = Kochava.Tracker.GetDeviceId(); |
NOTE: If you have enabled the Intelligent Consent Management feature, this unique device ID may change between consent status changes when consent is required and has not been granted.
Developer API Reference:
string Kochava.Tracker.GetDeviceId()
Enabling App Limit Ad Tracking:
Limit the ad tracking at the application level.
If you wish to limit ad tracking at the application level, with respect to Kochava conversions, you can set this value during or after configuration. By default the limit ad tracking state is not enabled (false).
For example, you might provide an option for a user to indicate whether or not they wish to allow this app to use their advertising identifier for tracking purposes. If they do not wish to be tracked, this value would be set to true.
Example (Enabling App Limit Ad Tracking During Tracker Configuration):
-
123Kochava.Tracker.Config.SetAppGuid ("_YOUR_APP_GUID_");Kochava.Tracker.Config.SetAppLimitAdTracking (true);Kochava.Tracker.Initialize ();
Example (Enable App Limit Ad Tracking After Starting the Tracker):
|
1 |
Kochava.Tracker.SetAppLimitAdTracking (true); |
Developer API Reference:
Kochava.Tracker.Config
Kochava.Tracker.SetAppLimitAdTracking(bool)
Enabling Logging:
Enable logging output from the SDK.
Logging provides a text-based log of the SDK’s behavior at runtime, for purposes of debugging.
For example, while testing you may wish to see the contents of certain payloads being sent to Kochava servers, in which case you would enable logging at a debug (or higher) level.
Six different log levels are available, each of which include all log levels beneath them. Info log level is set by default, although trace log level should be used when debugging so that all possible log messages are generated.
| Log Level: none
No logging messages are generated. |
| Log Level: error
Errors which are usually fatal to the tracker. |
| Log Level: warn
Warnings which are not fatal to the tracker. |
| Log Level: info
Minimal detail, such as tracker initialization. |
| Log Level: debug
Granular detail, including network transaction payloads. |
| Log Level: trace
Very granular detail, including low level behavior. |
Example (Enabling trace logging in a non-production build):
-
123Kochava.Tracker.Config.SetAppGuid ("_YOUR_APP_GUID_");Kochava.Tracker.Config.SetLogLevel (Debug.isDebugBuild ? Kochava.DebugLogLevel.trace : Kochava.DebugLogLevel.info);Kochava.Tracker.Initialize ();
Developer API Reference:
Kochava.Tracker.Config
Kochava.DebugLogLevel
Sleeping the Tracker:
Delay the start of the tracker.
Android and iOS only.
Placing the tracker into sleep mode, the tracker will enter a state where all non-essential network transactions will be held and persisted until the tracker is woken up. This can be useful if you wish to start the tracker early and begin tracking events but need the tracker to wait before sending events or the install data to Kochava servers.
For example, if you wanted the tracker startup process to have little or no impact on your own loading process, you might start the tracker in sleep mode during the app launch but wait while your app’s resource-intensive loading process completes. When the app’s loading process completes, the tracker can be woken and will continue with its own startup process without losing any events that may have been queued beforehand.
Example (Enabling Sleep Mode During Tracker Configuration):
-
123Kochava.Tracker.Config.SetAppGuid ("_YOUR_APP_GUID_");Kochava.Tracker.Config.SetSleep (true);Kochava.Tracker.Initialize ();
Example (Enabling Sleep Mode After Starting the Tracker):
|
1 |
Kochava.Tracker.SetSleep (true); |
Once you are ready to wake the tracker simply set the sleep state to false. At that point the tracker will wake up and continue as normal, sending any queued events or install data.
Example (Waking the Tracker from Sleep Mode):
|
1 |
Kochava.Tracker.SetSleep (false); |
NOTE: For every call to set sleep to true, there should be a matching call at some point setting sleep to false. While these calls do not necessarily have to be balanced, care should be taken to not inadvertently leave the tracker asleep permanently. This allows the tracker to wake up and continue with necessary logic and processing of data. Any events or other activity queued while sleeping will be held but not sent until sleep mode is set to false. This means that if the tracker is never woken from sleep mode, events and other activity will continue to build up in the queue, causing undesirable results and resource usage.
Developer API Reference:
Kochava.Tracker.Config
Kochava.Tracker.SetSleep(bool)
bool Kochava.Tracker.GetSleep()
Consent — GDPR:
Handle GDPR and consent requirements.
The Kochava SDK does deal with GDPR-sensitive data, such as device identifiers. Care should be taken to ensure that your use of the Kochava SDK remains GDPR compliant when applicable.
GDPR applies to users within the EU and requires users to opt-in to data collection. For common questions and answers regarding both GDPR and CCPA consent models, refer to our Handling Consent support documentation.
Example (Starting the Tracker Only When Consent Allows) —
|
1 2 3 4 5 |
if(!consentRequired || consentGranted) { // we will not initialize Kochava unless consent requirements are met Kochava.Tracker.Config.SetAppGuid ("_YOUR_APP_GUID_"); Kochava.Tracker.Initialize (); } |
Example (Calling Tracker Methods Only When Consent Allows) —
|
1 2 3 4 5 6 7 |
if(!consentRequired || consentGranted) { // we will not call Kochava methods unless consent requirements are met // (and we will make sure the tracker has been initialized) if (Kochava.IsInitialized ()) { Kochava.Tracker.SendEvent("My Event"); } } |
Consent — CCPA:
Handle CCPA and consent requirements.
CCPA applies to users within California and allows users to opt out of the sale of their data.
For purposes of CCPA, the Kochava Tracker SDK follows IAB’s CCPA Compliance Framework by reading the U.S. Privacy String from local storage, when present. The app or any entity within the app can set this string any time.
This means that if IAB’s U.S. Privacy String has been set within the app, the Kochava Tracker SDK will automatically adorn installs and post-install events with it’s value, when present. By doing so, CCPA consent status via the U.S. Privacy String can be associated with all user tracking and syndicated downstream for interested 3rd parties.
You do not need to take any action in the Kochava Tracker SDK for this functionality. However, it is your responsibility to ensure the U.S. Privacy String has been set within local storage when appropriate. The SDK will look for the U.S. Privacy String in local app storage under the key ‘IABUSPrivacy_String’ within default shared preferences on Android and default NSUserDefaults on iOS. As long as the value is present, the SDK will pick it up.
For more information regarding SDK-based solutions for CCPA, refer to our Handling Consent support documentation.
Intelligent Consent Manager:
Kochava’s fully managed consent solution.
Push Engagement:
Kochava’s push services.
