Quick answer
Postback tracking is the practice of reporting conversion events from your backend directly to the tracking platform via an HTTP request, instead of relying on a JavaScript pixel that fires in the visitor's browser. It became the affiliate-marketing standard around 2020 as Safari ITP, Firefox ETP, ad blockers, and iOS privacy controls progressively broke pixel-based tracking. By 2026, every modern affiliate platform — Trcker, Impact, Everflow, TUNE, ShareASale, CJ — defaults to postback tracking for new partner integrations because pixel-only attribution now misses 20-40% of conversions depending on audience.
What is postback tracking?
Postback tracking is a server-to-server attribution method. When a customer completes a conversion — a purchase, signup, qualified lead, subscription renewal — your application backend fires an HTTP request to the tracking platform's postback endpoint with the data needed to attribute the conversion: a unique click identifier from the original affiliate click, the conversion amount, a transaction ID, and any metadata you want to record.
The visitor's browser is involved only at the click stage. After that, the entire conversion-reporting flow runs in infrastructure you control. There is no pixel to fire, no cookie to survive, no JavaScript to execute. Your server talks to the tracking platform's server with the same reliability as your payment processing.
The name "postback" comes from the request direction: your application posts the conversion back to the tracking platform after a conversion happens. You will also see this pattern called server-to-server tracking, S2S tracking, server postback, or conversion postback. They all describe the same architectural pattern. See server-to-server tracking for the broader category and postback URL for the specific endpoint format.
How postback tracking works in practice
The end-to-end flow has three stages: click capture, click ID storage, and conversion fire.
Click capture. When a customer clicks an affiliate tracking link, the tracking system generates a unique click identifier and appends it to the destination URL — typically as a query parameter like ?click_id=a7f9c3e2. Your landing page receives both the visitor and the click ID.
Click ID storage. Your application captures the click ID and persists it server-side. The exact mechanism depends on your stack: it might be a cookie that your backend reads, a session record in Redis, or a column on your user record once they create an account. The critical property is that the click ID must be retrievable later — possibly days or weeks later — when the conversion happens.
Conversion fire. When the customer converts, your backend retrieves the stored click ID and fires an HTTP request to the tracking platform's postback URL. A typical postback request looks like GET https://track.example.com/postback?click_id=a7f9c3e2&amount=89.50&txn_id=order_12345. The tracking platform validates the click ID, looks up the affiliate who drove that click, calculates the commission based on your payout configuration, and records the conversion.
The whole flow happens server-to-server. The visitor's browser never knew about the conversion event. This is what makes postback tracking immune to the things that break pixel tracking: ad blockers, cookie restrictions, slow page loads, and the conversion happening hours or days after the click.
Why postback tracking became the standard
Pixel-based tracking was the default for two decades because it was simple to deploy. Drop a