O GTM server-side é uma forma de medir a atividade do usuário em que parte das tags roda em um servidor seu, e não só no navegador do visitante. O Google lista como benefícios melhor desempenho de página, mais controles de privacidade e melhor qualidade de dado. Mas mover a tag para o servidor não elimina a necessidade de consentimento.

A documentação do Google mostra isso de um jeito prático: o servidor depende do sinal de consentimento que sai do aviso no navegador. Este artigo explica o que é o recurso, como o consentimento chega ao servidor e quais perguntas de privacidade surgem, dentro da trilha de atribuição com privacidade.

Na página do Google, o servidor usa o mesmo modelo de tags, acionadores e variáveis do Tag Manager comum. Quem já usa o GTM conhece a lógica; muda o lugar onde ela roda. Em vez de cada tag enviar dados direto do navegador a cada plataforma, o navegador envia a um contêiner no seu servidor, e as tags do servidor repassam o que for decidido.

A página diz que o servidor de tags pode ser montado na Google Cloud ou em outra plataforma à escolha, com guias para Cloud Run, App Engine e instalação manual. Ela não traz custos. Também não explica em texto o fluxo entre o navegador e o servidor, e por isso este artigo não descreve esse fluxo além do que a página de consentimento confirma.

Entre os benefícios, a página fala em desempenho, controles de privacidade e qualidade de dado, sem detalhar como cada um funciona. "Controles de privacidade" significa mais poder de decisão sobre o que sai do seu servidor, e não uma dispensa de pedir autorização. A página não diz que o servidor dispensa o consentimento, e este artigo não afirma isso.

A página do Google sobre consentimento no GTM server-side descreve o caminho: o aviso de cookies envia a escolha do visitante à tag do Google no contêiner web, e essa tag repassa a escolha ao contêiner do servidor como parâmetros da requisição HTTP. Por isso, diz a página, o Consent Mode só precisa ser configurado no contêiner web.

O Consent Mode não traz aviso nem widget: ele conversa com a sua CMP. A escolha continua nascendo no aviso, e o servidor só a recebe.

Segundo a página, as tags de produto do Google no servidor reconhecem o consentimento e ajustam a quantidade e o tipo de dado que enviam. Alguns exemplos que ela traz:

• Google Analytics: com analytics_storage negado no modo básico, as tags ficam totalmente bloqueadas; no avançado, elas carregam em todas as páginas e ajustam o comportamento.
• Conversões do Google Ads: com ad_storage negado, cookies não são gravados nem lidos, e um pixel de conversão é enviado a um domínio sem cookies de terceiros.
• Remarketing do Google Ads e Floodlight: com ad_storage negado, as requisições HTTP e o uso de cookies são bloqueados.

Para as tags de conversão do Google Ads e do Floodlight, a página diz que é preciso instalar a tag Conversion Linker no contêiner do servidor. E os contêineres do servidor aceitam os dois modos, básico e avançado. A diferença entre eles está no artigo sobre Consent Mode básico ou avançado.

Três pontos sustentam a afirmação, e todos vêm de páginas lidas para este texto.

1. O servidor depende do sinal do navegador. A documentação do Google faz as tags do servidor reagirem aos parâmetros de consentimento enviados pelo contêiner web. Se o servidor dispensasse o consentimento, não precisaria receber o sinal.
2. As plataformas continuam exigindo. Nos termos das ferramentas de negócios da Meta, onde a lei exige consentimento esclarecido para cookies, o anunciante deve garantir, de forma verificável, que o usuário deu os consentimentos necessários antes do uso das ferramentas. O artigo sobre API de Conversões trata disso.
3. A lei olha para a finalidade, e não para o lugar onde a tag roda. A LGPD define consentimento como manifestação livre, informada e inequívoca para uma finalidade determinada (art. 5º, XII), e dado pessoal como a informação ligada a pessoa identificável (art. 5º, I). Nada nesses artigos muda porque o envio passou do navegador para o servidor.

As páginas do Google lidas não dizem se carregar o contêiner de tags exige consentimento em si, nem como o servidor se enquadra na LGPD. Também não trazem os parâmetros técnicos que indicam o estado do consentimento nas requisições, e por isso este artigo não os descreve. Se o seu jurídico precisa dessa resposta, ela depende do que o seu contêiner faz, e não de uma regra geral.

O servidor muda o lugar do controle. No navegador, você depende do que cada tag faz. No servidor, você escolhe quais campos repassar e para quem, e isso abre espaço para aplicar o mínimo necessário (LGPD, art. 6º, III).

Ter controle sobre o que sai do servidor também significa responder por isso. Um filtro que remove campos desnecessários é uma boa prática de minimização. Já um servidor que repassa tudo o que recebe só mudou o endereço do problema. A pergunta de cada campo é a mesma: qual finalidade o justifica e o visitante aceitou essa finalidade?

• Mapeie os dados que passam pelo servidor. O mapeamento de dados ajuda a saber o que entra e o que sai.
• Defina quem hospeda, e atualize a política de privacidade se um novo operador entrar na cadeia.
• Teste a recusa: recuse a finalidade, navegue e confira, no servidor, que as tags respeitam o sinal.
• Registre a decisão: quando o aviso, as tags ou os campos mudarem, guarde a data.

A documentação do Google não responde quando o servidor compensa o esforço, e nenhum estudo aberto sobre o ganho foi lido para este texto. Em vez de um número, vale uma lista de perguntas para a sua decisão:

• Existe uma necessidade real de controlar o que sai para as plataformas, como remover campos?
• A equipe consegue manter um servidor e depurá-lo?
• O ganho esperado compensa o trabalho extra de manter o consentimento coerente nos dois lugares?

Se a resposta for não, a trilha de Google Analytics 4 e LGPD mostra como ligar o consentimento às tags comuns, o que já resolve boa parte dos casos.

A CMP continua sendo o ponto onde a escolha nasce. Na AdOpt, a prova do consentimento é o registro no Consent Log, com data e hora, as tags e os cookies aceitos ou recusados e as versões dos documentos. O CookieID só liga a escolha ao registro. Como esse sinal chega ao servidor depende da sua implementação, e este artigo não descreve um passo a passo.

O artigo sobre registro de consentimento mostra o que precisa estar guardado para provar a escolha, e a taxa de consentimento ajuda a acompanhar se o aviso está funcionando.

• Atribuição com privacidade: medir sem reter dado pessoal
• Enhanced conversions: o que é e como usar com consentimento

É uma forma de medir a atividade do usuário em que as tags rodam em um contêiner no seu servidor, usando o mesmo modelo de tags, acionadores e variáveis do Tag Manager. O Google lista como benefícios melhor desempenho de página, mais controles de privacidade e melhor qualidade de dado, e permite hospedar o servidor na Google Cloud ou em outra plataforma.

Não. A documentação do Google faz as tags do servidor reagirem ao sinal de consentimento enviado pelo contêiner web, e as plataformas continuam exigindo o consentimento onde a lei pede. A LGPD trata de finalidade e de dado pessoal, e nada disso muda porque o envio passou do navegador para o servidor.

Segundo a documentação do Google, só no contêiner web. A tag do Google adiciona os parâmetros de consentimento à requisição HTTP e o contêiner do servidor os recebe. O Consent Mode não traz aviso nem widget: ele depende da sua CMP para coletar a escolha do visitante e informar as tags.

Sim. A página do Google diz que os contêineres do servidor aceitam os dois modos. No básico, as tags do Google Analytics ficam bloqueadas com analytics_storage negado; no avançado, elas carregam e ajustam o comportamento. Para configurações regionais no avançado, a página manda configurar o servidor para aceitá-las.

Se você quer que o aviso respeite a recusa e guarde a prova de cada escolha, fale com a gente e vemos juntos o que o seu site precisa.