A mecânica é simples. Quando um afiliado envia um clique, sua plataforma gera um click ID único e o passa no link de tracking. O operador guarda esse ID junto ao jogador que se cadastra. Quando o jogador converte, o servidor do operador chama uma URL que o afiliado configurou antes, a URL de postback, anexando o click ID armazenado e os detalhes do evento como parâmetros: tipo de evento, às vezes valor do depósito, às vezes moeda. A plataforma do afiliado recebe a chamada, busca o click ID e credita a conversão à campanha, página e fonte certas.
Os postbacks normalmente disparam sobre uma cadeia de eventos, não só um. Uma configuração comum reporta cadastro, FTD e depósitos seguintes como postbacks separados. Um afiliado em um acordo CPA se importa sobretudo com o postback de FTD, já que esse é o evento que paga. Um afiliado em RevShare quer o fluxo completo de depósitos, porque é a única forma de conciliar o NGR reportado com a atividade observável dos jogadores em vez de aceitar um extrato mensal na fé.
Como a chamada viaja de servidor para servidor, ela não depende do navegador do jogador. Nenhum cookie precisa sobreviver, nenhum pixel precisa carregar, nenhum bloqueador de anúncios pode interceptá-la. Por isso os postbacks são o padrão em iGaming, onde o intervalo entre clique e depósito pode durar dias e atravessar vários dispositivos. Os modos de falha são operacionais: uma URL mal configurada, um mapeamento de parâmetro faltando, ou um operador que para de disparar em certos eventos em silêncio. Testar os postbacks antes de escalar tráfego para um acordo novo não é opcional.
Por que isso importa
Cada postback que deixa de disparar é uma conversão que você pagou para gerar e não consegue provar. Afiliados que monitoram a saúde dos postbacks por operador pegam as discrepâncias enquanto são pequenas, e entram nas conversas de conciliação com o próprio log de eventos em vez de depender inteiramente do painel do operador.
Relacionado