How Postback (S2S) Tracking Works — And Why It Decides Your Attribution

Attribution disputes between advertisers and networks are rarely about honesty. They are about two systems counting different events with different reliability. Understanding how server-to-server postbacks work removes most of that friction, and it is genuinely simple once the jargon is stripped out.

When a user clicks a tracked link, the tracking platform generates a unique identifier for that click — commonly passed as a parameter such as click_id, subid or transaction_id. That value travels with the user to your landing page as a URL parameter.

Your job as the advertiser is to store it. Put it in a hidden form field, a session variable, or the user record you create at registration. When that user later converts — deposits, submits documents, completes a purchase — your server fires a request back to the network's postback URL with that same click ID attached. The network matches the ID to the original click, credits the right publisher, and the loop closes.

That is the entire concept. Everything else is implementation detail.

A conversion pixel lives in the user's browser. That makes it vulnerable to everything a browser can do to it: ad blockers, tracking prevention in Safari and Firefox, cookie expiry limits, users closing the tab before the thank-you page finishes loading, and cross-device journeys where the conversion happens somewhere the pixel was never set.

A postback fires from your server to the network's server. No browser is involved at the moment of truth. It cannot be blocked by an extension, it does not depend on third-party cookies, and it survives the user switching from mobile to desktop as long as your system knows the click ID belongs to that user record.

The practical consequence is that pixel-only setups systematically undercount. The undercount is not random — it is concentrated in privacy-conscious browsers and mobile traffic, which skews optimisation decisions in ways that are hard to spot.

A network gives you a postback endpoint that looks something like a URL with placeholders for click ID, payout, event name and currency. You store the incoming click ID at registration. When the user's first deposit clears, your backend makes a simple HTTPS GET or POST to that endpoint, substituting the stored click ID and the real payout value.

The macros are just find-and-replace tokens. Different platforms name them differently — one calls it {clickid}, another {subid}, another {transaction_id} — which is why the first thirty minutes of any integration is spent mapping names, not writing code.

Two problems appear as soon as postbacks work. First, retries. If your server retries a failed request, the same conversion can be counted twice. Fix this by sending a stable, unique conversion identifier alongside the click ID so the receiving system can discard duplicates.

Second, multi-stage funnels. A lending application has a submitted stage, an approved stage and a funded stage. An iGaming user has registration and first deposit. Sending only the final event hides where campaigns break; sending every event without labelling it inflates counts. Name each event explicitly in the postback and agree with your partner which one carries payout.

Never trust a fresh integration on live spend. Fire a test conversion with a known click ID and confirm it appears on both sides within seconds. Then check the failure path: what happens if your server is briefly unreachable, or if the click ID is missing because a user arrived via an untracked route? A postback queue with retry logic and dead-letter logging costs an afternoon to build and prevents months of reconciliation arguments.

Also verify timing. Attribution windows are contractual. If your postback fires nine days after a click and the agreed window is seven, the conversion will not count, and neither party is wrong.

A healthy setup has near-real-time postback round-trips, a click ID stored on the user record rather than in a cookie, explicit event naming, deduplication by conversion ID, retry handling, and periodic reconciliation between your database and the network dashboard. When those six things are in place, discrepancies drop to a rounding error and the conversation with your partners shifts from whose numbers are right to which segments to scale.

That shift is the real return on getting tracking right. Attribution is not paperwork — it is the input to every optimisation decision you make afterwards.