Deduplicação: by_txid, one_per_tracking e window:N
Como o Affilitrack decide que um postback é repetição de outro, os três modos de deduplicação do merchant, a interação com o modo new/repeated do tipo, e por que conversões nunca são sobrescritas.
Plataformas de pagamento reenviam postbacks: em retry por timeout, em cada mudança de status, às vezes por bug. Sem deduplicação, cada reenvio viraria uma venda nova. A deduplicação garante que uma transação conte uma vez, e só uma.
A regra básica: txid
O txid (ou transaction_id, order_id, external_conversion_id, tid) é o identificador da transação na plataforma. Se um postback chega com um txid que já existe no workspace para o mesmo tipo, o resultado é duplicate — a conversão existente é mantida e nada é criado.
É por isso que os templates sempre incluem txid=. Sem ele, a deduplicação recai nos modos abaixo.
Os três modos (por merchant)
O modo fica na configuração do Merchant da campanha. Campanhas sem merchant usam by_txid.
| Modo | Regra | Quando usar |
|---|---|---|
by_txid (padrão) | Uma conversão por txid e tipo. Sem txid, cai em one_per_tracking. | Todo checkout que manda ID de pedido. |
one_per_tracking | Uma conversão por clique e tipo, ignorando txid. | CPA, primeiro depósito (FTD), cadastro — eventos que por definição só acontecem uma vez por pessoa. Protege contra plataformas que geram um txid novo a cada reenvio. |
window:N | Postbacks do mesmo clique e tipo dentro de N minutos são a mesma conversão. | Plataformas que não mandam txid e reenviam em rajada (window:5, window:60). |
Interação com o modo do tipo
O modo do tipo de conversão (new ou repeated) é a outra camada:
- Tipo
new→ uma conversão por clique, independentemente do merchant. Um segundotxiddiferente para o mesmo clique e tipo éduplicate. - Tipo
repeated→ várias por clique, desde que otxidseja diferente (ou, emwindow:N, fora da janela).
Na prática: venda em new + by_txid cobre a compra única; upsell ou deposito em repeated + by_txid cobre recorrência com ID de transação; ftd em new + one_per_tracking cobre o primeiro depósito mesmo que a casa reenvie com IDs diferentes.
O que um duplicate faz
- Responde
200com{"status":"duplicate"}— 200 de propósito, para a plataforma parar de reenviar. - Se o
statusmudou (pending→approved→refunded), atualiza o status da conversão existente. - Se o valor é diferente do gravado, registra a divergência no motivo do log. O valor original permanece.
- Não dispara destinos nem sub-afiliados de novo.
Por que nunca sobrescrever
Uma conversão gravada é o registro de receita daquele dia. Se um reenvio pudesse alterá-la, um retry com payload incompleto zeraria receita histórica, e um bug da plataforma reescreveria o relatório de um mês. A imutabilidade é o que torna o histórico confiável. Para corrigir um valor errado de verdade, a saída é uma conversão nova com txid distinto (e, se for o caso, marcar a errada como refunded).
Ver a deduplicação acontecendo
Em Logs › Postbacks S2S, filtre por duplicate. Cada linha mostra o motivo (txid já registrado, clique já convertido, dentro da janela) e o payload. Se você vê duplicate onde esperava created, olhe o txid: a plataforma pode estar mandando o mesmo ID para eventos diferentes (compra e upsell com o ID do pedido pai) — nesse caso o tipo repeated com o ID do item resolve.