CDP, GTM server-side e pixel: quem faz o quê
As três mandam evento para o Meta, e é por isso que são confundidas. Mas só uma delas sabe que a visita de terça e a compra de domingo são a mesma pessoa — e essa diferença decide qual você precisa.
Se você pediu orçamento de rastreamento server-side nos últimos meses, recebeu propostas que parecem a mesma coisa por preços que variam dez vezes. A confusão é legítima: as três categorias mandam evento para o Meta. O que elas fazem antes disso é completamente diferente.
| Pixel no navegador | GTM server-side | CDP | |
|---|---|---|---|
| Papel | Coleta o que acontece na página | Recebe e repassa o evento | Guarda, resolve identidade e ativa |
| Tem memória? | Só a sessão atual | Não — cada evento é isolado | Sim: histórico por pessoa |
| Sabe quem é a pessoa? | Enquanto o cookie durar | Só o que vier no evento | Sim, unindo fontes e dispositivos |
| Enxerga venda fora do site? | Não | Só se você mandar | Sim: webhook do checkout, CRM, e-mail |
| Dá para perguntar aos dados? | Não | Não | Sim — é uma base, não um cano |
GTM server-side é transporte, e isso não é defeito
Um contêiner de GTM hospedado num servidor recebe o evento, aplica regras e repassa para os destinos. É um roteador muito bem feito, e resolve de verdade o problema de bloqueador de anúncio e restrição de navegador.
O que ele não faz é lembrar. Cada evento entra e sai. Se a pessoa visitou na terça de um celular e comprou no domingo pelo notebook, não existe nada no contêiner que ligue as duas coisas — porque não é isso que ele foi feito para fazer.
Comparar GTM server-side com CDP é comparar um roteador com um banco de dados. Os dois são necessários em momentos diferentes, e nenhum substitui o outro.
O pixel é coleta, e continua fazendo falta
Existe uma ideia circulando de que server-side substitui o pixel do navegador. Não substitui: o navegador é o único lugar que sabe o que a pessoa viu, quanto rolou a página e quando abandonou. O servidor sabe o que foi confirmado.
A implementação boa usa os dois com o mesmo identificador de evento, para o Meta contar uma vez só. A implementação ruim liga a CAPI, mantém o pixel sem deduplicar e comemora um faturamento que não existe.
A CDP é memória, identidade e ativação
Uma plataforma de dados de clientes faz três coisas que as outras duas não fazem: guarda o histórico, decide que eventos diferentes pertencem à mesma pessoa e devolve esse resultado para as ferramentas onde a decisão acontece.
A parte difícil é a do meio. Ligar a visita anônima de terça ao formulário de quarta e à compra de domingo — em dispositivos diferentes, com e-mails diferentes — é o trabalho que separa a categoria. E é ele que faz a CAPI parar de mandar evento sem e-mail: quando a compra chega, a plataforma já sabe quem é.
Qual escolher, sem enrolação
- 01Você precisa repassar poucos eventos de um site próprio para o Meta e o Google, e a venda acontece no mesmo site. Hospedagem de GTM server-side resolve, custa menos e é o caminho mais curto.
- 02A venda acontece fora do seu site — checkout de terceiro, WhatsApp, vendedor — e você precisa ligar essa venda à origem. Aqui GTM server-side não alcança, porque falta a memória.
- 03Você quer perguntar coisas aos dados, e não só enviá-los. A partir do momento em que a pergunta é "quem" e não "quantos", você está falando de CDP.
O teste de uma pergunta só
Se ficou em dúvida sobre o que você tem hoje, faça esta pergunta à sua ferramenta atual: quem foi a pessoa que comprou hoje de manhã, e por onde ela passou nos últimos trinta dias?
Se a resposta for um número agregado, você tem analytics. Se for "o evento foi entregue", você tem transporte. Se for uma linha do tempo com nome, e-mail, anúncio de origem e as visitas até a compra, você tem uma CDP — e aí a conversa sobre CAPI fica muito mais simples, porque o dado que falta ao envio já está guardado.