Um e-commerce brasileiro chegou até nós com um problema que parecia de mídia, mas era de engenharia de dados. As campanhas de Meta Ads entregavam resultado abaixo do esperado, o CAC não fechava e o Gerenciador de Eventos acusava uma cobertura baixa, na casa dos 35%. A leitura interna era a de sempre: culpa da campanha. Mas a campanha só conseguia trabalhar com o que a estrutura de dados entregava, e essa estrutura entregava pouco.
A operação rodava em uma arquitetura headless, com a plataforma de e-commerce (VTEX) atuando como back-end e um front-end desacoplado servindo a loja ao usuário. Essa separação, ótima para performance e escala, criava um efeito colateral silencioso: os dados primários do usuário (e-mail, telefone, identificadores) ficavam retidos no back-end e não trafegavam até a camada onde o Google Tag Manager conseguia capturá-los. Na prática, o contêiner instalado no site enxergava o evento de compra, mas não enxergava quem comprou. Sem esse dado, o sinal enviado à Meta e ao Google Ads nascia pobre.
A premissa que quase nos levou pelo caminho errado
O cliente chegou com a solução já decidida: implementar a API de Conversões da Meta através do Conversions API Gateway. É a recomendação padrão da plataforma, e por isso mesmo raramente é questionada.
Aqui entra uma parte do nosso trabalho que costuma ser invisível no relatório final: a mediação técnica. Boa parte da entrega da Métricas Boss está em entender o que o cliente precisa antes de executar o que ele pede. O Gateway, da forma como a Meta o recomenda, depende do Pixel Web para iniciar o fluxo. Se um bloqueador de anúncios impede a execução do Pixel no navegador, todo o resto da cadeia é interrompido junto. A redundância prometida some justamente no cenário em que ela deveria proteger o dado.
Ou seja: o Gateway resolveria a parte burocrática da implementação e deixaria a causa do problema de pé. A raiz estava na estrutura de dados, e era ali que precisávamos agir. Devolver ao cliente o controle sobre o próprio dado pedia uma camada de coleta nova, algo que nenhum atalho de configuração entregaria.
A arquitetura de Google Tag Manager Server Side que desenhamos
A solução foi montar uma camada de Google Tag Manager Server Side entre o contêiner client-side (cGTM) e as plataformas de destino. Essa camada resolveu o gargalo por três frentes que se somam.
- •Servir o contêiner em contexto first-party
Uma das formas mais comuns de os bloqueadores identificarem e cortarem o rastreamento é pela URL do request. Qualquer coisa que carregue de tagmanager.com ou de domínios reconhecidos como de rastreamento vira alvo. Usando a técnica de script serving do GTM Server Side (a mesma lógica hoje formalizada pelo Google no Google Tag Gateway for advertisers), passamos a carregar o contêiner a partir de um subdomínio do próprio cliente, como cgtm.example.com e sgtm.example.com. Com isso, o tráfego de dados acontece dentro do domínio primário da loja, com a aparência de um recurso qualquer do próprio site. Para o bloqueador, cortar esse request significaria arriscar quebrar a experiência do usuário, o que muda a equação a nosso favor.
- •Transformar e criptografar o dado no servidor.
Com a camada server-side no meio do caminho, ganhamos um ambiente controlado para tratar o dado antes de ele sair. Foi aí que resolvemos o gargalo original. Investigando o front-end, o localStorage e as variáveis globais definidas no JavaScript da aplicação, encontramos uma variável que a própria equipe do cliente não sabia que existia e que trazia os dados do usuário sem criptografia. Sem uma camada server-side na frente, esse dado jamais poderia ser enviado à Meta, porque iria ser descriptografado. Com ela, aplicamos o hash SHA-256 na camada de transformação e garantimos que apenas o dado tratado seguisse adiante.
- •Unificar o gatilho de todas as plataformas.
Em vez de cada plataforma disparar sua própria tag no navegador, passamos a usar um único evento do GA4 como acionador, distribuído pelo GTM Server Side para Meta Ads, Google Ads e GA4 a partir da mesma fonte e do mesmo dado. Isso resolve um problema clássico e mal diagnosticado: a discrepância de conversões entre plataformas. Quando cada pixel dispara de forma isolada no client, uma condição de corrida (o usuário fecha a página antes de todas as tags carregarem) faz uma plataforma registrar a conversão e outra não. Cada relatório passa a reivindicar um percentual de conversão incompatível com o das outras. A partir de um gatilho único, a distribuição das conversões entre os canais fica muito mais homogênea.
Para os eventos transacionais, fomos além do client. A VTEX permite notificar um endpoint sempre que o status de um pedido muda, via Order Hook. Construímos uma client tag de GTM Server Side que transforma o contêiner em um webhook genérico, capaz de receber esses dados server-to-server diretamente da plataforma de e-commerce, sem depender do navegador do usuário. A tag está disponível como template aberto:
Server-to-server é, tecnicamente, a forma mais confiável de garantir a coleta. Um servidor conversando com outro servidor elimina toda a fragilidade do lado do cliente: conexão instável, aparelho lento, aba fechada antes do carregamento, extensões de privacidade. O dado da compra sai da VTEX e chega à Meta sem passar pela loteria do navegador.
Além da cobertura: a qualidade da correspondência
Resolver a cobertura de eventos foi a metade do trabalho. Segundo a própria documentação da Meta, cobertura de eventos é a média de eventos do Pixel que também são cobertos pela API de Conversões compartilhando a mesma chave de deduplicação, com 75% como patamar recomendado. É importante, mas é apenas presença: garante que o evento chegou pelos dois lados.
O que de fato move o ponteiro do algoritmo é a qualidade da correspondência de eventos (Event Match Quality). E é aqui que o dado PII faz a diferença. Existe uma hierarquia clara nos identificadores que a Meta usa para conectar um evento a um perfil real: o _fbp (browser ID) e o _fbc (click ID), que vêm dos cookies do Pixel e não devem ser criptografados, e, num segundo nível de peso, telefone e e-mail criptografados. Quando enviamos o e-mail e o telefone com hash junto do click ID, damos à Meta o que ela precisa para reconhecer que aquele usuário que comprou no site é a mesma pessoa que tem uma conta no Instagram ou no Facebook. Foi essa combinação, cobertura mais correspondência, que destravou o resultado de mídia.
A analogia que fazemos internamente ajuda a entender: enriquecer o algoritmo da Meta é como enriquecer uma IA com contexto. O modelo só correlaciona bem o que consegue enxergar. Quanto melhor o sinal que você entrega, melhor a plataforma encontra quem tem real probabilidade de converter.
Precisamos mesmo duplicar tudo?
Antes de fechar a estrutura final, testamos enviar os eventos apenas via server-to-server, direto da VTEX pelo webhook. O teste também reduziu o CAC e provou o ponto técnico: o server-side, sozinho, é a fonte mais robusta. Mas a Meta acusou discrepância de cobertura, porque faltavam os eventos client-side para casar com os do servidor.
Isso nos deixou com uma pergunta legítima, que exploramos em profundidade no artigo complementar: se a implementação faz parte de um ambiente mais seguro e controlado, faz sentido duplicar o evento de propósito só para cumprir uma métrica de cobertura? A resposta prática, para quem precisa operar dentro do padrão da plataforma hoje, é sim: mantivemos o disparo pelos dois lados, com o mesmo event_id garantindo a deduplicação (a Meta desduplica pela combinação de event_id e nome do evento). O papel da consultoria foi seguir o standard e, ao mesmo tempo, construir a camada server-side como espinha dorsal real da coleta, com peso próprio na arquitetura.
Os resultados:
Com a estrutura mista de client e server rodando sobre a camada first-party:
- •Cobertura de eventos de 35% para 90%.
- •Cobertura de dados PII(dados sensíveis) em torno de 85%, limitada apenas pelas jornadas em que o usuário conseguia comprar sem se autenticar.
- •Redução de 15% no CAC do Meta Ads no período em que a estrutura esteve ativa.
O teto de 85% no dado PII apontou o próximo passo. Em operações com jornada logada, a cobertura de identificadores tende a se aproximar do total, porque o e-mail está disponível em toda compra. Modelos que exigem login para ver preço, ativar desconto ou finalizar o pedido colhem esse dado por padrão. Para os fluxos de checkout como convidado, a conversa passa a ser de produto e incentivo: vale adicionar uma fricção de login em troca de um benefício para qualificar o usuário mais cedo na jornada.
O que o dado enriquecido destrava?
O ganho de CAC é a manchete, mas o valor estratégico é maior. Com os sinais certos, a marca ganha condição de operar perto do marketing um para um. Dá para clusterizar públicos pelo comportamento real de quem comprou, e também de quem chegou perto e não comprou.
O uso mais imediato e mais ignorado disso é a gestão da janela de compra. Continuar impactando com anúncio quem acabou de converter é queimar orçamento. Analisando os dados de venda para entender a taxa de recompra de cada categoria, é possível invalidar dentro da Meta o público que já comprou pelo período em que ele não voltaria a comprar, e redirecionar essa verba para prospects parecidos. Um produto de consumo mensal e um bem de ticket alto pedem janelas completamente diferentes, e só o dado bem estruturado permite tomar essa decisão.
No fim, a lição deste case é sobre origem: o resultado de mídia começa muito antes da campanha, na arquitetura que decide se o dado do cliente chega íntegro ou pela metade.
Métricas Boss
Especialista em Digital Analytics com experiência em transformar dados em estratégia.
Publicado em 27 de julho de 2026
