Cookieless Affiliate Tracking: S2S Postbacks vs Pixels

Somebody drops us a line about this one nearly every month, and the email almost always arrives wearing the same disguise. It is never "please explain postback tracking to me", nobody writes that. What actually lands is a much more anxious message that goes something like, our biggest affiliate says they sent us four hundred players last month and our platform is only showing two hundred and ninety, they are getting fairly loud about it, and we cannot for the life of us work out who is right here.

And the honest answer, the one we give again and again and again, is that quite often neither side is lying to anybody. The affiliate really did send those players. Your platform really did only see some of them. What went missing in between the two of them was the browser, and specifically it was a little bit of tracking machinery that has been quietly falling apart underneath this entire industry for the better part of six or seven years now while everybody carried on as normal and hoped for the best.

So we thought we would write the whole thing out properly, the way we would explain it over a coffee to an affiliate manager who has inherited a programme somebody else set up years and years back and never once looked under the bonnet of. What a pixel is, what a postback is, why one of them broke and the other one did not, and what you can realisticly go and check this week without needing to become an engineer over it.

Let us start at the bottom, becuase the language in this corner of the industry is genuinely awful and half the confusion comes from people using four different words for the same thing.

A pixel, a tracking pixel, a JS pixel, a conversion tag, they all more or less mean the same idea. It is a little bit of code that sits on a page in the player's browser, usually your registration confirmation page or your deposit success page, and when that page loads, the code wakes up and fires a message off saying right, a conversion just happened here, and here is who I think deserves the credit for it.

And the way that code knows who deserves the credit is the whole crux of the matter. When the player first clicked the affiliate's link, something got written into thier browser, a cookie mostly, holding the affiliate's ID. Then the player wanders about your site for a bit, signs up, deposits, hits the confirmation page, the pixel fires, it reads that cookie back out, and it says ah yes, affiliate 4471, this one is yours, well done. Money gets attributed. Everybody is happy.

It is a lovely little system and for a good long while it worked absolutely fine. It is easy to install, you can hand the snippet to a marketing person and they can drop it in themselves without ever bothering a developer, and it does not need anybody's back end to talk to anybody else's back end. You can see exactly why the whole industry built its self on top of it.

The trouble is that every single part of that chain lives inside the player's browser, and the browser is not your property. It never was. It belongs to Apple, or to Google, or to Mozilla, or to whoever wrote the in-app webview inside the app the player happened to click your link from. And around 2017 or thereabouts those companies started, very deliberately, taking the thing apart.

This is the part that a lot of operators still have not really absorbed, becuase it did not happen all at once with a big announcement. It happened in slices, over years, and each slice on its own looked survivable.

Safari went first and went hardest. Intelligent Tracking Prevention showed up and started aggressively binning cookies it decided were tracking-shaped, and eventually Apple got to the point where a cookie written by JavaScript in the browser gets capped at seven days, full stop, and third-party cookies simply do not work at all anymore. Not degraded. Gone. Firefox followed along behind with its own version of much the same idea, blocking third-party cookies by default and not asking anybody's permission first. Chrome has spent years wobbling about publicly on what it wants to do here, changing its mind more than once, and honestly the wobbling is almost worse than a clean decision would have been, becuase nobody can plan around it.

Now sit with that seven day cap for a second and think about what it does to an iGaming programme specifically. A player clicks an affiliate review site on a Tuesday. They have a look at your welcome offer, they think about it, they get distracted, life happens. They come back a fortnight later and deposit. In a pixel-and-cookie world on Safari, that conversion is now an orphan. There is no cookie left to read. The pixel fires, finds nothing, and either attributes the player to nobody at all or shoves them into direct traffic, where they sit looking like a lovely free acquisition you got for nothing. Your affiliate, meanwhile, is looking at thier own click logs and can see perfectly well that they sent that person.

And then layer the rest of it on top. Ad blockers that eat tracking scripts before they ever run, players who click on a phone during the commute and deposit on a laptop that evening which no browser cookie has ever been able to follow, in-app browsers inside social apps keeping thier own little sandboxed cookie jars and binning them when the window closes. Every one of those is a hole, and they are not small holes, and they are not getting patched up.

The bit that really stings is that pixel loss is never random. It skews. Safari and iOS traffic goes missing far more than Android and Chrome traffic does, so the affiliates sending you a nice iPhone-heavy audience out of the UK or the US look worse in your reports than the ones sending you cheaper Android volume, even when the iPhone people are quietly the better players on lifetime value. You end up making commercial decisions, cutting rates, dropping partners, based on a measurement error that is politely pretending to be a performance signal, and every one of the KPIs your team reports on quietly inherits that same error. We have watched operators cut thier single best affiliate over exactly this, and it is a miserable thing to have to explain to somebody after the fact.

Server to server, S2S, postback tracking, again three names for one thing. And the concept underneath it is genuinely simple once somebody says it plainly, which people rarely bother to do.

Instead of asking the player's browser to remember who referred them, you ask your own server to remember it. That is basicly the entire idea. Everything else is plumbing.

Here is how the handshake runs in practice. The affiliate sends traffic to a tracking link, and that link carries a unique identifier on it, a click ID, generated fresh for that specific click. The player lands on your site with that click ID in the URL. Your system grabs it and stores it against that visitor, and then against thier account the moment they register, in your own database, on your own servers, where no browser vendor can reach in and delete it after seven days becuase it is frankly none of thier buisness.

Then later, whenever the thing you actually care about happens, the registration, the first deposit, the qualifying wager, whatever the deal is priced on, CPA or revenue share or hybrid, your server sends a message directly to the affiliate platform's server saying click ID such-and-such just converted, here is the amount, here is the timestamp. No browser involved anywhere in that conversation. No cookie. Just two machines talking to each other over HTTPS the way machines have been talking to each other since long before anybody worried about any of this.

That is a postback. That is the whole thing. It is not clever and it is not new, it is just moving the memory out of a place you do not control and into a place you do.

And the knock-on effects are the good bit. Attribution windows become whatever you decide they should be, thirty days, ninety days, a year, becuase you are the one holding the record now. Cross-device stops being a problem the second the player logs in, since the click ID is bolted to the account and not to a device. Ad blockers cannot block a conversation they are not part of. And your numbers and the affiliate's numbers finally start landing in roughly the same postcode, which does more for a partner relationship than any amount of conference small talk ever will.

If you take one single thing away from this article, make it this bit, becuase we have seen more programmes come unstuck here than anywhere else.

S2S only works if the click ID survives the entire journey from the click to the conversion. That is it. That is the only load-bearing part. And there are about four places where it quietly falls off the back of the lorry.

It falls off at the landing page, when somebody builds a shiny new campaign page and strips the query parameters out of the URL on redirect becuase they looked untidy. It falls off at registration, when the signup form does not pass the stored click ID through into the account record and it just evaporates the moment the player becomes a customer. It falls off between systems, when the click ID lives happily in your CRM but your payments platform is the thing that knows about the deposit and the two of them have never been formally introduced. And it falls off in apps, when the player clicks on the web, then downloads your native app, and there is no deferred deep-link handoff carrying the identifier across the gap.

And if you run master and sub-affiliate structures there is a fifth place to worry about, becuase the click ID has to carry enough information for the override chain to be worked out later, and a chain that loses its parent halfway along pays the wrong people quietly for months.

Every one of those is fixable, and none of them are hard exactly, but they are all boring, and boring is how things do not get done. This is the actual reason we do the integration builds for our partners ourselves during onboarding rather than handing over documentation and wishing everybody luck. It is not that the work is difficult. It is that it is fiddly in about nine seperate places and every one of those places is owned by a different team who all have thier own roadmap, and left alone the whole thing tends to sit in a backlog untill somebody notices the numbers are off six months later.

We are not going to sit here and tell you postbacks are magic, becuase they are not, and pretending otherwise would just set you up for a nasty surprise later.

The first thing is that you now own the reliability of it. When a pixel failed, it failed quietly in one player's browser and nobody died. When your postback endpoint goes down for two hours during a release, every conversion in those two hours is potentially just gone, unless somebody built retries and a queue and a proper dead-letter process, which somebody very often did not. Ask whoever set yours up whether failed postbacks retry. If the answer is a long pause, you have found something worth fixing this week.

Second thing is duplicates, which are the mirror image of the same problem. Retries plus an over-enthusiastic integration equals the same conversion arriving three times, and unless the platform on the other end is deduplicating on the click ID properly, you have just paid an affiliate three times for one player. That one shows up in the finance meeting rather than the marketing one, which is worse.

Third, and this is the sneaky one, S2S makes it technically much easier to under-report on purpose. When the operator's own server decides what to tell the affiliate platform, an operator who is so inclined can simply decide to mention fewer conversions than actually happened. The affiliates know this perfectly well, mind you, they are not daft, and it is precisely why the partners actually worth recruiting ask so many questions about your tracking setup before they scale anything with you. Real-time reporting the partner can log into thier own self, clean audit trails they can inspect, an independent platform sitting in the middle rather than a black box you built in-house, all of that is trust equipment. It is not a feature list item, it is the reason a good affiliate believes you.

And fourth, the honest limitation. S2S needs an identifier to carry. If your traffic arrives with no click ID at all becuase it came through a channel that cannot carry one, a printed QR code, a word of mouth recommendation, a streamer saying your name out loud, then no amount of server to server anything will save you. That is what promo codes are for, and they are still the right answer in those cases, unglamorous as they are.

Now, having spent all that time kicking the pixel about, let us be fair to the poor thing for a minute, becuase the "pixels are dead" line you hear at conferences is lazier than it sounds. Pixels are still perfectly useful up at the top of the funnel where the stakes are lower and approximate is fine, landing page views, funnel drop-off, the general shape of what people do before they convert, and losing a slice of that to a browser is annoying without costing anybody money directly. They are also still how you talk to the ad networks, becuase Meta and Google want thier own signal in thier own format and they are not changing that arrangement for us.

Where the pixel should absolutely not be anymore is as the thing that decides who gets paid. That is the demotion. Measurement of the vague stuff, fine, keep it. Attribution of actual commission, no, that belongs on the server now.

The setup most grown-up operators land on is both of them running side by side by side, postbacks doing the money, a pixel or two doing the colour, reconciled occassionally so you can see how wide the browser-loss gap really is. That gap is a genuinely intresting number to look at once a quarter. It tells you how wrong you were back when you thought you were right.

Enough theory. Here is the short list we would run through if we were sat at your desk, and none of it needs an engineer to start with.

Pull up one of your affiliate tracking links and look at the URL after it redirects. Is the click ID parameter still on there when the player lands, or did the landing page eat it. You can test this your own self in about thirty seconds with a browser window.

Then take a conversion from last week and follow it backwards. Can you get from the deposit, to the account, to the click ID, to the affiliate, without anybody having to open a spreadsheet or ask a developer to run a query. If you cannot, that chain is broken somewhere and you have just found where.

Ask whoever owns the integration what happens when a postback fails. Retries, queue, alerting. You want a real answer, not a shrug.

Compare your reported conversions against your two or three biggest affiliates' own reported numbers for the same period, split by device and by browser where you can get it. If the iOS gap is much wider than the Android gap, that is your pixel dependency waving at you from across the room.

And check what your attribution window actually is in practice as opposed to what the contract says it is. Plenty of programmes have a ninety day window written into thier terms and a seven day cookie doing the actual work, which is not a thing anybody set out to do on purpose, it just happened to them slowly.

If that little audit turns up more than you were hoping for and you end up weighing platforms rather than patching the one you have, our buyer's checklist for choosing iGaming affiliate software walks through the questions worth asking before anybody signs anything.

Fair enough, this is the part where we talk about our own thing, and we will keep it honest rather than turning it into a brochure.

MAP is our affiliate marketing platform, built in London by Mediacle, running in the cloud, used today by 250+ iGaming brands across 20+ countries, US-licensed operators included. Server to server postback tracking is not an add-on module we sell you later, it is the spine of the product, and our MasterPostback™ S2S technology plus dynamic tracking parameters are there so the click ID survives the whole journey rather than most of it. Cross-device attribution sits on top of that, which is what stops one player getting paid for twice, or worse, getting paid for never.

The rest of the toolkit is there for the edges we talked about. JS pixel for the on-site measurement you still want. Promo codes and QR codes for the traffic that cannot carry an identifier at all. Real-time reporting your affiliates can log into for thier own selves, so the trust conversation is a non-event. ML-based fraud detection watching for the patterns that turn up when somebody is gaming your postbacks. Audit trails and role-based access for when the compliance people come asking.

And becuase the integration is genuinely the part everybody dreads, we build it for you during onboarding, free, with an actual account manager rather than a ticket queue. That is the bit our operators mention most when they recommend us to somebody else, believe us on this one.

Have a look at the features page if you want the full list, or why operators move to MAP if you want the shorter version, or just book your own self a demo and bring your worst tracking horror story along with you. We have almost definately heard a worse one.

If you skim-read the lot and only kept five things, keep these.

1. 1Pixels store the referral in the player's browser, and browsers have spent years deleting exactly that. Safari caps script-written cookies at seven days and blocks third-party cookies outright.
2. 2Postbacks store the referral on your own server and report conversions machine to machine, so no browser gets a vote in who gets paid.
3. 3The click ID is the single load-bearing part. If it does not survive the landing page, the signup, the systems handoff and the app install, your S2S is not really S2S.
4. 4S2S has its own failure modes, mainly failed postbacks with no retries and duplicate conversions with no deduplication. Go and ask about both.
5. 5Keep pixels for on-site analytics and ad platforms. Take them off the money.

Is cookie-based affiliate tracking completely useless now

Not completely, no, but it is unreliable in a way that is not evenly spread out, which is arguably worse than being uniformly bad. It still functions well enough on some Android and Chrome traffic and it falls apart on Safari and iOS, so what you get is a picture that systematically undercounts one chunk of your audience and not the other. For general on-site measurement that is survivable. For deciding who gets a commission cheque it is not, becuase you are quietly punishing your best partners for the browsers thier players happen to use.

Do we have to rip out our pixels to move to postbacks

No, and honestly we would not advise it. Most programmes run both, with the postbacks handling attribution and payouts while the pixels carry on doing landing page analytics and feeding the ad platforms. Running them side by side for a while also gives you a very useful read on how wide the browser-loss gap actually was, which tends to be a slightly uncomfortable number the first time anybody looks at it properly.

How long does it take to switch an affiliate programme over to S2S

The platform side is quick, days rather than months, specially when the integration is being built for you. The longer pole is nearly always internal, becuase the click ID has to be picked up at the landing page, carried into the account at registration, and made avaialble to whichever system knows about deposits, and those three things frequently live with three different teams. Start the conversation with all of them at once rather than one after the other and it moves alot faster.

Can affiliates tell whether we are running proper server to server tracking

The good ones can, yes, and they will ask. They look at whether the numbers reconcile against thier own click logs, whether the discrepancy skews by device in the way pixel loss always does, and whether they can log in and inspect conversions for thier own selves rather than waiting for a monthly statement from you. Experienced affiliates have been burned before and they check. Being able to answer those questions cleanly is a genuine commercial advantage when you are trying to neogtiate a deal with a partner who has options.

What about app installs, does any of this survive that

It survives if somebody builds the handoff and it does not if nobody does, becuase the click ID has to be carried across the web to app gap through deferred deep linking, otherwise the player clicks on a mobile browser, installs the app, deposits inside it, and turns up in your reports looking like organic traffic that appeared out of thin air. That one is the most common silent leak we find when we go through an existing setup.

None of this is really a technology argument, when you get right down to it. It is an argument about where the truth of your programme is allowed to live. For about fifteen years the industry parked that truth inside the player's browser, becuase it was easy and free and nobody was going to come along and take it away. Then several very large companies came along and took it away, gradually and without asking, and a lot of affiliate programmes are still running on the assumption that they did not.

Moving attribution onto your own servers puts the record back somewhere you actually control, gives you attribution windows that mean what they say, follows a player across devices the way players actually behave, and stops you quietly under-paying the partners who send you the audience that happens to use iPhones. It is not exciting work. Nobody has ever been promoted for fixing a click ID handoff. But it is the difference between a programme where the numbers are argued about every month and one where they simply are not.

Go and pull one link apart this week and follow the click ID all the way through. If it makes it end to end, brilliant, you are in better shape than most. And if it does not, well, you have just found the reason your reports and your affiliates' reports have never quite agreed with each other, and that is worth knowing.

If you would like a hand tracing it, drop us a line or book your own self a demo, we are always happy to have the coffee-length version of this conversation properly.