Como funciona o postback server-to-server
O que é um postback, por que ele é mais confiável que pixel, o que viaja nele, o que o Affilitrack faz ao receber, e o que acontece em seguida — dedução, receita e destinos.
O que é
Um postback é uma requisição HTTP que o servidor da plataforma de pagamento, do CRM ou do merchant faz ao servidor do Affilitrack para avisar que uma conversão aconteceu. Ele não passa pelo navegador do comprador. Por isso não é afetado por bloqueador de anúncios, por Safari, por fechamento de aba antes de a página de obrigado carregar, nem por pixel que não disparou.
Plataforma ──HTTP GET/POST──▶ https://app.affilitrack.com.br/pb?token=…&click_id=…&tipo=venda&payout=97.00&txid=ABCO que viaja no postback
Quatro coisas importam:
| Dado | Parâmetro | Obrigatório |
|---|---|---|
| Qual clique | click_id (ou um dos aliases aceitos) | Sim |
| Qual workspace | token — ou o host do domínio de tracking próprio | Sim, de uma das duas formas |
| Que tipo de evento | tipo (venda, lead, …) | Não — sem ele, o tipo padrão |
| Quanto | payout e moeda | Não — sem valor, a conversão conta mas não gera receita |
| Identificador da transação | txid | Recomendado — é a chave de deduplicação |
| Status | status (approved, pending, declined, refunded) | Não — sem ele, approved |
A lista completa de aliases (clickid, subid, sck, valor, amount, order_id…) está em Parâmetros do postback.
O que o Affilitrack faz ao receber
- Identifica o workspace pelo
token(ou pelo host). - Localiza o clique pelo
click_id. Não encontrou? A conversão viraorphane fica guardada para eventual resgate. - Aplica o merchant da campanha, se houver: traduz parâmetros fora do padrão, aplica as regras que mapeiam status+tipo para LEAD/SALE, confere a allowlist de IP.
- Resolve o tipo de conversão e o status.
- Deduplica: pelo
txid, pelo clique ou por janela, conforme a configuração. Repetição viraduplicate— a conversão existente nunca é alterada. - Grava a conversão ligada ao clique, com valor e moeda (a moeda padrão é a do workspace).
- Dispara os efeitos: envio para os destinos de conversão (Meta, Google), postback de saída para o sub-afiliado, e o postback de saída da fonte, se configurado. Tudo em segundo plano — a resposta ao postback não espera por eles.
- Responde em JSON:
{"status": "created", "event": "SALE", "conversion_id": "…"}.
Tudo isso leva poucos milissegundos; a latência aparece em Logs › Postbacks S2S.
O que aparece depois
- Conversões: a lista com tipo, status, valor e
txid. - Painel e Relatórios: conversões, receita (soma dos payouts de tipos que contam receita), CR, EPC, e — com custo lançado — CPA, lucro e ROI.
- Postbacks S2S: o registro do postback com resultado, motivo e o payload exato.
- Integrações CAPI › Envios recentes: o que foi devolvido para cada plataforma.
Por que a conversão é imutável
Uma vez gravada, a conversão não é sobrescrita por um postback repetido nem por um "corrigido". Se a plataforma manda um segundo postback com o mesmo txid e outro valor, o resultado é duplicate e a diferença fica registrada no log. Isso protege a receita histórica contra reenvios e retries — o preço é que uma correção de valor exige contato com o suporte ou uma conversão nova com txid diferente.
Mudanças de status são a exceção prevista: um refunded depois de um approved com o mesmo txid atualiza o status da conversão, para que o estorno apareça.
Os dois erros que concentram os problemas
- A plataforma não recebe o
click_id. O checkout ou o CRM não tinha o identificador para devolver — a tag não estava instalada, ou o parâmetro que a plataforma propaga (sck,src) não foi usado. O sintoma éorphanouinvalidno log. Veja Instalar a tag. - A plataforma manda a macro sem substituir. O payload mostra
click_id={click_id}literal. O campo de postback da plataforma foi preenchido com a macro errada para ela. Veja Configurar o postback.