Skip to main content

Server Postback Tracking

Updated
Server postback tracking—also called “postback tracking” and “server-side tracking”—is the method of tracking conversions that uses the advertiser’s server rather than the user’s browser (as pixel-based tracking does).

This article explains postback tracking in detail and builds on the following articles:

The Flow of Postback Tracking

As discussed in the Attribution Methods in TUNE article, postback tracking can be thought of as two separate processes: what happens when a user clicks on an offer and what happens upon conversion.

Leading up to the conversion:

  1. The user sees an offer.
  2. The user clicks on the offer.
  3. Click goes to a TUNE server. The server records the click and then generates and records the ID for that session (in most cases, the transaction ID).
  4. TUNE immediately directs the user to the offer’s landing page, including the ID for that session in the offer URL.
  5. The user sees the offer’s page on the advertiser’s site. The advertiser’s site handles recording that session’s ID however it deems fit, such as storing it as a variable in an e-commerce site or SDK in a mobile app.

When the user converts on that offer:

  1. The advertiser’s server sends a signal to TUNE (a.k.a. “fires a postback”) that includes the ID TUNE initially supplied. The user is not directed back to TUNE in any way.
  2. TUNE records the conversion for that session.

When to Use Postback Tracking

We generally recommend using server postback tracking over pixel-based tracking, though postback tracking is only viable for offers from advertisers whose website’s software can send a signal back to TUNE in the code. As discussed in the Attribution Methods in TUNE article, it is more reliable t.

Postback tracking is required for offers that don’t direct to a website, notably for mobile apps.

If you want to start session tracking on impression, you cannot use postback tracking for that offer as well. You must set that offer to use pixel-based tracking. 

Postback Tracking Protocols

There are two protocols for server postback tracking: with transaction ID and with partner ID. Using transaction IDs is the best practice and the protocol we typically assume partners and advertisers use for server postback, but in some rare cases, transaction IDs aren’t usable.

Server Postback with Transaction ID

This postback tracking protocol uses transaction IDs—unique identification codes generated when users click on offers—to track individual clicks and their potential conversions. This identifier is sent to the advertisers along with click parameters relevant to that offer, including the offer ID.

The advertiser’s server stores the transaction ID, offer ID, and other information passed to it from TUNE. If that user converts on the offer, the advertiser’s server indicates this event to TUNE by calling the offer’s postback URL and passing in the transaction ID, offer ID, and any desired conversion parameters. TUNE checks if that transaction ID is valid and not duplicated and records the conversion if the transaction ID checks out.

Since transaction IDs are unique, TUNE can immediately reject any duplicated conversion caused by accidental user action, server glitches, or some form of fraud.

Server Postback with Partner ID

This postback tracking protocol uses the publisher’s ID (a.k.a. “partner ID”)—the number assigned to them in your TUNE platform—to track potential conversions. This identifier is sent to the advertisers along with click parameters relevant to that offer, including the offer ID.

The advertiser’s server stores the partner ID, offer ID, and other information passed to it from TUNE. If a user converts on the offer, the advertiser’s server indicates this event to TUNE by calling the offer’s postback URL and passing in the partner ID, offer ID, and any desired conversion parameters. TUNE checks if that publisher is permitted to use that offer and records the conversion if so.

Limitations with Partner ID Tracking

Due to the nature of partner ID postback tracking, there are a couple of issues and shortcomings that might deter you from using this tracking method. Since a transaction ID isn’t passed on the click, some issues and shortcomings exist with this protocol.

There’s no single value that helps the ad server locate which click the conversion is associated with, which limits your reporting capabilities. If you look at a report that shows stats for a partner ID conversion, you can see metrics attributed to the click (partner sub IDs, mobile parameters, creative files, and so on) but not which conversion is linked to that click. Conversions show up on separate lines with advertiser metrics, so the overall information isn’t lost. Still, you won’t be able to easily tell which campaigns are performing better or worse by comparing clicks and conversions.

In nearly all cases, we recommend using transaction IDs over partner IDs. They provide the best defense against fraud and provide the clearest reporting data.

Primary Use Cases for Partner ID Tracking

Companies use partner ID tracking mainly to handle offers with conversions that fire regularly, such as with a publisher credited for each rebill of a consumer they brought to the advertiser. In that case, you must use the partner ID protocol because transaction IDs have a limited lifespan (defaulting to 30 days), and by default, multiple conversions cannot take place for the same transaction ID. (Multiple conversions can be enabled on an offer-by-offer basis.)

Additionally, some advertisers’ systems may be unable to use transaction IDs. This is uncommon today, but it is still a potential issue that requires using partner IDs in tracking.

Postback Implementation in Brief

Ad networks and advertisers work together to implement postback tracking. This section covers the concept in brief; see Implementing Server Postback Tracking for a deep examination of this topic.

  1. The administrator sets the offer’s default offer URL to pass the postback ID (whether a transaction ID or partner ID), the offer ID, and any other desired click parameters.
    1. For the postback ID, include {transaction_id} if using transaction ID or {affiliate_id} if using partner ID.
    2. Include {offer_id}.
  2. The advertiser ensures their system will accept those parameters.
  3. The advertiser’s system must be able to store the postback ID and other parameters and associate those values with the user’s session.
  4. Whenever a user converts, the advertiser’s system makes an HTTP request to the offer’s postback URL, filling in the placeholders with information TUNE requires.
    1. If using transaction IDs, replace TRANSACTION_ID with the stored transaction ID for that session.
    2. If using partner IDs, replace AFFILATE_ID with the stored partner ID for that session.

Learn More

You may also find these articles useful:

Related articles