Android – Using the SDK

The following document describes the common use cases for the Kochava SDK after integration is complete. For information on integrating the SDK or configuring and starting the Tracker, refer to our Android SDK Integration support documentation.

Estimated Time to Complete
15 Minutes

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.


BEST PRACTICES: Use the standard event format whenever possible.


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.

  1. Create an event object using the desired standard event type.
  2. Set the desired parameter value(s) within the event object.
  3. Pass the event object to the tracker’s Send Event method.


Example (Standard Event with Standard Parameters)


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)


If you wish to use a custom event type with standard parameters, use a custom event name string within your event constructor in place of a standard event type.


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)


Example (Send a Custom Event with Only a Name, no Event Data)


Example (Send a Custom Event with Event Data)


Example (Send a Custom Event with Additional Data)


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:

Tracker.sendEvent(String, String)


Estimated Time to Complete
10 Minutes

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.


BEST PRACTICES: Include the name parameter as well, so that you can easily identify the SKU from the analytics side.

Google Play receipts can also be optionally included with your purchase event to be validated server-side by Kochava. If desired, include the receipt in your event using the standard parameter setGooglePlayReceipt.


Example (Standard Purchase Event):


Example (Custom Purchase Event with Additional JSON Data):



Subscriptions are tracked no differently than purchase events. When a subscription purchase has surfaced within the app, create and send a purchase event.


Example (Standard Subscription Purchase Event)


Example (Custom Subscription Purchase Event with Additional Data)


Developer API Reference:

Tracker.sendEvent(String, String)

Estimated Time to Complete
5 Minutes

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):


Example (Custom Deeplink Event with Additional Data):


Deeplink Listener:

You can subscribe to listen for app launch deeplinks in addition to deferred deeplinks from the install. Setting a deeplink listener in your launch activity’s onCreate method will provide a callback with either your current app launch parameters or on the first launch of a deeplinked install it will provide the Install Referrer based deeplink parameters.

In the case of a launch deeplink the callback will occur nearly instantly, for a deferred deeplink it will typically take 1-2 seconds but can vary with device speed and system load. The callback will always occur on the main thread.


Example (Deeplink Listener with default timeout) —


Example (Deeplink Listener with long timeout) —


Developer API Reference:

Tracker.setDeepLinkListener(Uri, DeepLinkListener)
Tracker.setDeepLinkListener(Uri, int, DeepLinkListener)


Estimated Time to Complete
10 Minutes

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):


Example (Set an Identity Link After Starting the Tracker):


Developer API Reference:



Estimated Time to Complete
15 Minutes

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 7-10 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.


BEST PRACTICES: Attribution retrieval does not affect attribution and should only be used if there is a clearly defined use within your app for knowing the attribution results; otherwise this causes needless network activity.


Example (Requesting Attribution Results):


Example (Using the Getter After Attribution Results Have Been Retrieved):


The attribution results are provided as a stringified JSON object and can be parsed using a JSONObject or other json parsing functionality. If the attribution results have not yet been retrieved, calling the attribution data getter will return an empty string.

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:

String Tracker.getAttribution()


Estimated Time to Complete
1 Minute

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):


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 Tracker.getDeviceId()


Estimated Time to Complete
1 Minute

If at any time you’d like to get the current version of the SDK, call the SDK Version string getter. This will return the full string value of the SDK version, such as “AndroidTracker 3.4.2”.


Example (Getting the SDK Version String)


Developer API Reference:

String Tracker.getVersion()


Estimated Time to Complete
1 Minute

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):


Example (Enable App Limit Ad Tracking After Starting the Tracker):


Developer API Reference:



Estimated Time to Complete
5 Minutes

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.


To enable logging, set the desired log level during tracker configuration. When the tracker runs, each log message will be printed to your console log. In this example we’re setting a higher log level only when a debug build is detected, which is suggested but is not required.


Example (Enabling trace logging in a non-production build):


BEST PRACTICES: Logging should be set to info log level or lower for production builds. This will limit the log messages generated by the tracker to errors, warnings, and basic tracker initialization messages which contain no sensitive information.


Developer API Reference:



Estimated Time to Complete
10 Minutes

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 After Starting the Tracker):


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)


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:

boolean Tracker.isSleep()


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.


Intelligent Consent Management:

As GDPR can present many challenges during development, Kochava offers a fully managed solution for all your GDPR consent requirements through the use of our Intelligent Consent Management feature. By using this feature the Kochava SDK will handle determining when consent is required for any user while shouldering much the GDPR burden for you. For more information on this feature, see: Intelligent Consent Management.


Self Managed Consent:

Estimated Time to Complete
30 Minutes

If you choose not to use our Intelligent Consent Management feature and you are handling consent on your own or using a 3rd party tool, startup and use of the tracker should not occur until after you have determined consent is not required or consent has been granted. Any calls to the tracker should be wrapped in this check, so that if a user revokes consent later calls to the tracker will stop. Ensure that the tracker has been started before any calls to the tracker are made when going this route.


Example (Starting the Tracker Only When Consent Allows)


Example (Calling Tracker Methods Only When Consent Allows)


NOTE: All consent-related API calls (such as granting or declining consent) will have no effect unless the Intelligent Consent Management feature has been enabled in code and has also been setup in your Kochava dashboard. Do not use these methods if you are handling consent on your own or through a 3rd party tool.


Estimated Time to Complete
1 Day

As GDPR can present many challenges during development, Kochava offers a fully managed solution for all your GDPR consent requirements through the use of our Intelligent Consent Management feature. By using this feature the Kochava SDK will handle determining when consent is required for any user while shouldering much the GDPR burden for you. For complete details on how this feature works, see: Intelligent Consent Management.


If you have configured your app to use the Kochava Push Notification service, you can use the SDK to send push tokens, as well as push open events. For complete information and usage instructions see Push Notifications.


Estimated Time to Complete
5 Minutes

During testing, debugging, and non-production app development, the following steps will help you get the most out of your test environment and help to ensure your integration is working properly.

  1. Use an alternate testing App GUID so that your testing activities do not have an impact on your live app analytics.
  2. Enable Logging, if helpful, to gain insight into the SDK’s behavior during runtime.
  3. If you would like the SDK to behave as it would during a new install, be sure to un-install the app before each test.
  4. Test your Kochava integration. For more information see: Testing the Integration.

Keep in mind that you should always add logic to ensure that you do not accidentally release to production a build with a development configuration used. Below is an example of how this type of configuration might look.


Analyzing SDK Behavior:

While testing your integration, it is important to understand the tracker’s basic flow of operations. When the tracker is started the following sequence of events occur:

  1. A handshake with Kochava may be made to determine dynamic settings for this app.
  2. If this is the first launch, the install data is sent to Kochava (this only happens once).
  3. At this point the SDK is idle and awaits requests from the app.
  4. If a request is made to the SDK by the app, the request is moved to a background thread for processing. After processing the request and performing any necessary network calls the SDK returns to an idle state.
  5. When the app is terminated or suspended, a session-end payload may be sent to Kochava.
  6. When the app is resumed or relaunched, a session-begin payload may be sent to Kochava.

NOTE: While testing, keep in mind that data sent from the SDK may sometimes be delayed up to a few minutes before being displayed within the Kochava analytics dashboard.


In order to call methods and interact with the Kochava SDK from within a native WebView, see: SDK Utilization from a Web View.


Last Modified: Jul 8, 2019 at 1:40 pm