If you're buying traffic and your conversions don't match what your network reports, tracking is almost always the culprit — and in 2026 the fix is server-to-server (S2S) postback tracking, not pixels.
A postback is simple in concept: when someone clicks, your tracker stamps that click with a unique ID and carries it through to the offer; when the user converts, the network's server calls a URL you gave it and hands that same ID back, so the conversion lands on the exact click that produced it. No cookies, no browser, no JavaScript an ad-blocker can strip. If the basics of tracking are new, start with affiliate tracking explained.
When a user clicks your ad, the tracker generates a click ID — a random alphanumeric string that uniquely identifies that one click and ties it to a campaign and offer. The tracker appends this ID to the outbound offer URL via a token or macro, so the ID travels with the user to the advertiser's page. Critically, the tracker has no memory of the click once the user leaves, so the receiving system must persist the ID — in a hidden form field, first-party cookie or database — until conversion. When the user converts, the network's server fires an HTTP request to your postback URL, substituting the stored click ID back in; your tracker reads it, matches it to the original click, and credits the conversion with its payout and status. Because that final call is server-to-server, no browser, cookie or ad-blocker is ever in the path.
The click ID (also called subid, cid or tid) is the single mandatory value — the thread that survives the entire funnel; lose it and nothing else matters. The postback URL is a server endpoint you own that the network calls on conversion; it carries data purely in query-string parameters rather than cookies. Macros (tokens) are placeholders like {clickid}, {payout} or {status} that get swapped for real values the moment the postback fires. The setup work is almost entirely a name-matching exercise: your tracker expects a parameter with a fixed name, and you set its value to the network's own macro for the ID it stored. Every platform names these differently, which is exactly why postbacks break.
A pixel (a 1×1 image or JS snippet on the conversion page) fires in the user's browser and leans on cookies. It's trivial to install and captures rich browser-side data that powers retargeting — but it silently loses conversions to ad-blockers, JavaScript errors and cookie expiry. A postback fires from the network's server, so it's immune to all three, works for mobile apps and cross-device journeys where cookies can't follow the user, and is harder to defraud because it ties to a confirmed backend event. The trade-off is setup cost: S2S requires generating, storing and passing the click ID through the funnel. The 2026 consensus is a hybrid — S2S as the source of truth for the confirmed conversion, pixels layered on for retargeting and behavioural signal.
A generic postback URL is just an endpoint plus query parameters — one mandatory (the click ID) and the rest optional:
https://your-tracker.com/postback?clickid={click_id}&payout={payout}&status={status}&txid={transaction_id}Replace each placeholder with the network's macro for that value, then paste the finished URL into the affiliate network's dashboard — the network is the party that fires it. There is a second, separate postback that runs tracker → traffic source, so the ad platform learns of the conversion and can optimise; that one is pasted inside your tracker's traffic-source template and returns the traffic source's own click ID. Confusing these two is the most common setup mistake. Test by pasting the full URL with a real click ID (captured from an actual test click, not a fake one) into a browser and confirming one conversion appears. Deduplicate by passing a unique transaction or order ID so upsells and reloads don't double-count.
Five failures eat most "missing conversion" tickets. First, a literal macro arrives — the log shows clickid={clickid} instead of a real value, meaning you used a macro the network doesn't recognise; copy the exact macro from that network's docs. Second, a click-ID mismatch — you pass the ID out in one field but the network returns it in another, so nothing matches. Third, the subid is lost in a redirect — a landing-page rotator or JS redirect drops the parameter; trace a manual click with a known test value and confirm it survives every hop. Fourth, double-firing — a confirmation-page reload counts twice; deduplicate on a unique order ID. Fifth, the postback fires but nothing records — a required parameter is missing, the IP isn't whitelisted, or the ID doesn't match a stored click. The postback log is always your first stop: an empty log means the network is sending nothing, while "click ID not found" means a mismatch.
Client-side tracking is structurally lossy today, and it's browser policy — not your setup — driving it. Safari's ITP blocks all third-party cookies outright and caps JavaScript-set first-party cookies to 7 days, which quietly breaks any attribution window longer than a week. Firefox enabled Total Cookie Protection for all users by default, isolating every site's cookies. Chrome is the twist: after announcing third-party cookie deprecation and delaying it for years, Google reversed course — so third-party cookies still exist and are on by default in Chrome as of 2026, but Chrome is now the only major browser where that's true. The practical takeaway: don't count on cookies, because a large slice of your traffic (Safari, Firefox, ad-blocker users) is already cookieless regardless of Chrome. Server-side S2S tracking sidesteps the whole mess — it never reads or writes a third-party cookie. That's why S2S is the durable standard and pixels are the optional add-on. For how this reshapes credit assignment, see attribution models.
They're the same concept under different names. "Click ID" is the generic term for the unique string that identifies one click; "subid" (sub1, sub2…) is what many networks and traffic sources call the parameter fields they use to carry that ID. Your job is to make sure the ID you send out comes back in the field your tracker reads.
Check your postback log first. An empty log means the network sent nothing (wrong URL or not configured on their side). A "click ID not found" error means the ID that came back doesn't match a stored click, usually because the subid was lost in a redirect or a literal macro was sent instead of a real value. A missing required parameter can also cause a silent drop.
Only if you want what S2S can't give you — retargeting audiences and real-time on-page behavioural data. For the conversion count and payout that pays your bills, S2S is the reliable source of truth. Most operators run S2S as primary and add a pixel for retargeting.
Pass a unique transaction or order ID with every postback. The tracker uses it to recognise repeats — either ignoring exact duplicates or recording distinct transactions — instead of overwriting or double-counting.
