Written by Krisztián Stark
Key takeaways
- S2S tracking reports a conversion from one server to another, matched by a click ID that travelled with the user, not by a browser cookie.
- It survives ad blockers, cookie limits, and app environments, but only if the advertiser stores the click ID and calls back reliably.
- Moving tracking to a server does not make it anonymous: sign every call, send the minimum data, and follow consent rules as before.
What is server-to-server (S2S) tracking?
Server-to-server (S2S) tracking is a way of recording conversions where the advertiser’s server tells the ad platform’s server directly that a conversion happened, instead of relying on code in the user’s browser. The two sides match the conversion to the original click through a unique click ID that was passed along in the link. The call that reports the conversion is called a postback, which is why S2S tracking is also known as postback tracking.
Three ways to track a conversion
Every tracking method has to answer one question: which click led to this conversion? They differ in where the answer is kept.
| Method | How the click is remembered | Who reports the conversion |
|---|---|---|
| Pixel with a cookie | A cookie in the user’s browser | The browser loads a pixel or script on the thank-you page |
| SDK in an app | Device signals collected by a library inside the app | The library reports events to its vendor |
| Server-to-server | A click ID stored on the advertiser’s server with the user record | The advertiser’s server calls the platform’s postback URL |
The pixel method depends on the browser keeping a cookie and running the pixel. Ad blockers, private browsing, cookie limits, and users switching devices all break that chain. S2S takes the browser out of the reporting step, which is why it has become the standard for offerwalls, affiliate programs, and app campaigns. In apps, a measurement SDK often sits between the two: What is an MMP? explains how app attribution works.
How S2S tracking works: the click ID round trip
- The click gets an ID. When a user clicks an ad or starts an offer, the ad platform records the click and creates a unique click ID, for example
6acb...30b5. - The ID travels in the link. The platform sends the user to the advertiser’s tracking link with the click ID filled into a parameter, such as
?cid={click_id}. - The advertiser stores it. The advertiser’s site, app backend, or tracker saves the click ID together with the new user or session. This step is the one most often missed.
- The user converts. Minutes or days later, the user signs up, installs, or buys.
- The advertiser’s server calls back. It requests the platform’s postback URL with the stored click ID and the event, for example
click_id=...&goal=signup. - The platform matches and acts. It finds the click, checks the event, records the conversion, and bills or pays accordingly. On an offerwall, it then sends its own postback to the publisher so the user gets their reward.
So there are often two S2S hops: advertiser to network, and network to publisher. Each side only needs the ID it was given, not the user’s identity. How click IDs and the extra sub ID parameters are named, passed, and returned is covered in What are click IDs and sub IDs? The anatomy of the postback call itself, with macros and statuses, is in What is a postback URL?
How S2S calls are secured
A postback is an ordinary web request, so anyone who learns the URL could try to call it. Platforms use two main protections:
- A secret key in the request. The calling server includes a key that only it and the receiver know. It is simple, but the key must stay on the server and be replaced if it leaks.
- An HMAC signature. The sender signs the important values, such as the transaction ID, user, amount, and status, with a shared secret, usually using HMAC-SHA256. The receiver recalculates the signature and rejects any call that does not match, so values cannot be changed on the way.
Add HTTPS, a check that each transaction is applied only once, and logging of every call. Postback security has a step-by-step checklist and complete handler code.
Pros and cons of S2S tracking
| Pros | Cons |
|---|---|
| Not affected by ad blockers or browser cookie settings | Needs development work on the advertiser’s side |
| Works the same in apps, games, and on the web | Breaks silently if the click ID is not stored |
| Reports conversions days or weeks after the click | Harder to debug without logs on both sides |
| Supports later updates, such as reversals | Fraud is still possible if calls are not signed or checked |
| Shares only an ID and an event, not browsing data | Every partner may name parameters differently |
S2S tracking and privacy
Server-side tracking can be more private than a pixel, because the platform receives a click ID and an event instead of running code in the user’s browser. But it is not a way around privacy rules:
- A click ID can be personal data. The EU GDPR lists online identifiers among the examples of data that can identify a person. If a click ID can be linked back to a user, treat it as personal data, with a legal basis, a privacy notice, and a retention limit.
- Platform rules still apply. Apple defines tracking as linking user or device data from your app with data from other companies’ apps, websites, or offline properties for targeted advertising or advertising measurement purposes. That definition is about what you do with data, not where the code runs, so iOS apps still need App Tracking Transparency permission where it applies.
- Send the minimum. A click ID and an event name are enough. Do not put emails, names, or phone numbers in postback URLs, because URLs end up in server logs on both sides.
This is general information, not legal advice. Check the rules that apply in the countries where you operate.
S2S tracking on Sharklio
Sharklio uses S2S tracking on both sides. For advertisers running a multi-step offer campaign, available by arrangement with our team, we fill {click_id} into your tracking link, and your server reports each step to our postback URL with that click ID and the step’s event ID. You pay only for the steps your server reports. Task campaigns need no tracking setup at all: users send proof and you approve each completion before you pay, at a price you set per country from $0.01. The offer postback docs show the exact call. For publishers, every event is sent to your postback URL signed with HMAC-SHA256, failed calls are retried up to 5 times, and the format is in the postback docs. Publisher applications open soon. You can create a free account and your first campaign today.
Frequently asked questions
What does S2S mean in tracking?
Server-to-server. The conversion is reported by one server calling another, not by a pixel or script in the user’s browser.
Is S2S tracking the same as postback tracking?
Yes, in practice. The postback is the call that carries the conversion, and S2S describes how it travels.
Is server-to-server tracking more accurate than a pixel?
Usually, because ad blockers, cookie settings, and app environments do not stop it. It is only accurate if the advertiser stores the click ID and calls back for every conversion.
Does S2S tracking need cookies?
Not for reporting the conversion. The click ID replaces the cookie. Your own site may still use a first-party cookie or session to keep the click ID until the user signs up.
Is S2S tracking GDPR compliant?
The method itself is neither compliant nor non-compliant. What matters is what data you send, why, and on what legal basis. Keep to a click ID and an event wherever you can.
What happens if the postback fails?
The conversion is not recorded until the call succeeds. Many platforms retry failed calls, which is why receivers must ignore duplicates of an event they already applied.
