Como evitar conversões duplicadas na Adgora

Conversões duplicadas em campanhas da Adgora após postback: comparação de soluções

Uma conversão pode aparecer duas vezes mesmo que o visitante tenha concluído a ação apenas uma vez. O registro extra pode resultar de um postback repetido, de um endpoint que aceita o mesmo evento mais de uma vez ou de relatórios que contabilizam um evento em dois lugares. Para investigar como evitar conversões duplicadas na Adgora, rastreie todo o percurso e identifique onde o segundo registro aparece pela primeira vez.

Esta comparação aborda três maneiras de evitar duplicatas: deduplicação por ID do evento, verificações do ID da transação e regras baseadas em intervalos de tempo. A escolha certa depende dos identificadores fornecidos pela sua integração e de os clientes poderem ou não converter legitimamente mais de uma vez. Uma regra ampla demais pode eliminar vendas ou cadastros válidos.

Defina os critérios antes de comparar as soluções

Avalie cada solução segundo três critérios: ela bloqueia um evento repetido? Preserva conversões repetidas legítimas? Pode ser testada sem afetar campanhas ativas? Anote esses critérios antes de ajustar o fluxo de postback. Caso contrário, uma queda no número de conversões pode parecer um sucesso, mesmo que a regra tenha suprimido atividades válidas.

Defina o que conta como duplicata para a ação que está medindo. Em uma compra única, o mesmo pedido registrado duas vezes provavelmente é uma duplicata. Já em uma renovação de assinatura, duas compras do mesmo cliente em momentos diferentes podem ser válidas. Defina o critério para o evento específico, não apenas para a campanha.

Guarde os registros necessários para comparar os resultados: o evento de origem, qualquer identificador de evento ou transação, as tentativas de postback, as respostas do endpoint e o relatório de conversões da Adgora. Se algum campo não estiver disponível, registre essa lacuna em vez de presumir que dois registros correspondem à mesma ação. Um pequeno log de testes é mais útil do que dizer vagamente que as conversões “parecem infladas”.

Rastreie uma conversão ao longo do fluxo de postback

Escolha uma conversão registrada e acompanhe-a desde a ação original até a visualização do relatório. Comece pelo evento de origem, como a confirmação de um pedido, o envio de um formulário ou uma ação no aplicativo. Anote o horário e qualquer identificador associado nesse momento. Em seguida, localize o postback enviado e o registro correspondente no endpoint de recebimento.

Compare os identificadores e os horários em cada etapa. Se houver um único evento na origem, mas dois registros correspondentes no endpoint, o segundo registro foi criado em algum ponto entre o envio do postback e o armazenamento no endpoint. Se houver um único registro no endpoint, mas a Adgora mostrar duas conversões, investigue o fluxo de relatórios ou de importação, em vez de alterar a deduplicação do endpoint.

Procure o ponto exato em que os dados divergem. Por exemplo, um evento do navegador e outro do servidor podem registrar a mesma compra, ou uma nova tentativa pode chegar a um endpoint que armazena cada solicitação como um evento novo. São padrões de falha diferentes e exigem soluções diferentes. Se os dois fluxos tiverem um identificador de evento em comum, será mais fácil conciliá-los; caso contrário, talvez seja necessário adicioná-lo na origem.

Registre o percurso em ordem: evento de origem, geração do postback, tentativa de entrega, resposta do endpoint, registro armazenado e relatório da Adgora. Assim, a equipe terá uma sequência concreta para testar. Isso também evita um desvio comum: culpar a campanha antes de verificar se o endpoint já criou dois registros.

Compare lado a lado as estratégias de deduplicação

A deduplicação por ID do evento costuma ser a opção mais clara quando a mesma conversão pode levar um identificador de evento único e estável desde a origem até o destinatário. O endpoint armazena o primeiro evento e considera já processada qualquer solicitação posterior com o mesmo ID. Verifique se o ID permanece igual nas novas tentativas e em qualquer fluxo pelo navegador ou pelo servidor que possa registrar a mesma ação.

A verificação do ID da transação pode funcionar bem para compras quando cada pedido tem uma referência estável. É menos adequada a um formulário de lead, ao início de um período de teste ou a outro evento que não gere naturalmente um ID de transação. Verifique também o escopo: uma referência de transação pode ser única apenas dentro de uma conta ou loja, então talvez seja necessário incluir esse contexto na chave de deduplicação. Essa é uma diferença entre deduplicação por ID de evento e ID de transação que vale considerar ao escolher a estratégia.

As regras baseadas em intervalos de tempo são uma alternativa quando a integração não tem um identificador estável de evento ou transação. Elas podem considerar como uma só as conversões correspondentes que ocorrerem em sequência, mas “em sequência” não significa “o mesmo evento”. Um cliente pode concluir duas ações válidas dentro do intervalo escolhido. Use o menor intervalo que resolva o padrão de duplicação observado e, depois, teste as repetições legítimas antes de aplicar a regra de forma ampla.

Para equipes que analisam a mensuração das campanhas de forma mais abrangente, vale a mesma disciplina ao avaliar fontes de tráfego e definições de conversão. O guia de opções de segmentação para redes de anúncios de criptomoedas da Adgora pode ajudar a orientar as escolhas de segmentação, mas mudanças na segmentação não corrigem uma duplicata criada depois que o postback chega ao endpoint.

Verifique o comportamento das novas tentativas e das respostas

Um tempo limite não comprova que o postback falhou. O endpoint pode ter armazenado o evento, mas não ter enviado uma confirmação clara, levando o remetente a tentar novamente. Confirme como o remetente lida com tempos limite, quais códigos de resposta acionam novas tentativas e se o endpoint só responde depois de salvar o evento.

Examine os logs reais de solicitações e respostas antes de atribuir as duplicatas a novas tentativas. Verifique o número de tentativas, os horários, os códigos de resposta e se cada tentativa continha o mesmo identificador de evento. Depois, confirme o comportamento documentado do endpoint no ambiente utilizado.

Há uma diferença prática importante. Se todas as solicitações repetidas tiverem o mesmo ID e o endpoint armazenar todas, o sistema de recebimento talvez precise lidar com as solicitações de forma idempotente. Se as solicitações repetidas tiverem IDs diferentes para uma única ação de origem, investigue onde esses IDs estão sendo gerados. A política de novas tentativas, por si só, não explica essa divergência.

Teste as soluções com casos de duplicação e de eventos repetidos

Use dois casos controlados antes de implantar uma regra. Primeiro, envie duas vezes o postback da mesma conversão com o mesmo identificador. O resultado esperado é uma única conversão armazenada. Segundo, crie duas conversões legítimas com identificadores diferentes, como dois pedidos separados, e confirme que ambas continuam visíveis. Esses testes ajudam a validar como deduplicar postbacks de conversão sem bloquear ações válidas.

Compare o log de origem, o log de entrega, os registros do endpoint e o relatório da Adgora nos dois casos. A solução só funciona se eliminar o evento repetido sem eliminar o segundo evento válido. Se usar uma regra baseada em intervalo de tempo, teste a repetição dentro do intervalo proposto; um teste fora dele não revelará se a regra é ampla demais.

Quando possível, isole o teste da otimização em tempo real. Use uma campanha de teste, um endpoint de homologação ou um evento de teste claramente identificado para que o resultado não afete as decisões da campanha. Se for inevitável fazer uma verificação em produção, combine o evento de teste e o período de observação com as pessoas responsáveis pelos relatórios antes de enviá-lo.

Se as campanhas também rastrearem ações no aplicativo, verifique se o teste reflete a forma como esses eventos são enviados. Uma visão geral sobre publicidade de criptomoedas para campanhas de instalação de aplicativos pode ajudar a contextualizar a campanha, mas a verificação de duplicatas ainda precisa acompanhar cada evento de instalação ou dentro do aplicativo pelo respectivo fluxo de postback.

Implemente a mudança com um plano de reversão

Comece com uma implantação limitada: um tipo de evento, um endpoint ou uma campanha de teste. Antes de mudar a regra, salve a configuração atual e anote os números de referência para eventos de origem, postbacks entregues, registros no endpoint e conversões informadas. Sem essa referência, será difícil interpretar uma queda posterior.

Monitore os dois lados do problema. Uma queda nas duplicatas só é positiva se as conversões legítimas continuarem intactas. Fique atento a registros ausentes, quedas inesperadas em compras recorrentes, aumento de erros de entrega ou divergências entre os dados armazenados no endpoint e os relatórios da Adgora. Se algum desses sinais aparecer, pause a mudança e compare os IDs dos eventos ou as referências de transação afetadas.

Defina claramente as condições para reverter a mudança antes de lançá-la. Por exemplo, reverta se uma conversão de teste conhecida for suprimida ou se eventos repetidos válidos desaparecerem do log do endpoint. Mantenha a regra anterior disponível até confirmar que a nova funciona com registros reais da campanha.

Documente o que mudou, quando mudou e quais tipos de evento são afetados. Esse registro ajuda a distinguir uma correção no postback de outras alterações na campanha. Também permite que a próxima pessoa restaure diretamente o comportamento anterior se o número de conversões mudar inesperadamente.

Conclusão: prefira uma identidade por evento, quando disponível

Use um identificador de evento único e estável quando a integração for compatível e o mesmo identificador puder percorrer o caminho do evento de origem até o endpoint de recebimento. Assim, o endpoint consegue reconhecer diretamente uma solicitação repetida, sem tratar toda conversão próxima no tempo como duplicata.

Se não houver um ID de evento adequado, use um ID de transação para compras cuja referência seja confiável. Para outros eventos, uma regra baseada em intervalo de tempo pode ser a alternativa mais restrita disponível, mas valide-a com conversões repetidas legítimas antes da implantação. Em casos como o de conversões duplicadas em campanhas da Adgora após postback, a melhor solução é aquela que elimina um registro repetido sem apagar uma segunda ação real — não a que simplesmente reduz o total.