S2S Attribution after ITP: Why Postbacks Beat Pixels

Intelligent Tracking Prevention did not kill affiliate marketing. It killed the idea that a browser would still be holding your cookie when the player deposited three days later. Pixels and image tags live in that browser. A postback does not.

If your reporting still depends on a page loading a script at the moment of conversion, you are measuring the players who did not use Safari, did not install an ad blocker, and did not take a week to deposit. In iGaming, that is a minority.

What ITP actually did

Safari treats third-party cookies as hostile, and first-party cookies as short-lived when they look like tracking. Other browsers followed in pieces. The practical result for an affiliate is simple: the click on Monday and the FTD on Thursday often no longer share a cookie.

A pixel is a request the player's browser makes. If the browser is not there, or will not make the request, the conversion is not yours in the report, even when it is yours in the real world. Image tags are the same idea in a smaller costume.

This is not a theory. It is why every serious iGaming operator already fires events from their server, and why affiliates who still debug "missing FTDs" by looking at the landing page are looking at the wrong machine.

What a postback is, without the mystique

The operator's platform tells AFFILIFY that an event happened, over HTTPS, from server to server. Registration, FTD, later deposits. The request carries the click the operator was given, and the event type.

The player's browser is not in the path. Ad blockers do not see it. ITP does not see it. A player who deposits from a different device than the one they clicked on can still count, because the operator already knew who they were.

Postbacks versus pixels versus image tags is the comparison table. How AFFILIFY works is the path from click to payout. This post is why the middle of that path cannot be a pixel in 2026.

What you should still test

S2S does not make QA optional. A click id that does not round-trip still loses every conversion behind it. Six checks, on a real phone, before you buy traffic.

The difference is what a passing QA now means. It means the operator can see the click and can fire the event. It does not mean a browser cookie survived. Stop treating a conversion on Safari as a surprise.

Retries are expected. Networks time out. A postback that is safe to send twice still counts once. Idempotent postbacks is the finance version of that sentence.

What this is not

It is not a claim that cookies never work. Plenty of same-session deposits still match on a cookie, on browsers that still allow it. It is a claim that you cannot plan a book on that remaining slice.

It is not a tour of how matching is implemented. Traffic quality is checked continuously. We do not publish the checklist. Several independent signals sit behind a conversion, layered so that no single blocker takes the click down with it. The capability is: the FTD can still land when the browser will not help. The mechanism stays off this page.

What to ask an operator before you send traffic

1. Do you fire S2S postbacks for registration and FTD, not only a pixel on the thank-you page?
2. Which parameter do you want the click id in, spelled exactly?
3. Can I send the same event twice without creating a second FTD?
4. How long after the click will you still attribute a deposit?

If the answers are pixel-only, a parameter that changes by email, and "we will see", you are buying a report that will argue with the operator's own admin. On AFFILIFY the click id is one opaque value under the operator's own parameter, conversions arrive S2S, and payouts still clear on the 15th. The browser is not the plan.

Pixels remain a fallback for people who cannot send a server event yet. They are not a strategy.