Thanks advertisers can send conversion events to Thanks via a "postback URL". A postback URL is a simple setup involving a URL that needs to be called with a HTTP GET request. This is a simple and flexible approach to conversion reporting, and can be setup to be called programmatically from the browser, as a HTML element (pixel), or server-to-server. The postback type of integration requires that you can store dynamic values provided by Thanks for later usage.

A typical flow would be something like this:

  1. Customer engages with Thanks widget, clicking on your offer
  2. Thanks directs the customer to your landing page, along the way we will include a few URL query parameters for you to send back to us when the customer converts.
  3. The customer completes whatever actions are required to convert
  4. You call the Thanks-provided postback URL, including the parameters we sent to you earlier

Integration

The postback is simply a URL that should be called with a HTTP GET request, with a few dynamic parameters provided by Thanks. All integration types require the ability to accept query parameters and send them back to us later. We can send these query params in any way that works for you, but we have strict requirements for how they are returned to us.

For each integration type, Thanks will coordinate with you to provide you with your unique postback URL, ensure that we are sending our dynamic values in a format that works for you, and to complete end-to-end testing of the integration.

Client side / browser

The browser integration can be set up to be called programmatically, or treated as a pixel.

Programmatic

Programmatic is probably the most common approach because it gives you the most control over when the client-side conversion is triggered.

  1. We send the customer to your landing page with a few query parameters, for example:
https://your-site.com/your/landing/page?queryParam1=thanksQueryParam1&queryParam2=thanksQueryParam2&...your query params

Where the actual text for queryParam1/2 can be defined by you, and thanksQueryParam1/2 are dynamic values that must be saved for later.

  1. When the customer completes the conversion event, the unique postback URL is called with the earlier query params, for example:
fetch('https://thanks.is/postback/{your-key}/{click-id}');

Where sub_id_1 and sub_id_2 are sent with the dynamic values that we provided earlier.

Pixel-like

The pixel-like solution is the least technical and easiest to set up in a tool like Google Tag Manager, but also the least flexible.

  1. We send the customer to your landing page with a few query parameters. The actual text for queryParam1/2 can be defined by you, and thanksQueryParam1/2 are dynamic values that must be saved for later.
https://your-site.com/your/landing/page?queryParam1=thanksQueryParam1&queryParam2=thanksQueryParam2&...your query params
  1. When the customer lands on a page where the conversion event is complete, an image HTML tag should be added to the page that acts as the pixel. sub_id_1 and sub_id_2 are sent with the dynamic values that we provided earlier.
<img src="https://thanks.is/postback/{your-key}/{click-id}" width="0px" height="0px" />

Server to server (S2S)

A S2S integration is the same similar as the browser-based programmatic integration, simply called from the server rather than the browser. You have total control over when the conversion event is sent to us.

  1. We send the customer to your landing page with a few query parameters, for example:
https://your-site.com/your/landing/page?queryParam1=thanksQueryParam1&queryParam2=thanksQueryParam2&...your query params

Where the actual text for queryParam1/2 can be defined by you, and thanksQueryParam1/2 are dynamic values that must be saved for later.

  1. When the customer completes the conversion event, the unique postback URL is called with the earlier query params, for example:
fetch('https://thanks.is/postback/{your-key}/{click-id}');

Where sub_id_1 and sub_id_2 are sent with the dynamic values that we provided earlier.
This example is in JavaScript/Node, but you can of course use language that supports HTTP requests.


Anonymised Postback Events

Pushing conversion events back to Thanks is important so that Thanks can optimise where and how your offers are placed. The default postback setup with the click ID will allow us to tie a conversion event to a specific session and make deep connections into the ideal customer profile for your offer. However, there may be cases where it is not possible or not desirable to tie the conversion event back to a specific session (for example, where regulations restrict the sharing of personal information). For these cases Thanks supports an anonymised postback that lets a select subset of information be shared back to the network, without tying the event to a specific click or user. This information may include things like a creative ID or a placement ID. During the integration process we will ensure that the data to be shared meets your needs.

There are a couple of key limitations with the anonymised postback events:

  1. With less data it follows that this may limit the extent to which Thanks is able to optimise your offer. We will always place the offer as best we can with the available data.
  2. Without the ability to match to a specific click, Thanks cannot perform deduplication of events. We will ingest all events we receive as separate events, even if from your side they are coming from the same session and should be deduplicated.

Setup

The anonymised postback setup is very similar to the process described above.

  1. Thanks will send a customer to your landing page with a link including query params that you will later pass back to us (see above for examples)
  2. At conversion time, you make a HTTP request like so:
  3. https://thanks.is/postback/{your-key}?creativeId=crtv-1234-abc&placementId=plcmt-1234-abcd

The key and precise query parameter names will be shared during integration.


Did this page help you?