S2S postbacks: how to track conversions
Link a click to a registration or deposit: click identifiers, server postbacks, duplicate prevention, reconciliation and reasons for missing events.
What is an S2S postback?
An S2S postback is a message from the advertiser's server to the affiliate platform's server reporting a result: a registration, first deposit or another agreed event. It helps link that result to a click on a publisher's link. A postback alone is not proof that the sender is trustworthy: authorization, data validation and reconciliation are required.
How a click is linked to an event
A visitor follows a tracking link. The platform records the click and passes a click identifier to the advertiser. The advertiser stores the association with the user and sends that identifier back along with the event when the target action occurs.
The sequence is: campaign link → click → identifier storage → action on the advertiser's side → server message → validation → conversion record. A break at any step can prevent attribution.
Which data needs to be agreed?
You need a click identifier, an event type, a unique transaction number and, where the calculation depends on an amount, that amount and its currency. Use the current integration documentation for the exact parameter names. An example from another affiliate network does not guarantee compatibility.
Agree separately on how registration, first deposits and repeat deposits are distinguished. A new amount does not turn a repeat deposit into a first deposit. For a revenue-based model, clarify what the reported amount means: deposits and net revenue are not interchangeable.
Why a repeated request must not trigger another payment
The network connection may fail after a message has been processed successfully but before the advertiser receives the response. The sender retries the request even though the event is already recorded. Each transaction therefore needs a stable identifier: changing the number with every attempt makes retries harder to recognize.
Authorization checks and duplicate reward prevention solve different problems. The first restricts who can send messages; the second prevents the same event from being paid twice. Secrets must stay on the server; they must not be inserted into public links or advertising materials.
Do you need to add code to the website?
The server postback itself requires server-to-server communication. The advertiser still needs to receive and store the click identifier. The specific implementation depends on its website and integration. A browser pixel can be an additional tool, but it does not replace server-side confirmation of a financial result.
The CPM model requires separate impression tracking: an ordinary link tracks clicks. You cannot calculate impressions as the number of clicks or treat every page request as a payable ad view.
What if the advertiser did not send the event?
A click alone cannot tell you whether a deposit occurred. You need the advertiser's sending log, the receiving side's response and reconciliation with the source system. Compare transactions by identifier and time, not just total daily amounts.
Use the checklist for finding missing conversions. The rules for turning an approved event into available income are explained in the article on hold periods.