Atribuição S2S depois do ITP: por que Postbacks ganham de pixels

A Intelligent Tracking Prevention não matou o marketing de afiliados. Matou a ideia de que um navegador ainda estaria guardando o seu cookie quando o jogador depositasse três dias depois. Pixels e image tags vivem naquele navegador. Um Postback não.

Se o seu relatório ainda depende de uma página carregar um script no momento da conversão, você está medindo os jogadores que não usaram Safari, não instalaram um bloqueador de anúncios e não levaram uma semana para depositar. No iGaming, isso é minoria.

O que o ITP de fato fez

O Safari trata cookies de terceiros como hostis, e cookies de primeira parte como de vida curta quando parecem rastreamento. Outros navegadores seguiram em pedaços. O resultado prático para um afiliado é simples: o clique na segunda e o FTD na quinta muitas vezes já não compartilham um cookie.

Um pixel é uma requisição que o navegador do jogador faz. Se o navegador não está lá, ou não vai fazer a requisição, a conversão não é sua no relatório, mesmo quando é sua no mundo real. Image tags são a mesma ideia numa fantasia menor.

Isso não é teoria. É o motivo de todo operador sério de iGaming já disparar eventos do próprio servidor, e de afiliados que ainda depuram «FTDs faltando» olhando a landing estarem olhando a máquina errada.

O que é um Postback, sem mistério

A plataforma do operador avisa a AFFILIFY que um evento aconteceu, por HTTPS, de servidor a servidor. Cadastro, FTD, depósitos seguintes. A requisição carrega o clique que o operador recebeu, e o tipo de evento.

O navegador do jogador não está no caminho. Bloqueadores de anúncios não veem. O ITP não vê. Um jogador que deposita de um aparelho diferente daquele em que clicou ainda pode contar, porque o operador já sabia quem ele era.

Postbacks versus pixels versus image tags é a tabela de comparação. Como a AFFILIFY funciona é o caminho do clique ao pagamento. Este texto é por que o meio desse caminho não pode ser um pixel em 2026.

O que você ainda deve testar

S2S não torna o QA opcional. Um click id que não faz a ida e volta ainda perde toda conversão atrás dele. Seis checagens, num celular de verdade, antes de comprar tráfego.

A diferença é o que um QA que passa agora significa. Significa que o operador consegue ver o clique e disparar o evento. Não significa que um cookie de navegador sobreviveu. Pare de tratar uma conversão no Safari como surpresa.

Retentativas são esperadas. Redes dão timeout. Um Postback seguro de mandar duas vezes ainda conta uma. Postbacks idempotentes é a versão financeira dessa frase.

O que isto não é

Não é a afirmação de que cookies nunca funcionam. Muitos depósitos na mesma sessão ainda casam num cookie, nos navegadores que ainda permitem. É a afirmação de que você não pode planejar o negócio em cima dessa fatia que restou.

Não é um tour de como os eventos são casados. A qualidade do tráfego é checada o tempo todo. Não publicamos a lista. Vários sinais independentes ficam atrás de uma conversão, em camadas para que nenhum bloqueio isolado leve o clique junto. A capacidade é: o FTD ainda pode aterrissar quando o navegador não ajuda. O mecanismo fica fora desta página.

O que perguntar a um operador antes de mandar tráfego

1. Vocês disparam Postbacks S2S para cadastro e FTD, e não só um pixel na página de obrigado?
2. Em qual parâmetro vocês querem o click id, escrito exatamente?
3. Posso mandar o mesmo evento duas vezes sem criar um segundo FTD?
4. Por quanto tempo depois do clique vocês ainda atribuem um depósito?

Se as respostas forem só pixel, um parâmetro que muda por e-mail, e «vamos ver», você está comprando um relatório que vai discutir com o próprio admin do operador. Na AFFILIFY o click id é um valor opaco só, no parâmetro do próprio operador, as conversões chegam S2S, e os pagamentos ainda liberam no dia 15. O navegador não é o plano.

Pixels continuam sendo um fallback para quem ainda não consegue mandar um evento de servidor. Não são uma estratégia.