S2S Postback Tracking: How to Set It Up and Why It Beats Pixels

Every performance campaign eventually reduces to one question: did that click turn into money? Answering it reliably is the job of S2S postback tracking — and it is the difference between optimizing on truth and optimizing on a comfortable fiction. If you run CPA, this is not an optional refinement. It is the mechanism you get paid by.

This guide explains how server-to-server tracking works, why it survives the things that quietly break pixels, and exactly how to wire it up on Adgora.

Why pixels fail and servers do not

A tracking pixel is a request the visitor's browser makes on a thank-you page. That means every link in the chain depends on someone else's browser cooperating. Ad blockers strip it. Privacy modes drop it. The user closes the tab before it fires. Third-party cookie rules keep tightening around it. And because it is client-side, anyone can fire it by hand — which is why pixel-only conversions are easy to fake.

A postback moves the report to where the truth lives: your server. When the order is confirmed in your database, your backend calls the network directly. No browser, no blocker, no cookie policy, no closed tab. The event is reported because it actually happened, from the system that knows it happened. That is why it is both more accurate and far harder to spoof.

The three moving parts

1. The click ID

When a visitor clicks your ad, the click routes through Adgora's tracker at go.adgora.net, which logs the event, runs anti-fraud checks, and forwards the user to your landing page. In that redirect it stamps a unique click ID — a single value identifying that exact click.

2. The macro

You tell the network where to put that ID by placing a macro in your landing URL. Write your destination like this:

https://yoursite.com/lp?click={clickid}&zone={zoneid}&geo={geo}

Adgora replaces each macro at redirect time, so your page receives the values as ordinary query parameters. The available macros are {clickid}, {zoneid}, {geo}, {device}, and {sub1} through {sub5} for your own campaign labels.

3. The postback

When the conversion happens, your server calls the network:

https://api.adgora.net/s2s?clickid=CLICK_ID&status=confirmed&secret=YOUR_OFFER_SECRET

Adgora matches the click ID to the original click, verifies the secret against the offer, and records the conversion. That is the whole loop.

Wiring it up, step by step

1. Put the macro in your landing URL. Add ?click={clickid} (plus any subs you want) to the destination on your creative.
2. Capture it on arrival. Read the parameter on your landing page and store it — in the session, and then on the order or lead record itself. This is the step people skip, and it is why their postbacks later have nothing to send.
3. Fire the postback at the real moment. When the action is genuinely complete — payment captured, lead validated — have your backend make the call with the stored click ID, the status, and your offer's secret.
4. Add a retry. Timeouts happen. Retry a failed postback a few times with a backoff. Duplicates are safe (see below), so retrying costs you nothing and protects real revenue.
5. Test with a real click. Click your own ad, complete the action, and confirm the conversion appears. Never assume the integration works because the code looks right.

Statuses, holds, and cash-on-delivery

Not every conversion is final the moment it fires. A status tells the network what state the action is in — confirmed when it is good, rejected or returned when it is not. That matters because a reversal should reverse the money too, not sit in your stats as revenue that never existed.

Adgora also supports a cash-on-delivery flow, where a conversion stays pending until its status becomes delivered. For physical goods that is the honest model: the "action" is not really an action at checkout — it is an action when the parcel arrives and is paid for. Send the status change when reality changes, and the billing follows. This is the backbone of the dropshipping playbook and of CPA marketing generally.

Idempotency: why duplicates are safe

Adgora records each conversion once, keyed by click ID and offer. A retried postback, a double-fired webhook, or a fraudster replaying a captured URL all hit the same guard: the conversion already exists, so it is not counted again. This is why you should add retries without worrying, and it is also one of the reasons postback fraud fails here — replaying a legitimate conversion a thousand times bills exactly one. The wider picture is in ad fraud explained.

Keep the secret secret

Each offer has its own postback secret. It is what proves the call came from you rather than from someone who guessed a click ID. Keep it server-side — never in JavaScript, never in a URL a browser can see, never in a public repo. If a secret leaks, rotate it. And because postback endpoints attract brute-force probing, Adgora rate-limits calls per source IP; a sane integration never comes close to that ceiling, but a leaked secret being hammered will.

What good tracking unlocks

Once conversions tie back to clicks, everything downstream gets sharper. You can read cost per action by geo, placement, creative, and sub-ID instead of guessing from click-through rate. You can kill a source that delivers volume and no revenue. You can scale the segment that clears your payout. Every optimization discipline in targeting and every margin in arbitrage depends on this one integration being right.

Ready to wire it up? Create an Adgora account, create an offer to get your postback secret, and put {clickid} in your landing URL. See the advertiser overview for how tracking fits the rest of the stack.

Key takeaways

• S2S postbacks report from your server, so ad blockers, cookie rules, and closed tabs cannot break them.
• The loop is {clickid} macro → store it → postback with status + offer secret.
• Storing the click ID on the order is the step most integrations miss — and the reason their tracking is empty.
• Conversions are idempotent by click ID and offer, so add retries freely and replay attacks fail.
• Use statuses honestly — including the pending → delivered flow for cash-on-delivery — so billing follows reality.
• Keep the postback secret server-side; rotate it if it leaks.