What is an S2S postback? Server-to-server tracking, explained
Track the user who installs an app, submits a lead, or completes a purchase without ever touching their device - that's what an S2S postback does. It's a server-to-server ping that tells an ad network a conversion happened, no cookies, no pixel fires, no browser involved. The mechanism itself is simple; where it breaks is not.
What is an S2S postback?
An S2S postback is an HTTP request your server sends to an ad network to report that a conversion happened. Client-side tracking works the opposite way: pixels fire in the user's browser, postbacks fire on your backend. The user never sees a postback, can't block it, and no ad-blocker or privacy setting gets in the way - which is why S2S postbacks are the most reliable attribution method for app installs, server-side purchase events, and anything else where the browser was never the final destination.
A postback URL in practice looks like this: https://network.com/postback?clickid=ABC123&payout=5.00&country=DE. The network catches that ping, matches the clickid to the original click, and credits the affiliate or campaign.
How is an S2S postback different from a callback?
In most industry usage, postback and callback mean the same thing - some platforms just call it a 'server callback' or 'server notification' instead. The mechanism doesn't change: an HTTP request from the tracker to the network. The one real variation is that some networks insist the postback carry a unique transaction ID, so a retried postback doesn't get counted twice.
The anatomy of an S2S postback flow
A user clicks an ad on Facebook. The click URL carries a parameter like &clickid=XYZ, and once the user lands on your site or app and completes an action - installing the app, say - your app or your MMP fires a POST or GET request to your tracking server: Keitaro, Binom, Adjust, AppsFlyer. That server matches the clickid to the original click, then sends the postback on to the ad network's endpoint.
The postback itself is usually just a GET URL with query parameters - the network expects the clickid and a status, something like payout=2.50. A 200 OK confirms receipt; a 4xx or 5xx means the tracker should retry, typically 3-5 times with exponential backoff.
When do you need S2S postbacks?
Three scenarios force your hand. Mobile app installs happen outside the browser entirely, so no pixel can fire - the app has to send an install event to your MMP, which fires the postback to the network in turn. Server-side events like purchases or subscriptions are the second case: they happen on your backend, never in the browser. Third is scale - once a campaign gets big enough, pixels start dropping a real share of conversions, typically 5-30% lost to ad-blockers, iOS 14.5+ ATT, or plain browser privacy restrictions.
App campaigns don't give you a choice here - Facebook, TikTok, Google, and Apple Search Ads all require S2S postbacks, routed through an MMP, for app install attribution. Web campaigns can get by on pixels, but at a CPL above $10, that pixel loss means you're effectively overpaying by the same margin on every reported conversion. S2S postbacks close that gap.
S2S postback vs. pixel tracking: a comparison
An S2S postback carries the same kind of event as a pixel, but fired from your server instead of the browser - and that shift changes three things: reliability, latency, and how much control you keep. Pixel tracking, by contrast, works by dropping a JavaScript snippet into the user's browser after a conversion, which the browser then reports to the ad network.
Pixel tracking is simpler to set up - drop a code snippet on the thank-you page and you're done. It breaks, though, the moment a user closes the browser before the pixel fires, runs an ad-blocker, or has ITP (Intelligent Tracking Prevention) switched on. Typical loss runs from 5% on desktop up to 30% on mobile Safari. S2S postbacks lose almost nothing by comparison - the only way one fails is a server that's down or a malformed postback URL.
Pixels fire in real time; postbacks can lag by anywhere from seconds to minutes, depending on your server's processing and retry logic. Most networks will still accept a postback up to 24 hours after the click for attribution purposes, though a sub-second postback serves pacing and optimization far better.
| Factor | Pixel (client-side) | S2S postback (server-to-server) |
|---|---|---|
| Data loss | 5-30% typical | <1% if implemented correctly |
| Ad-blocker resistance | None (blocked easily) | Full (server-to-server, invisible) |
| iOS 14.5+ ATT impact | Heavy (SKAdNetwork fallback) | Unaffected (but SKAdNetwork still used for app installs) |
| Latency | Real-time (sub-second) | Seconds to minutes (depends on retry logic) |
| Setup complexity | Low (copy-paste snippet) | High (server-side development, API integration) |
| Use case | Web purchases, lead forms | App installs, server-side events, high-scale web |
Where you meet S2S postbacks in practice
Buy traffic for mobile apps and postbacks aren't optional - every major MMP, Adjust, AppsFlyer, Branch, Singular, uses them to send install and in-app events back to the networks. You configure the postback URL template inside the MMP's dashboard, and the MMP itself matches the click ID from the click URL to the device ID before firing the postback.
Web campaigns bring S2S postbacks into play through tracking platforms like Keitaro, Binom, or RedTrack, each of which lets you set up postback URLs per network. The sequence runs: user clicks, tracker stores the clickid, user converts on your server, your server passes the conversion data to the tracker, and the tracker fires the postback to the network.
iGaming and trading verticals depend on postbacks even more, because the conversions that matter - a deposit, a first trade, a completed registration - often land hours or days after the click. A client-side pixel would drop most of those delayed conversions outright; the postback keeps attribution intact regardless of how long the gap runs.
Implementing S2S postbacks: the nuts and bolts
Implementation details vary by tracker and network, but the pattern holds steady: generate a unique clickid on click, store it in a database or session, and carry it through the user's journey. On conversion, your backend sends that clickid to the tracker's conversion endpoint, and the tracker fires the postback on to the network.
The pitfalls repeat across teams: forgetting to URL-encode parameters, sending HTTP instead of HTTPS (most networks reject anything non-secure), skipping redirect handling. Test with Postman or cURL before going live - send a postback with a known clickid and check what comes back. Many networks run a test endpoint that returns a simulated attribution for exactly this purpose.
Retry logic matters because networks aren't always up. A typical setup retries up to 5 times with delays stretching from 1s to 5s, 30s, 2min, then 10min; if every attempt fails, log it and alert the team. Some networks also hand you a deduplication key - a unique transaction ID that has to ride along so a retried postback doesn't get counted twice.
The postbacks themselves cost almost nothing to run - a few hundred HTTP requests a day at most, even at $10k/day in spend. What costs money is the development time: figure 4-8 hours to implement and test a single network integration, more if you're handling multiple conversion types like install, purchase, and subscription with custom logic for each.
Limitations of S2S postbacks
S2S postbacks aren't perfect. The whole system leans on the clickid surviving the user's journey, and it often doesn't: click on device A, convert on device B - a routine pattern in web-to-app or cross-device scenarios - and the clickid is simply gone. No postback can match a conversion it never received. Fixing that takes probabilistic or deterministic cross-device matching, which is out of reach for most small advertisers.
There's also latency to reckon with. Real-time bidding systems optimize on conversion signals within seconds, and a postback arriving five minutes later may already have missed the window for the next auction. Most networks will still take the data inside a 24-hour window and fold it into day-level optimization rather than real-time bidding.
Postbacks can also be spoofed - anyone who works out your URL pattern can fire fake conversions at it. HMAC signatures or secret keys, IP validation, and a deduplicated transaction ID close most of that hole, and most mainstream networks support signatures out of the box.
And postbacks travel light: no browser fingerprint, no IP address, none of the user-level signals networks sometimes lean on for attribution. App installs don't miss any of that, since the MMP already supplies device IDs. Web conversions might: if a network needs probabilistic matching, you may have to pass user agent or IP as extra parameters.
Click ID, postback URL, SKAdNetwork: the tracking vocabulary
A click ID is a unique identifier generated the moment someone clicks, then carried inside the postback URL so the network can match the conversion back to that click.
The postback URL is the endpoint on the ad network's server that actually receives the conversion data.
Server callback is the same thing under a different name - most documentation uses it interchangeably with S2S postback.
MMP stands for Mobile Measurement Partner, a platform that manages attribution for mobile app installs and in-app events, using S2S postbacks to do it.
SKAdNetwork is Apple's privacy-focused attribution API for iOS - it runs on the same postback concept, except the postback comes from Apple's servers rather than yours.
A conversion pixel is the client-side alternative, firing in the browser instead of on a server, and losing the share of conversions an S2S postback would have kept.
FAQ
Can I use S2S postbacks without a tracking platform?
Yes, but then you're building your own system to generate click IDs, store them, match conversions, and fire HTTP requests to every network yourself. A tracking platform like Keitaro (from $40/month) or Binom (from $104/month) handles all of that out of the box.
Do S2S postbacks work with iOS 14.5+?
Not for app installs because Apple requires SKAdNetwork postbacks from its own servers there. Web conversions and in-app events that happen after install are a different story: S2S postbacks work as normal and ATT doesn't touch them.
How do I test if my postback is working?
Send the postback URL manually with a known click ID, using cURL or Postman, then check the network's reporting dashboard for the conversion to show up. Many networks also run a test mode that accepts postbacks without needing a real click behind them.
What happens if the postback fails?
Most trackers retry it 3-5 times with increasing delays between attempts. If every retry fails, the conversion is simply lost - worth setting up alerts for failed postbacks and keeping an eye on your tracker's error logs.
Is S2S postback the same as a server-to-server integration?
Yes, in the sense that a postback is one kind of server-to-server integration. The broader category also covers other API calls, like pulling reports or uploading audiences - a postback is specifically the one that sends conversion data.
I can do this on your product
I consult on acquisition, funnels and retention - including hard verticals.
