Server Postback Tracking Explained

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. User sees an offer.
  2. User clicks on the offer.
  3. Click goes to a TUNE server. The server records the click, 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. User sees offer’s page on advertiser’s site. 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.

postback-tracking-flowchart

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 who have their website’s software able to send a signal back to TUNE in the code. That is more reliable that using pixel-based tracking, as discussed in the Attribution Methods in TUNE article.

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 or measure view-through conversions, you cannot use postback tracking for that offer as well. You must set that offer to use pixel-based tracking. Working directly with Attribution Analytics is the exception to this.

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 networks 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, passing in it 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 that could happen due to accidental user action, server glitches, and some forms of fraud.

Server Postback with Partner ID

This postback tracking protocol uses the publisher’s ID (a.k.a. “partner ID”)—the number the network assigned to them—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 that user converts on the offer, the advertiser’s server indicates this event to TUNE by calling the offer’s postback URL, passing in it 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 issues and shortcomings that might deter from using this tracking method. Since a transaction ID isn’t passed on the click, some issues and shortcomings exists 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, but you won’t be able to easily tell which campaigns are performing better or worse through comparing clicks and conversions.

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

Primary Use Cases for Partner ID Tracking

The main reason for networks to use partner ID tracking is to handle offers with conversions that fire on a recurring basis, such as with a publisher is 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 not have the capability to use transaction IDs. This is uncommon today, but still a potential issue that requires the use of partner IDs in tracking.

Network & Advertiser Implementation in Brief

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 network 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 to the user’s session.
  4. Whenever a user converts, the advertiser’s system makes a 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: