Um evento, vários destinos: o que muda de plataforma para plataforma
Mandar a mesma conversão para cinco plataformas parece copiar e colar. Não é: cada uma tem regra própria de hash, formato de identidade e nome de evento — e uma delas faz o contrário de todas as outras.
Depois de resolver o envio pelo servidor para o Meta, a pergunta natural é mandar o mesmo evento para as outras plataformas. Parece um trabalho de copiar e colar com outra URL. Não é — e as diferenças não são cosméticas.
O que segue é o mapa das divergências que realmente quebram integração, levantado implementando os destinos um a um.
O que hashear, e o que não
A regra da família do Meta é conhecida: identidade vai em sha256, nunca em texto puro. É natural assumir que vale para todo mundo. Não vale, em dois sentidos opostos.
| Plataforma | Identidade | A pegadinha |
|---|---|---|
| Meta, TikTok, Snapchat, Pinterest | sha256 | Cada uma hasheia um conjunto diferente de campos |
| sha256, inclusive IP e user agent | É o inverso da família Meta, que manda os dois em claro | |
| Microsoft Ads | sha256, com normalização própria | Remove pontos e apelidos do e-mail antes do hash |
| Klaviyo, HubSpot, Customer.io | Texto puro | Hashear quebra a integração: o e-mail é o produto ali |
A última linha costuma surpreender. Ferramenta de marketing não é plataforma de anúncio: ela precisa do e-mail legível para enviar a mensagem. Hash é regra de leilão de anúncio, não de comunicação.
Não existe uma regra de hash universal. Existe uma regra por destino, e ela precisa estar declarada no destino — não escondida no código que monta o envio.
O nome do evento não viaja igual
Compra é Purchase no Meta, e em outras plataformas o mesmo conceito tem outro nome ou outra forma. O Pinterest espera nomes em minúsculas e chama a compra de checkout. O LinkedIn não trabalha com nome de evento: você referencia um identificador de conversão criado na conta. O TikTok convive com dois formatos de API diferentes, um deles herdado.
O erro clássico aqui é silencioso: mandar um nome que a plataforma não conhece costuma ser aceito como evento personalizado. Nada falha, e a conversão simplesmente não aparece onde você espera.
O formato da identidade
Depois do nome vem a forma. O Pinterest espera os campos de identidade em listas, mesmo quando há um valor só. O LinkedIn espera identificadores tipados, com o tipo declarado ao lado do valor, e o tempo em milissegundos em vez de segundos.
E há uma diferença de comportamento que muda a conta: o LinkedIn descarta o evento que chega sem identidade nenhuma. No Meta, esse evento é aceito e simplesmente não pareia. Nas duas situações você não ganha atribuição, mas só numa delas você fica sabendo.
O que fazer com isso
A conclusão prática não é evitar destinos. É separar duas coisas que costumam vir grudadas: a montagem do evento e as regras do destino.
- O evento é montado uma vez, com a identidade completa e os campos de negócio.
- Cada destino declara o que aceita, o que hasheia e como nomeia — e o envio aplica essa declaração.
- Nome de evento novo passa por uma lista conhecida, para não virar evento personalizado por acidente.
- Destino que descarta evento sem identidade precisa reportar o descarte, não engoli-lo.
Quando essas quatro coisas estão no lugar, acrescentar um destino é preencher uma declaração. Quando não estão, cada destino novo é uma integração do zero — e cada uma envelhece sozinha.
No CrazyLeads cada destino declara o próprio contrato: o payload aceito e a regra de hash por nome de campo. O envio é comum, e é por isso que hoje são mais de vinte destinos server-side com a mesma máquina por baixo.