A pixel runs in the visitor's browser. A postback runs between two servers. That single difference explains almost every other point in the comparison: what breaks, what you can measure and what you can't.
This post compares the two methods the way a media buyer needs them: how each one works, where each loses data, what the setup looks like and when it makes sense to run both. It is vendor-neutral, since the mechanics are the same in any tracker or ad platform.
Use a server-to-server postback when you need conversions tied to a specific click, with revenue, from a network or an offer you don't control. Use a pixel when you need to feed an ad platform's own optimisation and the conversion happens on a page you can edit. Many setups use both for different jobs.
How pixel tracking works
A pixel is a small piece of code, often a tiny image request or a script, placed on the page where the conversion happens, usually a thank-you page. When the visitor's browser loads that page, it runs the code and sends a request to the tracking system. The system reads the visitor's cookie to find out which click this person came from.
So the pixel depends on three things being true at once: you control the thank-you page, the browser actually runs the code, and the cookie set at click time is still there when the conversion happens.
How a server-to-server postback works
A postback is an HTTP request sent by the affiliate network's server to your tracker's server when a conversion is registered. No browser is involved at that point. For the tracker to know which click converted, the click ID travels with the visitor to the offer, the network stores it, and the network sends it back in the postback URL. If you want the full mechanics, read what a postback URL is and click ID and SubID.
The postback needs no cookie and doesn't care what browser the person used. It does need the click ID to survive the whole path.
Comparison table
| Pixel | S2S postback | |
|---|---|---|
| Where it fires | In the visitor's browser | Server to server |
| Who must place it | Whoever controls the conversion page | The network or advertiser, using your URL |
| Cookies and browser | Depends on cookies and on code running | Independent of the browser; depends on the stored click ID |
| Ad blockers and privacy settings | Can block the request or limit cookies | Not affected, since the browser isn't involved |
| Setup effort | Paste code on a page | Build the URL, add macros, paste into the network, test |
| Conversions that happen later or elsewhere | Missed if the visitor never returns to the page | Caught whenever the network registers them |
| Revenue and status (approved, rejected) | Only what the page knows | Can carry payout and status from the network |
| What it can't do | Track conversions on a page you don't own | Report anything if the click ID was lost on the way |
Where pixels lose data
Pixels fail quietly. The page loads, the visitor sees nothing wrong and your stats are simply short. The usual causes:
- Ad blockers and browser privacy features. They can block the request or restrict third-party cookies, so the system can't tie the event to a click.
- The visitor closes the page before it loads. A slow thank-you page loses events.
- Different browser or device. A person clicks on a phone and buys on a laptop, so the cookie isn't there.
- You don't own the page. On a network's offer you usually can't paste your code, which is the most common reason media buyers move to postbacks.
If your numbers and the network's numbers differ, this is one of the first places to look. The wider picture is in why the tracker and network stats differ.
Where postbacks lose data
Postbacks don't suffer from browsers, but they have their own weak points.
- Click ID lost on the path. A redirect, a form or a landing page drops the parameter, and the network has nothing to send back.
- Wrong or missing macro. The URL in the network has a typo or an unfilled placeholder.
- The network doesn't send the status you expect. You may get only approved leads, or get them with a delay.
- The postback never leaves. Some networks require you to enable it per offer.
Debugging these is a separate topic: postback not firing covers the checks in order.
What setup looks like
Pixel. You copy a snippet from the tracker or ad platform and put it on the conversion page. You open the page, check in the browser's network tab that the request is sent, and see whether the event appears. Setup takes minutes if you own the page.
Postback. The setup has more steps:
- Make sure the click ID reaches the offer. Most networks call the parameter something like
{clickid}or{subid}; check your network's docs for the exact name. - Build the postback URL in your tracker with placeholders for the click ID, payout and status.
- Paste it into the network's postback field for the offer or the account.
- Run a test conversion, or ask the network to fire one, and check that it appears with the right revenue.
It takes longer, but you only do it once per network.
When you use both
The two methods answer different questions, so running both is normal.
- Postback for your own reporting. It tells you which source, creative or landing page produced the approved conversion and what it paid. This is what you use to decide where to put budget.
- Pixel for the ad platform. If a platform optimises delivery on conversion events, it needs those events reported to it, and its own pixel or its server-side API is how that happens.
A worked example with hypothetical numbers: you spend $500 and the ad platform's pixel shows 40 conversions. Your tracker, fed by network postbacks, shows 31 approved. Neither is wrong. The pixel counts leads the page saw, the postback counts what the network approved. For deciding profit you use the 31, for feeding the platform's optimisation you keep the pixel.
The TDS.SO tracker, with postbacks, conversions, revenue and ROI, is in beta. Revenue is counted from approved conversions, and cost from all clicks. TDS.SO does not fire ad-platform pixels or call conversion APIs such as CAPI; if you need those, set them up on your page or with the platform's own tools. What the beta tracker can do is send a postback to the postback URL you set on a traffic source, with the source's click ID filled in.
Clean clicks make both methods more useful
Whichever method you pick, the denominator is clicks. If a share of them are bots, conversion rate and ROI look worse than they are. Filtering bots before they count is part of getting a number you can use. See the analytics page for what the overview and click log show, and keep in mind that TDS.SO filters clicks on the link only; it does not protect forms on your site.
FAQ
Is postback more accurate than a pixel?
For tying a conversion to a click and carrying revenue, usually yes, because it doesn't depend on cookies or the browser. It is only as good as the click ID that travels with the visitor.
Can I use a pixel on a network's offer?
Only if the network lets you place code on their conversion page, which most don't. That is why postbacks are standard for affiliate offers.
Do I need both?
If you run ads on a platform that optimises on conversions, yes, often. The postback handles your reporting, and the pixel or the platform's server-side tool handles its learning.
Why do my pixel and postback counts differ?
They count different things: what the browser saw versus what the network confirmed. Delays, rejections and lost cookies all widen the gap.
What is the minimum I need for postbacks?
A click ID passed to the offer, a postback URL with a placeholder for it, and a network that sends the request back on conversion.
To see clicks, traffic quality and conversions in one place, take a look at TDS.SO analytics.
Guides and write-ups on routing, bot filtering and tracking from the TDS.SO team.
All articles by the author