Server-to-Server Postback

A server-to-server postback is a callback fired between servers, not from the device, that records a conversion by matching a click identifier the network passed at ad time.

When someone clicks your ad, the network hands over a click ID. Your MMP or backend stores it, and when that user installs or converts, your server sends a postback straight to the network's server carrying the ID and the event. No pixel fires in a browser, no SDK call has to survive on the device. Because the handoff is server to server, it keeps working when cookies are blocked, apps sandbox tracking, or the SDK is stripped.

Take a paid social campaign optimizing for purchase. A user clicks, installs, and buys two days later. Your MMP matches the stored click ID to the install, then fires an S2S postback to Meta and Google saying "purchase, this campaign, this value," so their algorithms can optimize toward buyers instead of installers. You control what you send, which means you can hold back revenue amounts or send only coarse events when privacy rules require it.

You own what the postback claims, and so does the network receiving it. Self-attributing networks match the same click on their side, so two of them will both fire a postback for one install and both count it, which is how one purchase becomes three in your reports. The postback is a message, not proof; a fraudster who guesses your click ID format can fire fake ones straight at your endpoint unless you sign and validate them.

The server tells the truth it was handed, nothing more.