Overview
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). Aspire partners with Tune to provide our clients with server postback tracking.
💡 Please note that if you work with a standalone system like Shopify, or something where you can’t access the backend of your system, you will not be able to implement this method. We recommend using Javascript SDK or implementing client-side tracking in Google Tag Manager.
The Flow of Postback Tracking
Postback tracking can be thought of as two separate processes: what happens when a user clicks on an affiliate’s link and what happens upon conversion.
Leading up to the conversion:
The user clicks on an affiliate’s link.
The click goes to Tune, where they generate and record the ID for that session (in most cases, the transaction ID).
Tune directs the user to the Offer’s landing page and includes the ID for that session in the URL.
The advertiser’s site handles recording that session’s ID on their end, such as storing it as a variable in an e-commerce site. When storing the session ID, they should associate it with the current user.
When the user converts on that offer:
The advertiser’s server sends a signal to Tune by making an API request (a.k.a. “firing a postback”) that includes the session ID and the order amount.
Tune uses the session ID to figure out the affiliate/offer and stores it as a conversion in their database
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 recommend, 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 Aspire. If that user converts on the offer, the advertiser’s server indicates this event to Aspire by calling the offer’s postback URL, and passing in it the transaction ID, offer ID, and any desired conversion parameters. Aspire checks if that transaction ID is valid and not duplicated, and records the conversion if the transaction ID checks out.
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 Aspire. If that user converts on the offer, the advertiser’s server indicates this event to Aspire by calling the offer’s postback URL, and passing in it the partner ID, offer ID, and any desired conversion parameters. Aspire checks if that publisher is permitted to use that offer, and records the conversion if so.
The main reason to use partner ID is to track recurring purchases. For example, if you want customers who make monthly purchases to be attributed to one of your members. 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.
Implementation Overview
This section covers the implementation process in brief; see Implementing Server Postback Tracking with Transaction ID or Partner ID for further directions.
Create a link tracking offer and set the offer’s URL tracking to pass the postback ID (whether a transaction ID or partner ID) and any other desired click parameters.
For the postback ID, include {transaction_id} if using transaction ID or {affiliate_id} if using partner ID.
The advertiser ensures their system will accept those parameters.
The advertiser’s system must be able to store the postback ID and other parameters and associate those values with the user’s session.
Whenever a user converts, the advertiser’s system makes an HTTP request to the offer’s postback URL, filling in the placeholders with information Aspire requires.
If using transaction IDs, replace TRANSACTION_ID with the stored transaction ID for that session.
If using partner IDs, replace AFFILATE_ID with the stored partner ID for that session.
Frequently Asked Questions
What is the default attribution window when using Server Postback tracking?
The default session lifespan is 28 days.