Kochava Integration
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.