Rastreamento server-side e Consent Mode v2: como medir com dados primários e consentimento
Server-side tagging leva a coleta do navegador para um servidor da empresa. Veja como combinar GTM server-side, APIs de conversão e Consent Mode v2.

Rastreamento server-side, ou server-side tagging, é a arquitetura em que os eventos de um site ou aplicativo passam por um servidor controlado pela empresa antes de seguir para ferramentas de análise e plataformas de mídia. No modelo tradicional, o client-side, cada tag roda no navegador do visitante e envia dados diretamente ao seu fornecedor. No server-side, a empresa recebe os dados primeiro e decide o que repassar, para quem e em qual formato.
Consent Mode v2 é o mecanismo do Google que transmite às tags a escolha de consentimento de cada pessoa. Com servidor próprio e APIs de conversão, forma a base de uma medição que usa dados primários e respeita o que o usuário autorizou. Este guia explica cada peça e o que lideranças de marketing e dados precisam decidir antes de implantar.
O que é server-side tagging e como difere do client-side
No client-side, o navegador carrega o código de cada ferramenta, como análise e pixels de mídia, e cada script envia ao próprio destino o que lê da página. A empresa vê pouco do que sai de fato.
No server-side, o contêiner de servidor, segundo a documentação do Google Tag Manager, não roda no navegador nem no telefone do usuário, e sim em um servidor sob controle do anunciante, e os dados que chegam a ele ficam acessíveis à empresa até que ela decida enviá-los a outro lugar. A documentação também recomenda instalar esse servidor em um domínio próprio antes de receber tráfego de produção.
Na prática, campos podem ser removidos ou transformados antes de cada envio, e o servidor passa a ser infraestrutura com custo e dono. Server-side não substitui o consentimento: o ganho é controle e governança, não um atalho.
O contêiner server-side do Google Tag Manager
O GTM server-side usa o mesmo modelo de tags, acionadores e variáveis do contêiner web. A peça nova são os clientes: adaptadores que recebem as requisições que chegam ao servidor e as convertem em eventos, que tags de servidor encaminham ao Google Analytics, às plataformas de mídia ou ao data warehouse.
O servidor pode rodar no Google Cloud ou em outro ambiente escolhido pela empresa. O guia de configuração no Cloud Run recomenda no mínimo duas instâncias para reduzir o risco de perda de dados em quedas, além de estimativa de custo e alertas de faturamento. É um custo recorrente, que cresce com o tráfego e precisa de orçamento e de responsável.
APIs de conversão: o servidor falando com as plataformas
As APIs de conversão das plataformas enviam eventos do servidor da empresa diretamente à plataforma de mídia, sem depender exclusivamente do navegador.
A Conversions API da Meta envia dados de marketing a partir do servidor do anunciante e aceita eventos do site, do aplicativo, de mensagens e conversões offline. Segundo a documentação, eventos de servidor vinculados a um conjunto de dados são processados como os enviados pelo Pixel da Meta.
As conversões otimizadas do Google Ads, em inglês enhanced conversions, complementam as tags de conversão com dados primários do cliente, como e-mail ou telefone, transformados por hash SHA256 antes do envio. Há uma variante para conversões no site e outra para leads que fecham fora dele.
O dado mais útil para otimizar mídia, como a venda no ERP ou a oportunidade qualificada no CRM, nasce fora do navegador. O artigo sobre CRM e receita detalha como definir essas etapas.
Deduplicação entre navegador e servidor
Quando o mesmo evento é enviado pelo navegador e pelo servidor, o que a Meta chama de configuração redundante, a plataforma precisa reconhecer as duas cópias como um único evento. A documentação de deduplicação da Meta recomenda enviar o mesmo nome e o mesmo identificador de evento nas duas origens, e informa que a deduplicação por identificador vale para eventos recebidos em até 48 horas do primeiro. Sem essa chave, uma compra pode ser contada duas vezes.
Consent Mode v2: o que é e por que importa
O Consent Mode, ou modo de consentimento, transmite ao Google as escolhas do usuário sobre cookies e identificadores, e as tags ajustam o comportamento a elas. Ele não exibe banner e funciona com a ferramenta de consentimento que a empresa já usa, como explica a central de ajuda do Google Ads.
A documentação para desenvolvedores registra que o recurso foi atualizado em novembro de 2023 com dois parâmetros adicionais. Os tipos de consentimento principais passaram a ser ad_storage (cookies para publicidade), analytics_storage (armazenamento para análise), ad_user_data (envio ao Google de dados do usuário relacionados à publicidade) e ad_personalization (publicidade personalizada).
A página do Google sobre gestão de consentimento acrescenta que ad_user_data é exigido para mensuração como conversões otimizadas e conversões por tag, e que publicidade personalizada depende de ad_user_data e ad_personalization concedidos.
Modo básico e modo avançado
- Básico: as tags do Google não carregam até que a pessoa interaja com o banner. Sem consentimento, nenhum dado é transferido ao Google, nem mesmo o status do consentimento.
- Avançado: as tags carregam quando a página abre, com consentimento negado por padrão. Enquanto ele estiver negado, enviam medições sem cookies; depois do consentimento, enviam a medição completa.
Segundo a explicação conceitual do Google, o modo avançado permite um modelo de conversões específico do anunciante, e o básico usa um modelo geral. A escolha envolve privacidade e risco e deve ser feita com o jurídico.
Por que a Europa puxou o tema e por que empresas brasileiras também adotam
A política de consentimento de usuários da UE do Google exige que anunciantes obtenham consentimento legalmente válido de usuários do Espaço Econômico Europeu, do Reino Unido e da Suíça para cookies, quando a lei exigir, e para personalização de anúncios, guardando registros desse consentimento. A documentação do Consent Mode associa a atualização de 2023 ao reforço dessa política.
No Brasil, a Lei Geral de Proteção de Dados, Lei 13.709/2018, define consentimento como manifestação livre, informada e inequívoca para uma finalidade determinada (art. 5º). Entre os princípios do art. 6º está a necessidade, que limita o tratamento ao mínimo necessário. O art. 7º lista as hipóteses que autorizam o tratamento, entre elas o consentimento e o legítimo interesse, e o art. 8º considera nulas as autorizações genéricas.
Por isso empresas brasileiras também adotam medição sensível a consentimento: banner, sinais enviados às tags e o que o servidor repassa precisam contar a mesma história. A base legal de cada tratamento é decisão do jurídico e do encarregado de dados (DPO), e este texto não é orientação jurídica.
Dados primários: o que são e onde entram
Dados primários, ou first-party data, são os dados que a empresa coleta diretamente na relação com clientes e visitantes: eventos no site e no aplicativo, cadastros, compras, atendimento e CRM. Dados de terceiros, ao contrário, são coletados por outra organização.
O servidor próprio é onde esses dados ganham regra: recebe os eventos em domínio da empresa, aplica consentimento e minimização e alimenta plataformas e data warehouse. O artigo sobre governança de dados de marketing trata dos responsáveis por esse trabalho.
Governança: quem é dono do servidor e do dado
- Dono do servidor: área responsável, contrato de nuvem, orçamento recorrente e monitoramento.
- Controle de mudanças: quem publica versões do contêiner, com revisão e histórico.
- Minimização: campos permitidos por destino e remoção de dados pessoais que aparecem por acidente, como e-mails em URLs.
- Consentimento de ponta a ponta: o sinal do banner chega às tags web, ao servidor e às APIs.
- Papéis e contratos: quem é controlador e quem é operador em cada fluxo, com contratos revisados pelo jurídico.
Passo a passo de uma implantação
- Inventarie as tags atuais: o que cada uma coleta e para onde envia.
- Defina com jurídico e DPO finalidades, bases legais e comportamento por categoria de consentimento.
- Desenhe o plano de eventos e o dicionário de dados.
- Suba o servidor em domínio próprio, com ambiente de teste.
- Migre os destinos em ondas e compare os números em paralelo com a coleta antiga.
- Conecte as APIs de conversão com deduplicação e eventos do CRM.
- Implante o Consent Mode v2 e valide os sinais em cada estado de consentimento.
- Monitore volume de eventos por origem, divergências e custo do servidor.
Erros comuns
- Tratar server-side como forma de contornar bloqueadores ou recusas de consentimento.
- Enviar o mesmo evento pelo navegador e pelo servidor sem identificador comum.
- Repassar ao servidor tudo o que o navegador coletava, sem revisar os campos.
- Subir o servidor sem dono, sem orçamento e sem alerta de custo.
- Configurar o Consent Mode com categorias diferentes das que o banner mostra.
- Comparar antes e depois sem período paralelo, atribuindo à arquitetura variações do mercado.
Exemplo hipotético: uma implantação em três ondas
O caso a seguir é hipotético e ilustrativo, sem dados de clientes ou de mercado. Imagine um fabricante de equipamentos com e-commerce para revendedores, leads de grandes contas e tráfego no Brasil e em Portugal.
Na primeira onda, o time sobe o servidor em um subdomínio próprio e envia os eventos de análise por ele, com a coleta antiga em paralelo por algumas semanas. No caminho, encontra formulários que enviavam e-mails em parâmetros de URL, agora removidos no servidor.
Na segunda, conecta a Conversions API da Meta e as conversões otimizadas do Google Ads, com um identificador por evento enviado pelos dois caminhos. O CRM passa a devolver às plataformas a oportunidade qualificada, além do formulário preenchido.
Na terceira, jurídico e DPO definem o comportamento por região: para Portugal, consentimento negado por padrão; para o Brasil, a configuração que segue a base legal escolhida. Ao final, a empresa tem um mapa de quem envia o quê, para onde e sob qual autorização, e um número de conversões que plataformas e CRM conseguem reconciliar.
Perguntas frequentes sobre rastreamento server-side e Consent Mode v2
O que é GTM server-side?
É o uso do Google Tag Manager com um contêiner que roda em um servidor controlado pela empresa, e não no navegador do visitante. O navegador envia os eventos a esse servidor, que os recebe por meio de clientes, aplica regras e encaminha cada evento a ferramentas de análise e plataformas de mídia, conforme o que a empresa decidir.
Server-side tagging dispensa o consentimento?
Não. Mudar o local onde a tag roda não altera as obrigações sobre o dado pessoal: se a coleta depende de consentimento no navegador, continua dependendo no servidor. O server-side ajuda a cumprir regras, porque permite remover campos e controlar destinos, mas não serve para contornar a recusa do usuário. Bases legais são definidas pelo jurídico e pelo DPO.
Qual a diferença entre Consent Mode básico e avançado?
No básico, as tags do Google não carregam até que a pessoa responda ao banner; sem consentimento, nada é enviado ao Google. No avançado, as tags carregam com consentimento negado por padrão e enviam medições sem cookies até que haja consentimento. Segundo o Google, o avançado permite um modelo de conversões específico do anunciante. A escolha deve ser feita com o jurídico.
Empresas que atuam no Brasil precisam do Consent Mode v2?
A política de consentimento do Google trata de usuários do Espaço Econômico Europeu, do Reino Unido e da Suíça, então empresas brasileiras com tráfego dessas regiões precisam considerá-la. Para o público brasileiro, a LGPD exige finalidade, necessidade e base legal para cada tratamento. Usar o Consent Mode para refletir o banner nas tags é decisão do jurídico e do DPO.
O que são dados primários (first-party data)?
São os dados que a empresa coleta diretamente na relação com clientes e visitantes: eventos no site e no aplicativo, cadastros, compras, atendimento e CRM. Diferem dos dados de terceiros, coletados por outras organizações. Para servirem à mídia e à análise, precisam de finalidade clara, consentimento quando exigido e um responsável pela qualidade.
Para estruturar essa camada de medição, conheça a frente Dados.