In affiliate marketing, the conversion happens in somebody else's system. You send a lead to a broker; the registration, the verification and the deposit all take place behind the broker's login, invisible to any tag on your side. The postback is the mechanism that closes this gap: the broker's system calls your system to say "your click number 8: it converted". Every serious affiliate operation runs on postbacks, and most tracking disputes trace back to postbacks configured badly. Here is how the machinery works.
What a postback actually is
A postback (also called a server-to-server or s2s callback) is nothing more exotic than an HTTP request to a URL you control, fired by the advertiser's or network's server when an event occurs. A typical postback URL template looks like this:
https://track.yoursite.com/pb?clickid={clickid}&event={event}&value={value}
You hand this template to the broker or network. When a conversion happens, their system replaces the placeholders with real values and calls the URL. No browser, no cookie, no pixel: one server telling another server what happened. That is why postbacks are immune to ad blockers and app switches, and why they can arrive days or weeks after the click.
The click ID: the thread through the whole funnel
The entire system hangs on one value. When your visitor clicks through to the broker, your tracker generates a unique click ID and appends it to the tracking link. The broker's platform stores that ID against the account the visitor creates. Every subsequent postback for that account carries the ID back to you, letting you join the broker's event to your original click, and through it to the campaign, ad set, creative and cost.
Two failure modes account for most "missing FTDs":
- The ID never arrives at the broker. A redirect strips the parameter, a landing page rebuilds links without it, or the parameter name does not match what the broker's platform expects. Result: the account is created untracked, and no postback will ever fire for it.
- The ID arrives but is not returned. The postback template is missing the placeholder, or the broker fires postbacks only for some event types. Result: you see registrations but never deposits, or the reverse.
Test the chain before spending. Click your own tracking link, register a test account where the broker allows it, and confirm the click ID appears intact in the broker's reporting and comes back in a test postback. Five minutes of testing prevents weeks of arguing about missing conversions.
The event ladder: registration, qualification, FTD, deposits
Broker funnels report a sequence of events, and each one has a distinct job in your reporting:
| Event | Meaning | What it tells you |
|---|---|---|
| Click | Visitor followed your tracking link | Traffic volume, by source |
| Registration | Account created | Landing page and offer fit |
| Qualified / verified | KYC passed, account approved | Traffic quality, fraud filter |
| FTD | First-time deposit, usually the commission trigger | The number your business runs on |
| Deposit / redeposit | Subsequent funding events | True customer value beyond the bounty |
Optimising campaigns on clicks or registrations alone is how affiliates burn budget on traffic that never funds. The FTD is the event that pays, and redeposits reveal which sources produce customers rather than one-off bonus hunters. Feeding those deep events back to ad platforms as conversion signals, via the Conversions API, is what teaches Meta or Google to find depositors instead of clickers.
Cellxpert-style networks and affiliate platforms
Most brokers do not build tracking in-house; they run affiliate platforms such as Cellxpert or similar systems. From your side these platforms share a common shape: a dashboard where you pull your tracking links, a place to register your postback URL per event type, and reporting exports. The details differ per platform, parameter names, supported placeholders, which events can fire postbacks, so treat each broker as its own integration with its own quirks. This per-broker configuration work is exactly what FlowTracker's 34+ broker integrations package up: the parameter mapping, event normalisation and postback handling are prebuilt, so each broker's events land in one consistent schema.
FlowTracker joins your ad spend, clicks and broker events into a single funnel, and fires the results back to Meta, TikTok and Google.
Reconciliation: trust, but verify against the payout
Postbacks tell you what happened in near real time. The payout report tells you what you are getting paid for. These two sources disagree more often than newcomers expect, and the differences are usually explainable rather than sinister:
- Timing windows. A deposit on the last day of the month may land in next month's payout.
- Qualification rules. Brokers pay on qualified FTDs, and the qualification (minimum deposit, verified KYC, non-restricted country) can lag or reverse the raw event.
- Chargebacks and fraud reversals. Events that fired a postback can later be clawed back.
- Lost attribution on their side. Accounts created without your click ID convert invisibly, the payout report is sometimes where you first notice the gap.
The working practice: reconcile monthly, matching postback records to payout lines by click ID or account ID, and investigate anything unmatched in either direction. Persistent one-way gaps are a signal, either your link plumbing is leaking IDs, or the conversation with your affiliate manager is overdue. Teams running this at scale, the audience our forex and trading affiliates solution is built for, treat reconciliation as a standing monthly routine, not an emergency procedure.
Postbacks are unglamorous infrastructure, but they are the difference between an affiliate business run on data and one run on the broker's word. Set the chain up carefully, test it end to end, feed the deep events to your ad platforms, and check the money against the data every month. For the broader context on why server-delivered events beat browser tags, see our guide to server-side tracking vs pixels.