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 HasOffers 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 HasOffers server. The server records the click, then generates and records the ID for that session (in most cases the transaction ID).
  4. HasOffers 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 HasOffers (a.k.a. “fires a postback”) that includes the ID HasOffers initially supplied. The user is not directed back to HasOffers in any way.
  2. HasOffers 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 HasOffers in the code. That is more reliable that using pixel-based tracking, as discussed in the Attribution Methods in HasOffers 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 affiliate 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 HasOffers. If that user converts on the offer, the advertiser’s server indicates this event to HasOffers by calling the offer’s postback URL, passing in it the transaction ID, offer ID, and any desired conversion parameters. HasOffers 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, HasOffers can immediately reject any duplicated conversion that could happen due to accidental user action, server glitches, and some forms of fraud.

Server Postback with Affiliate ID

This postback tracking protocol uses the publisher’s ID (a.k.a. “affiliate 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 affiliate ID, offer ID, and other information passed to it from HasOffers. If that user converts on the offer, the advertiser’s server indicates this event to HasOffers by calling the offer’s postback URL, passing in it the affiliate ID, offer ID, and any desired conversion parameters. HasOffers checks if that publisher is permitted to use that offer, and records the conversion if so.

Limitations with Affiliate ID Tracking

Due to the nature of affiliate 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 an affiliate ID conversion, you can see metrics attributed to the click (affiliate 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 affiliate IDs. They provide the best defense against fraud and give you the clearest reporting data.

Primary Use Cases for Affiliate ID Tracking

The main reason for networks to use affiliate 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 affiliate 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 affiliate 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 affiliate 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 affiliate 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 HasOffers requires.
    1. If using transaction IDs, replace TRANSACTION_ID with the stored transaction ID for that session.
    2. If using affiliate IDs, replace AFFILATE_ID with the stored affiliate ID for that session.

Learn More

You may also find these articles useful:

No Comments

Leave a reply