Windows SDK

Estimated Time to Complete
30 Minutes

Upgrade to a new major version of the Kochava SDK by following the instructions provided. When upgrading multiple major versions you should review the documentation for each version along the way, making the necessary changes as you go until you reach the most recent version. This will ensure smaller and more manageable steps.

After completing all upgrade steps to the current version you should follow the Confirming the SDK Integration instructions before deploying the changes. You may also wish to review the release notes or additional topics to see if there are any new features you wish to integrate.

Overview

Version 3 to version 4 was a substantial update with the SDK rewritten as a C# WinRT component rather than C++. Support for legacy windows versions was also removed and the public API was updated.

Removals

Support for Windows 8.1 and Windows phone was removed.

Refactors

Public API

The public API has been refactored in a more modern and concise format. After changing to the new SDK library you can review your code and make updates as necessary.

In order to integrate the Kochava SDK you must first add the SDK to your project and then start the SDK in code. To ensure proper measurement and attribution thoroughly review all integration steps.

1. Add the SDK

Adding the SDK to your project involves adding the Kochava Tracker plugin using NuGet.

dotnet add package KochavaWRT --version x.y.z // Replace with latest SDK version

KochavaWRT should now appear within your project’s references.

2. Start the SDK

Once you have added the Kochava SDK to your project, the next step is to configure and start the SDK. We recommend starting the SDK as soon as the application starts in your App singleton, although this can be done later if needed. Starting the SDK as early as possible will ensure it’s started before use, provide more accurate session reporting, and quicker deeplink results.

Only your App GUID is required to start the SDK with the default settings, which is the case for typical integrations. You may optionally use an alternate testing App GUID so that your testing activities do not have an impact on your live app analytics. However, when doing this you should always ensure that you do not accidentally release a production build with a development configuration. Below are examples showing both configuration options.

Example (Basic Configuration)

using KochavaWRT;

public App()
{
     this.InitializeComponent();
     this.Suspending += OnSuspending;

     // start the Kochava SDK
     var config = new Config();
     config.AppGUID = "YOUR_APP_GUID";
     SharedInstance.Initialize(config);
}

Example (Separate Dev and Prod Configurations)

using KochavaWRT;

public App()
{
     this.InitializeComponent();
     this.Suspending += OnSuspending;

    var config = new Config();
    #if DEBUG
    // development build configuration
    config.AppGUID = "YOUR_DEV_APP_GUID";
    config.IsDevelopment = true;
    #else
    // production build configuration
    config.AppGUID = "YOUR_PRODUCTION_APP_GUID";
    #endif
    SharedInstance.Initialize(config);
}

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 it may be useful to see the contents of certain payloads being sent to Kochava servers, in which case the log level should be set to debug (or higher).

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/Never
No logging messages are generated.

Log Level: Error
Errors which are to some extent fatal.

Log Level: Warn
Warnings which are not fatal.

Log Level: Info
General information, such as basic initialization and API calls.

Log Level: Debug
Low level messages intended for verifying (or debugging) an integration. Includes transaction payloads.

Log Level: Trace/Verbose
Very low level messages intended for tracing the origin of an issue.

To enable logging, set the desired log level early during initialization. As the SDK executes, log messages will be printed to your console log. Kochava SDK log messages are denoted with a log tag of “KVA”, however log messages may span multiple lines so filtering just to lines containing KVA may truncate messages. When capturing a log for a support request, it is critical that the entire un-truncated log is provided. For checking basic integration, log messages with the additional tag of “Kochava Diagnostic” provide the most commonly used information.

Example (Enable Trace Logging in a Dev Build)

#if DEBUG
config.LogLevel = LogLevel.trace;
Tracker.LoggingEvent += new LoggingEventHandler(delegate (string message) {
     // output the message to the debug window
     System.Diagnostics.Debug.WriteLine(message);
});
#endif
// Start the SDK
// ...

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

Estimated Time to Complete
15 Minutes

Measure noteworthy actions or user behavior within your app such as in-app purchases, page views, or level completions. Events can be instrumented either by using the standard format provided by the SDK or using your own custom event name.

Events are built by first selecting an event type and then setting any applicable parameters you wish to include with the event. For example, you might choose a Registration Complete event type and set values for the User ID and User Name parameters. There are a variety of standard event types and dozens of standard parameters available. When creating an event, you only need to set values for the parameters you wish to measure with a maximum of 16 per event.

For a detailed list of standard event types and parameters, see: Post Install Event Examples.

It is recommended to use one of the standard event types whenever possible, however for scenarios where standard event types do not meet your needs custom event types can be used. Custom event types can be implemented by using a String in place of the Standard Event Type when instrumenting the event.

FAA Limited Option: Custom event types are not available within Free App Analytics. Free App Analytics apps must use one of the standard event types listed in Post Install Event Examples. Contact us for more information on upgrading to a paid Kochava account.

Example (Basic)

var myEvent = new EventParameters(EventType.RegistrationComplete);
myEvent.SetUserId("abcdefg");
myEvent.SetUserName("user_123");
SharedInstance.Tracker.SendEvent(myEvent);

Example (Custom Parameter Types)

var myEvent = new EventParameters(EventType.LevelComplete);
myEvent.SetName("The Deep Dark Forest");
myEvent.SetCustomValue("attempts", 3.0);
myEvent.SetCustomValue("score", 12000.0);
SharedInstance.Tracker.SendEvent(myEvent);

Custom Event Types

It is recommended to use one of the standard event types whenever possible, however for scenarios where standard event types do not meet your needs custom event types can be used. Custom event types can be implemented by using a String in place of the Standard Event Type when instrumenting the event.

Example (Custom Event Type)

var myEvent = new EventParameters(EventType.Custom);
myEvent.SetCustomEventName("Enemy Defeated");
myEvent.SetName("The Angry Ogre");
myEvent.SetCustomValue("reward", "Gold Token");
SharedInstance.Tracker.SendEvent(myEvent);

NOTE: No custom event name pre-registration is required. However, a maximum of 100 unique event names can be measured within the Kochava dashboard (including any standard event types also used), so keep this in mind as you create new custom event names.

Estimated Time to Complete
10 Minutes

In-app purchases can be easily measured and attributed by sending a purchase event with the total amount of revenue. To accomplish this instrument an event of type Purchase and include the following values.

• Price (revenue)
• Currency
• Product Name
• Receipt (if available)

Example (Purchase Event)

var myEvent = new EventParameters(EventType.Purchase);
myEvent.SetPrice(4.99);
myEvent.SetName("Coins");
myEvent.SetCurrency("usd");
SharedInstance.Tracker.SendEvent(myEvent);

Estimated Time to Complete
10 Minutes

User subscriptions and free trials can be easily measured and attributed by sending a subscription or trial event along with an accompanying identity link. To accomplish this instrument a Subscription or Trial event and include the following values.

• Price (revenue)
• Currency
• Product Name
• Receipt (if available)
• User or Subscriber ID (hash suggested)

BEST PRACTICE: When registering an identity link, register it prior to sending the event, otherwise the event will not be properly associated with the user’s identity.

Example (Subscription Event)

// first set an identity link for this user
config.SetIdentityLink("user_id", "ABCDEF123456789");

// next, instrument the subscription event
var myEvent = new EventParameters(EventType.Custom);
myEvent.SetCustomEventName("Subscribe");
myEvent.SetPrice(9.99);
myEvent.SetCurrency("usd");
myEvent.SetName("Monthly Subscription");
myEvent.SetUserId("ABCDEF123456789");
SharedInstance.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 (Free Trial Event)

// first set an identity link for this user
config.SetIdentityLink("user_id", "ABCDEF123456789");

// next, instrument the subscription event
var myEvent = new EventParameters(EventType.Custom);
myEvent.SetCustomEventName("Start Trial");
myEvent.SetPrice(9.99);
myEvent.SetCurrency("usd");
myEvent.SetName("Monthly Subscription");
myEvent.SetUserId("ABCDEF123456789");
SharedInstance.Tracker.SendEvent(myEvent);

Estimated Time to Complete
5 Minutes

Measuring deeplinks is accomplished similar to any other type of event. In order to measure a deeplink event, create an event of type Deeplink and set the URI parameter along with any other relevant parameters to the values provided when the deeplink occurred.

Example (Deeplink Event)

var myEvent = new EventParameters(EventType.DeepLink);
myEvent.SetUri("https://deeplinkuri.example/path");
SharedInstance.Tracker.SendEvent(myEvent);

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 register this identity link information in the form of unique key and value pair(s) as early as possible. This can be done during the initial configuration of the SDK if the identity link information is already known, or it can be done after starting the SDK. When linking to an event, such as for purchases and subscriptions, ensure that the Identity Link is registered prior to instrumenting the event.

NOTE: Do not send Personal Identifiable Information (PII) such as email addresses or deprecated platform identifiers such as IMEI to Kochava.

Example (Register an Identity Link)

// When starting the SDK
config.SetIdentityLink("user_id","123456789");
config.SetIdentityLink("service_id","abcdefg");

// After starting the SDK
SharedInstance.Tracker.SetIdentityLink("user_id","123456789");
SharedInstance.Tracker.SetIdentityLink("service_id","abcdefg");

NOTE: If the IdentityLink needs to be associated with an Install Postback it must be set prior to starting the SDK or if it is not known at startup, you can leverage Sleeping the SDK to briefly delay SDK startup until it is known.

Estimated Time to Complete
1 Minute

The unique identifier assigned to an install can be obtained any time after the SDK has been started by calling this method. The Kochava Install ID is used to identify a specific app install and is scoped to that particular install. Different apps or installs on the same device will have different Install IDs.

Example (Retrieving the Kochava Install ID)

string installId = SharedInstance.Tracker.DeviceId;
// Do something with the Kochava Install ID

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 experience if you have determined they installed the app from a certain advertising network or source.

Attribution results are fetched by the SDK when 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. Typically once attribution results have been retrieved for the first time, it is persisted and not retrieved again. From that point on they can continue to be queried but will always provide the persisted attribution results from the original retrieval. In some scenarios, such as when using Seasonal Apps, attribution can change and be retrieved again. For such cases discuss it with your Client Success Manager for more details.

Example (Requesting Attribution Results)

var config = new Config();
config.SetAttributionResultsListener(new AttributionResultsListener(delegate (string results) {
     // do something with the attribution result
     if(JsonObject.TryParse(results, out JsonObject attributionDictionary))
     {
          // ...
     }
});

// Start the SDK
// ...

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.

BEST PRACTICE: 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. 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.

Estimated Time to Complete
10 Minutes

While the SDK is in sleep mode, all non-essential network transactions will be held and persisted until the SDK is woken. Commonly, this is used to pause the SDK while waiting for some additional configuration, such as permission prompts, IdentityLink, or App Limit Ad Tracking. Once the configuration has completed, the SDK can be woken up and will continue with its startup process without losing any events that may have been queued before or during sleep.

Example (Enable Sleep Mode)

SharedInstance.Tracker.Sleep = true;

// Start the SDK
// ...

Example (Wake the SDK from Sleep Mode)

SharedInstance.Tracker.Sleep = 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 SDK sleeping permanently. Any events or other activity queued while sleeping will be held but not sent until sleep mode is set to false.

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 at any time but generally it should be done before starting the SDK. By default the limit ad tracking value is set to false indicating no limitation.

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 (Enable App Limit Ad Tracking)

SharedInstance.Tracker.AppLimitAdTracking = true;

NOTE: If the App Limit Ad Tracking value needs to be associated with an Install Postback it must be set prior to starting the SDK or if it is not known at startup, you can leverage Sleeping the SDK to briefly delay SDK startup until it is known.

Estimated Time to Complete
30 Minutes

The Kochava SDK deals with potentially sensitive data such as device identifiers, care should be taken to ensure that your use of the Kochava SDK remains compliant with any applicable laws and regulations.

DISCLAIMER: Kochava does not offer legal advice for businesses in relation to CCPA and/or GDPR compliance. Information herein is for reference only and businesses are encouraged to seek their own legal counsel regarding CCPA and/or GDPR compliance efforts and obligations.