Sou o Marcelo Marcondes, CEO e fundador da Vince Marketing. Na implementação de server side tagging, você fala direto comigo: quem atende e responde pelo seu projeto sou eu, com o time completo atrás. Você recebe o servidor funcionando, a documentação do que é medido e a infraestrutura no nome da sua empresa.
Esta página é para quem investe em mídia, desconfia dos números que as plataformas recebem e quer alguém responsável pela entrega.
Server side tagging resolve o quê (e o que não resolve)
No rastreamento comum, o navegador do visitante envia os dados direto para o Google, a Meta e as outras plataformas. No server side tagging, o navegador envia os dados para um container em um servidor, e é esse servidor que repassa os eventos às plataformas.
Na minha experiência, o que isso muda na prática:
- você decide, em um único ponto, o que sai para cada plataforma;
- o mesmo evento pode alimentar mais de um destino sem repetir a configuração no site;
- a conta do servidor e o endereço de envio ficam sob o seu controle.
O que não muda:
- não cria dado que o site não gera: se o evento não existe, o servidor não o inventa;
- não corrige evento mal definido: se “lead” conta qualquer clique, o servidor vai enviar esse erro com mais eficiência;
- não garante venda nem barateia a campanha por si só.
Por isso a primeira etapa do meu trabalho é olhar o que já está rastreado, não ligar um servidor.
Quando vale implementar e quando não vale
Decido com critérios qualitativos. Costuma valer quando:
- há verba de mídia constante, com decisões tomadas em cima dos números das plataformas;
- venda ou lead têm valor definido, e a empresa sabe o que conta como resultado;
- há motivo para suspeitar de perda de dados, por exemplo conversões que o seu CRM registra e as plataformas não enxergam;
- o GTM e o GA4 já funcionam e estão organizados.
Não vale agora quando:
- você está começando do zero, sem verba de mídia própria e sem produto validado;
- o volume é tão baixo que nenhuma decisão muda com mais precisão de dado;
- o básico não existe: sem GTM e GA4 funcionando, o servidor só adiciona uma camada sobre uma base frágil. Nesse caso o caminho começa por implementar o Google Tag Manager e o GA4;
- o problema real é a página que não converte ou o comercial que não responde o lead. Mais precisão de dado não resolve isso.
Se for o seu caso, eu digo na conversa, mesmo que signifique não vender a implementação.
Server side, Google Tag Gateway ou só o client side: como decido
São três caminhos, e cada um atende a um perfil. Esta é a minha lógica de decisão:
| Situação | Caminho que costumo considerar |
|---|---|
| Pouca verba, poucos eventos, básico recém-configurado | Manter o client side bem feito e medir antes de complicar |
| Usa só o Google e quer pouca mudança de arquitetura | Avaliar o Google Tag Gateway, o que faço no diagnóstico, olhando o seu caso |
| Várias plataformas recebendo dados (Google Ads, GA4, Meta) e necessidade de controlar o que cada uma recebe | Server side tagging |
| Dados de CRM ou de venda que precisam chegar às plataformas | Server side tagging |
Critérios que uso:
- Quantos destinos recebem dados. Um destino só raramente justifica um servidor. Vários, sim.
- Quanto controle você precisa sobre o que sai. Se precisa filtrar ou padronizar eventos antes do envio, o servidor entrega isso.
- Quem vai manter. Um servidor em nuvem exige acompanhamento. Se ninguém vai cuidar, o client side bem feito é mais honesto.
- O estágio da medição. Antes de qualquer um dos três, o plano de eventos precisa estar correto.
Não existe resposta única. Recomendo depois de olhar o seu rastreamento atual, e a auditoria de rastreamento é o ponto de partida natural.
Como é a implementação de server side tagging, passo a passo
Cada etapa tem um critério de “pronto”. Sem ele, a etapa não fecha.
- Diagnóstico do que já está rastreado. Levanto tags, eventos e conversões existentes nas plataformas. Pronto quando: há um inventário do que dispara, onde e com qual nome.
- Plano de eventos. Defino com você quais eventos importam (lead qualificado, pedido, agendamento), com nomes e parâmetros padronizados. Pronto quando: você aprovou o que conta como resultado.
- Container server no GTM. Crio o container do servidor, separado do container web. Pronto quando: o servidor recebe os eventos de teste do container web.
- Provisionamento do servidor. Subo o servidor em nuvem, em conta no nome da sua empresa. Antes de seguir, confiro se você tem acesso de administrador e se há pelo menos um responsável seu cadastrado, para a infraestrutura nunca depender de mim. Pronto quando: o servidor responde e o acesso está confirmado.
- Domínio próprio. Configuro um subdomínio da sua empresa para o envio de dados. Pronto quando: o container web envia os eventos ao seu subdomínio.
- Migração das tags, uma plataforma por vez. Começo pela que tem o evento mais simples e a conferência mais fácil, e deixo a Meta para depois, porque exige cuidado extra com duplicidade. Não desligo o envio antigo antes de conferir o novo. Se a contagem do servidor diverge da antiga, não publico: investigo primeiro duplicidade, depois evento que deixou de disparar. Pronto quando: cada plataforma recebe os eventos pelo servidor, sem duplicidade e com divergência explicada.
- Testes. Uso os modos de pré-visualização do GTM e as ferramentas de diagnóstico de cada plataforma. Pronto quando: cada evento do plano aparece uma vez, com os parâmetros certos.
- Publicação. Publico com registro de versão, mantendo a configuração anterior à mão para voltar atrás se algo se comportar mal. Pronto quando: os dados em produção batem com os testes.
Aqui eu trato só do container do servidor; o container web segue a lógica da página de Google Tag Manager.
Envio para Google Ads, GA4 e Meta no mesmo fluxo
Com o servidor no meio, um evento do site alimenta vários destinos a partir de um único ponto:
- GA4: recebe os eventos do plano, para análise de comportamento e origens.
- Google Ads: recebe as conversões que você definiu como meta de otimização.
- Meta: recebe os eventos pelo servidor, ligados à API de Conversões, complementando o pixel.
O ponto de atenção é a duplicidade. Pela documentação da Meta para desenvolvedores, o recomendado é usar a API de Conversões junto com o pixel, e o evento do pixel e o da API devem ter o mesmo nome e o mesmo event_id. O detalhe da configuração fica na página de implementação da API de Conversões da Meta.
Em um caso que acompanhei, Google Ads e Meta combinados fizeram diferença.
Quer saber se o seu cenário pede servidor ou não? Peça uma conversa de diagnóstico, sem custo e sem compromisso: olho o seu rastreamento e digo o que eu faria.
Como validamos que os dados estão certos
Implementar não basta; é preciso conferir. A validação tem três frentes:
- Antes e depois. Antes de migrar, registro quantas conversões cada plataforma e o seu CRM mostram em um período. Depois, comparo em janela equivalente. Diferença pequena entre plataformas é esperada, porque cada uma atribui de um jeito; procuro buracos e saltos sem explicação.
- Duplicidade. No Gerenciador de Eventos da Meta e nos relatórios de conversão do Google, confiro se cada evento chega uma vez só.
- Parâmetros. Verifico se os eventos chegam com valor, moeda e os identificadores que cada plataforma pede.
Quando CRM e plataforma divergem, a ordem de investigação que sigo é: primeiro duplicidade, depois evento que deixou de disparar, depois diferenças de janela e de critério de atribuição. Só então considero que o dado realmente se perde.
Isso pesa na otimização. Em sua documentação para anunciantes, a Meta indica que o conjunto de anúncios precisa de um mínimo de cerca de 50 eventos de otimização em 7 dias para estabilizar o aprendizado. Se os eventos chegam incompletos ou duplicados, o volume que a plataforma enxerga não é o real.
Para saber de onde vêm os leads depois que o dado está correto, veja como saber de onde vem o lead.
O que você recebe e o que fica com você
Ao fim da implementação, você recebe:
- Documentação do plano de eventos: o que é medido, com que nome, em que momento e para onde vai;
- Documentação da arquitetura: como o container web, o container server, o subdomínio e o servidor se ligam, para que qualquer pessoa consiga dar continuidade;
- Registro do que foi migrado e testado, plataforma por plataforma.
E a propriedade é sua:
- a conta de anúncios, o pixel e o servidor ficam sempre no nome da sua empresa;
- você tem acesso total o tempo todo;
- o responsável é o mesmo do início ao fim do contrato.
Se a relação com um fornecedor terminar, a infraestrutura continua sua. Vale fazer esta pergunta a quem for implementar: de quem é o servidor?
Quem faz a implementação: o dono, com a estrutura completa atrás
Você não passa por um atendimento intermediário: eu defino o plano e respondo pela entrega. A estrutura completa de uma agência fica atrás de mim, para o que vai além do servidor, como mídia, criativo e conteúdo, sem você precisar coordenar fornecedores.
São 15 anos de mercado e R$ 10M+ gerados em receita digital. Os resultados abaixo vieram de várias frentes, com o tráfego pago como parte da estratégia, junto com CRM, processo comercial, site, conteúdo e oferta:
- Taqe: +600% de receita em 6 anos.
- Vitao: −59% de custo de aquisição.
- Vendizap: +162% de leads qualificados.
- Live University: 66% mais oportunidades de venda.
Para um panorama do que a mensuração cobre, veja a página de mensuração.
Prazo, investimento e próximo passo
Os primeiros sinais aparecem logo depois da publicação: eventos chegando às plataformas, sem duplicidade e com os parâmetros certos. O que isso vira em campanha depende da sua verba, do seu ciclo de venda e da sua meta. Antes do contrato eu alinho uma previsão realista do seu caso, e só fecho com quem está de acordo com ela. Não há garantia de venda: há método, validação e um responsável que explica cada decisão.
O orçamento da implementação depende do seu cenário e sai na conversa. Para entender o que faz o valor variar, veja quanto custa o server side tagging.
Peça a auditoria gratuita do seu rastreamento: uma conversa de diagnóstico, sem custo e sem compromisso. Falo direto com você, em até 1 dia útil. Quero uma conversa de diagnóstico.