Implementation steps Last modified
Setting up Server to Server (S2S) tracking
Server to server tracking is used in situations where regular conversion registration is not possible by means of placing our tracking code within the publicly available pages on your website (known as "client-side tracking"). The S2S method relies on a unique click identifier to be stored on your server and passed back at the time of the conversion.

We are able to pass our unique click identifier to each page on your website and you are free to choose exactly what the name of this parameter should be, e.g. "someparameter".

The tracking data value is a unique reference to identify clicks within our system and is unique for each incoming click on your website.

As a result, a link to one of your landing pages will look something like:[marker]0%3A%3A12345%3A%3Areference%3A%3A%3A%3A1405418672[/marker]
Please note we always send this parameter url-encoded. Also, it's important this value is stored somewhere within a storage of choice, e.g. a memory database and/or a relational database, depending on the usage. When using a database, it can for example be stored within a column ttClickID or any other column name you prefer.

How to pass back the click identifier
Whenever a conversion is triggered for which an affiliate should receive a reward, this click identifier should be passed back to TradeTracker.
One of the tasks that lies ahead for your development team, is to store this unique click identifier, together with the information that is used to trigger this conversion.

Let's assume you run an online gaming website and you reward affiliates for bringing in new players. It's important that our unique click identifier is stored together with the new player information so that it can be accessed at the time of conversion trigger.

Within a database it would look something like:

111J. Smithjsmith00jsmith@eml.net2014-09-01[marker]0::12345::abc::::1405418672[/marker]
112J. Doeplayer123doe.j@email.org2014-09-0212::54321::def::::1405419867

In case an event is triggered that resembles a lead conversion (e.g. user registration), the following callback format is used:[marker]CAMPAIGN_ID[/marker]&pid=[marker]PRODUCT_ID[/marker]&tgi=&tid={transactionID}&descrMerchant={descrMerchant}&descrAffiliate={descrAffiliate}&data=[marker]{ttClickID}[/marker]&vc={voucherCode}

If an event is triggered that resembles a sales conversion (purchase, booking), the following callback format is used:[marker]CAMPAIGN_ID[/marker]&pid=[marker]PRODUCT_ID[/marker]&tgi=&tid={transactionID}&tam={transactionAmount}&descrMerchant={descrMerchant}&descrAffiliate={descrAffiliate}&currency={currency}&data=[marker]{ttClickID}[/marker]&vc={voucherCode}
In the above callbacks the {ttClickID} is tied to a fixed "data" parameter and its value must be replaced by the value saved during the initial click (and eventually stored within a database, like the table above).

Note: Please make sure all values are URL-encoded.

Example formatted callback[marker]CAMPAIGN_ID[/marker]&pid=[marker]PRODUCT_ID[/marker]&tgi=&tid=123456&descrMerchant=new%20player&descrAffiliate=new%20player&data=[marker]0%3A%3A12345%3A%3Areference%3A%3A%3A%3A1405418672[/marker]
Shortlink to this article:[id]=31
30-Nov-2021 17:07:39