Enviar eventos pelo servidor com a Events API sem contar venda em dobro

Com o Pixel limpo, sobra o que o navegador não enxerga. O Pix que é pago vinte minutos depois de a pessoa fechar a aba, o boleto compensado dois dias mais tarde e o visitante com bloqueador de script não chegam ao TikTok por nenhum código de página.

Sem esse pedaço, o lance aprende com uma amostra torta. Ele vê o cartão e perde parte do Pix, que no Brasil pesa no caixa de qualquer loja virtual. Quem tenta resolver mandando a mesma compra pelos dois caminhos sem preparo cai no problema oposto: a venda aparece em dobro.

Events API é a conexão de servidor a servidor, em que o sistema da empresa envia o evento direto ao TikTok, sem passar pelo navegador. Depois de montá-la, a compra confirmada chega pelo servidor, o navegador continua mandando o que só ele vê, e o event_id garante que o mesmo pedido seja contado uma vez.

Servidor, aqui, é qualquer sistema da empresa que sabe que o pagamento entrou: a plataforma da loja, o sistema de pedidos ou um pequeno serviço feito para isso. A Events API aceita eventos de site, de aplicativo e offline, como venda em loja física ou fechamento no CRM, e a Central de Ajuda recomenda usá-la junto com o Pixel, com deduplicação.

Arquitetura é a primeira escolha, e ela define prazo e custo. Pelo quadro oficial, parceiro de comércio ou de dados liga a Events API em menos de uma hora, enquanto a integração direta pela API leva de 1 a 4 semanas. Existe ainda o Events API Gateway, uma conexão de servidor feita em minutos, pensada para agências e varejistas com várias lojas.

Deduplicação é o mecanismo que junta o mesmo evento vindo pelo Pixel e pela Events API. Os dois canais mandam o mesmo event_id, um código único por evento, como o número do pedido. O TikTok guarda o primeiro evento que recebe e o enriquece com os dados do segundo. Ela só é necessária quando o mesmo evento vai pelos dois caminhos.

Janela de deduplicação é o prazo em que o TikTok ainda reconhece a repetição: 48 horas a partir do primeiro evento. Entre Pixel e Events API, a página de maio de 2025 diz que a fusão vale para eventos que chegam com mais de 5 minutos de diferença, dentro dessas 48 horas. Se o Pixel manda AddToCart e o servidor manda Purchase, não há nada a deduplicar.

Pix e boleto se encaixam nesse desenho sem regra oficial própria, que o TikTok não publica. O raciocínio de implementação é dividir por meio de pagamento. Cartão aprovado sai pelos dois canais com o mesmo event_id. Pix e boleto só geram Purchase no servidor, quando o pagamento confirma, e como viajam por um canal só, a janela de 48 horas deixa de ser problema.

Correspondência é o que permite ao TikTok ligar o evento do servidor a uma pessoa que viu o anúncio. As chaves são o Click ID, identificador do clique no anúncio, o e-mail e o telefone, o External ID (o código do cliente no sistema da loja), o IP, o navegador e o cookie de primeira parte _ttp. Na Events API, IP e navegador precisam ser enviados à mão.

Hash é a transformação do dado em uma sequência fixa de caracteres, sem volta, e o TikTok exige SHA-256 para e-mail, telefone e External ID. Antes do hash vem a normalização: e-mail sem espaços e em minúsculas, telefone no padrão internacional E.164, com +55 e DDD. Normalize e aplique hash antes de enviar, e nunca mande e-mail em texto aberto.

Qualidade da correspondência aparece no Events Manager como EMQ Score (Event Match Quality, a nota de quão bem os eventos casam com pessoas), calculado como média ponderada da cobertura de cada chave. O TikTok não publica a escala, então a leitura útil é a tendência: nota que cai depois de uma mudança no site indica chave que deixou de ser enviada.

CRM entra pela mesma porta. Venda fechada por telefone, contrato assinado e compra em loja física podem ser enviados como eventos offline, ligados ao anúncio pelas mesmas chaves. Aqui o cuidado com dados dobra: envie só o que a finalidade pede, guarde o registro do consentimento de cada contato e não mande dados de quem recusou.

Validação operacional junta três ferramentas. A aba de eventos de teste filtra o que chegou por Pixel e por Events API. O Payload Helper, recurso recente do Events Manager, confere o formato do envio. A conferência diária compara eventos com pedidos pagos. Nenhuma delas é instantânea, porque o Events Manager não mostra dados em tempo real.

Limites precisam estar no plano. A integração direta custa semanas de desenvolvimento e depois exige manutenção. Conversões modeladas, estimativas que o TikTok reporta quando a conversão real não é observável, entram no relatório de campanhas otimizadas para eventos do site. O servidor também não conserta um dicionário mal escrito: ele envia com precisão o evento que o plano definiu.

Ordem de trabalho, na página oficial de primeiros passos, começa longe do código. Primeiro, eventos, parâmetros e chaves de correspondência são definidos com marketing, jurídico e tecnologia. Depois vem o método de integração, e a recomendação do TikTok é a Events API como segundo canal ao lado do Pixel, não como substituta. As chamadas da Events API 2.0 exigem um token de acesso, a senha técnica que identifica quem envia.

Armadilha comum: ligar a Events API ao lado do Pixel sem enviar o mesmo event_id pelos dois canais. Cada compra de cartão chega duas vezes, o TikTok não tem como saber que é o mesmo pedido, e o relatório volta a mostrar o dobro de vendas que o Pixel limpo tinha acabado de corrigir.

A Aroeira seguiu o caminho da API direta, porque a integração da Nuvemshop aparece no quadro oficial só com Pixel. Otávio contratou um desenvolvedor, que levou três semanas de abril para montar um serviço ligado ao sistema de pedidos. O serviço envia Purchase quando o pagamento confirma, com event_id igual ao número do pedido, e o Pixel passou a mandar Purchase só para cartão.

Em maio de 2026, o site teve 1.321 pedidos pagos, 41 por cento no Pix, 53 por cento no cartão e 6 por cento no boleto. O Events Manager registrou 1.318 eventos Purchase, uma diferença de 0,2 por cento, dentro da tolerância de 2 por cento do plano. Os 93 pedidos não pagos de abril deixaram de aparecer como venda.

O ganho veio dos dois lados. O lance deixou de aprender com pedido que nunca foi pago e passou a receber o Pix que o navegador perdia. As compras atribuídas subiram de 300 para 324, o CPA reportado caiu de R$ 60 para R$ 55,56 e ficou abaixo do equilíbrio de R$ 58,88, com folga de só 6 por cento, pequena demais para Helena liberar verba nova.

Abra a aba de eventos de teste do seu Events Manager, faça uma compra no cartão e outra no Pix, e confira o canal de cada Purchase. O critério de acerto é um evento por pedido pago, com o mesmo event_id nos dois canais quando os dois enviam. O próximo capítulo compara esses números com o GA4 e com o Seller Center.