Home Integrations Kochava Integration

Kochava Integration

Last updated on May 27, 2026

1. What UCLIQ Does In This Integration

UCLIQ is used as a traffic-delivery and performance marketing analytics platform for advertisers, networks, and publishers. In mobile app campaigns, UCLIQ can work together with Kochava when the final tracking link is a Kochava tracking link.

There are two main ways traffic can be sent:

  1. Traffic goes through a UCLIQ tracking link first, and then UCLIQ redirects it to Kochava.

  2. Traffic goes directly to Kochava, without passing through UCLIQ first.

These two scenarios are important because they define whether UCLIQ can generate a Click ID or not.

2. Scenario 1: Traffic Goes Through UCLIQ First

This is the standard tracking flow.

A publisher generates a tracking link in UCLIQ. The user clicks this link, the traffic goes through UCLIQ’s traffic delivery system, and then UCLIQ redirects the user to the Kochava tracking link.

The flow looks like this:

Publisher Tracking Link → UCLIQ → Kochava Tracking Link → App Install / Event

In this scenario, UCLIQ generates a unique Click ID.

This Click ID must be passed to Kochava in the tracking link. Later, when Kochava sends a postback to UCLIQ, Kochava must send this same Click ID back.

This is needed so UCLIQ can match the install or event to the original click.

Example:

https://kochava_tracking_link.com/?click_id={click_id}

Or, if Kochava expects the click value in another parameter:

https://kochava_tracking_link.com/?sub1={click_id}

The parameter name can be changed depending on Kochava’s requirements, but the UCLIQ macro {click_id} should not be changed. UCLIQ will replace this macro with the actual click value automatically. The main UCLIQ guide also confirms that passing click_id in the advertiser link is mandatory for attribution when traffic goes through UCLIQ.

3. Scenario 2: Traffic Goes Directly To Kochava

Sometimes traffic cannot go through UCLIQ first. This can happen when an ad platform does not allow intermediate tracking links, or when the traffic must be sent directly to the Kochava tracking link.

The flow looks like this:

Ad Network / Mobile App → Kochava Tracking Link → App Install / Event

In this case, UCLIQ does not receive the original click and does not generate a Click ID.

Because of that, Kochava cannot send a Click ID back in the postback.

For this scenario, Kochava is expected to send a postback without a Click ID, but with a specific Campaign ID. This campaign identifier allows UCLIQ to understand which UCLIQ campaign the install or event belongs to. The file also mentions that the campaign ID can be included in the original postback template as part of the Kochava tracking link.

4. Which Postbacks UCLIQ Expects To Receive

UCLIQ expects to receive postbacks only for installs and events that were generated by campaigns configured and run by UCLIQ customers.

This means UCLIQ expects postbacks for:

  1. Campaigns where traffic goes through UCLIQ and a Click ID is generated.

  2. Direct campaigns where traffic goes straight to Kochava, but the campaign is still related to a UCLIQ customer’s setup.

UCLIQ does not expect to receive all app events from Kochava. It should only receive postbacks for the campaigns that belong to the client’s UCLIQ setup.

5. Postback URL Structure

A UCLIQ postback URL has two parts:

  1. A fixed part.

  2. Variable parameters.

Fixed Part

Example:

https://track.ucliq.com/pb/aaaabbbbccccddddeeeeffff

The domain and security token are client-specific.

The token is different for different advertisers or UCLIQ clients, but it remains the same for offers, apps, campaigns, and events under the same advertiser or UCLIQ client.

Variable Parameters

Variable parameters are added after ?.

Example:

?click_id={click_id}&sum={sum}&goal={goal}&tid={tid}

The most important parameters are:

click_id — the unique click identifier generated by UCLIQ. It is required when traffic goes through UCLIQ.

sum — the conversion amount, if applicable.

currency — the postback currency. This is optional. If it is not sent, UCLIQ uses the offer currency.

tid — the advertiser transaction ID. It is optional, but strongly recommended when there can be several postbacks for the same click.

goal — the goal alias or event name configured in UCLIQ.

type — conversion type, for example Lead, Sale, RevShare, or Chargeback. Usually optional.

6. How Goal / Event Name Works

In this integration, Goal can be understood as an event name.

It can be fixed or dynamic.

For example, Kochava can always send:

goal=Install

Or Kochava can send different goal values depending on the event:

goal=Install
goal=Deposit
goal=Renew

The client configures goals and their names in UCLIQ. UCLIQ does not use a fixed predefined list of goal names. Clients can define the goal names themselves.

However, the goal value should be alphanumeric and should not contain spaces or special symbols.

Good examples:

Install
CPA
RevShare
Deposit
Load
Renew

Bad examples:

First Deposit
Purchase Completed
Deposit #1
Renew/Subscription

If Kochava event names contain spaces or special symbols, the client should map them to UCLIQ-friendly goal names.

Example:

Kochava Event: First Deposit
UCLIQ Goal: Deposit

Kochava Event: Subscription Renewed
UCLIQ Goal: Renew

Kochava Event: App Install
UCLIQ Goal: Install

7. Impression Tracking

UCLIQ can pass an impression ID if the ad platform can add the impression ID to the tracking link.

Any of the UCLIQ sub1-sub6 parameters can be used for this.

Example:

https://ucliq_tracking_link.com/c/xxxx?sub1={impression_id}

In this case, UCLIQ can pass this value to Kochava.

However, UCLIQ does not currently process or analyze impressions internally as an ad analytics platform. It can only pass this information through if it is available.

8. Ext1-Ext6 Parameters

Ext1-Ext6 are optional parameters for additional arbitrary data sent by the advertiser, in this case Kochava.

They can be used if the client needs extra information in the UCLIQ postback.

However, in the QA file, Kochava confirms that they cannot define which extra parameters should be included, because they are not the advertiser. Therefore, these parameters can be left out unless the client has a specific requirement.

9. Example Postback With Click ID

This example applies when traffic goes through UCLIQ first.

https://track.ucliq.com/pb/aaaabbbbccccddddeeeeffff?click_id={click_id}&goal=Install&tid={transaction_id}

With conversion amount:

https://track.ucliq.com/pb/aaaabbbbccccddddeeeeffff?click_id={click_id}&sum={sum}&goal=Deposit&tid={transaction_id}

In the real setup, {click_id}, {sum}, and {transaction_id} must be replaced with the correct Kochava macros.

10. Example Postback Without Click ID

This example applies when traffic goes directly to Kochava and UCLIQ does not generate a Click ID.

https://track.ucliq.com/pb/aaaabbbbccccddddeeeeffff?campaign_id={campaign_id}&goal=Install&tid={transaction_id}

In this case, the campaign ID is required so UCLIQ can understand which campaign the install or event belongs to.

11. Testing Logic

For the scenario with UCLIQ tracking links, the basic testing flow is:

  1. Create or use an offer in UCLIQ.

  2. Add the Kochava tracking link as the advertiser link.

  3. Make sure {click_id} is passed in the Kochava link.

  4. Launch a campaign and generate a test click.

  5. Copy the generated Click ID.

  6. Send a test postback to UCLIQ with this Click ID.

  7. Check that UCLIQ responds with OK.

  8. Check the conversion in UCLIQ reports.

The UCLIQ guide explains that after running a test postback, the conversion is usually processed within 1–3 minutes and can then be checked in the Conversions section and reports.

Example test postback:

https://track.ucliq.com/pb/aaaabbbbccccddddeeeeffff?sum=10&click_id=test_click_id&goal=Install&tid=test123

For direct Kochava traffic without UCLIQ click ID, the test should confirm that Kochava can send campaign-level postbacks without click_id, and that UCLIQ can identify the campaign using the campaign identifier.

12. Key Points To Remember

If traffic goes through UCLIQ, Click ID must be generated by UCLIQ, passed to Kochava, and returned in Kochava’s postback.

If traffic goes directly to Kochava, there will be no UCLIQ Click ID, so Kochava should send the postback with a campaign identifier instead.

UCLIQ should receive only postbacks related to campaigns configured and run by UCLIQ customers.

The fixed postback URL token is client-specific. It is different between advertisers or UCLIQ clients, but the same across offers, apps, campaigns, and events under the same advertiser/client.

Goals are configured by the client in UCLIQ. UCLIQ does not require a predefined list of goal names, but goal values should not contain spaces or special symbols.

Impression ID can be passed through UCLIQ using sub1-sub6, but UCLIQ does not analyze impressions internally.

Ext1-Ext6 can be skipped unless the client specifically needs extra data.