Server-side tagging vale a pena? O que ele não conserta

A conta começa em torno de US$ 40 a 50 por instância por mês, e o Google recomenda no mínimo três para produção (Google). Antes de aprovar isso, vale saber que o principal benefício vendido pelo produto tem uma condição que a documentação do Google não menciona, e que o motivo mais citado para comprá-lo é um texto de 2019 que o próprio WebKit já reescreveu.

Server-side tagging resolve problemas reais. Só não os que aparecem na apresentação.

O que ele entrega: remoção de dado pessoal antes do fornecedor, alívio de script no navegador e roteamento de evento no servidor. O que ele não entrega: consentimento, identificador que o navegador já apagou, e durabilidade de cookie garantida no Safari.

O que o server-side tagging faz, mecanicamente?

Troca muitos destinos por um destino que é seu.

Em vez de o navegador falar com o endpoint de cada fornecedor, ele fala com um container que você hospeda. Lá dentro, “os clients são adaptadores entre o software rodando no dispositivo do usuário e o seu container de servidor”: recebem o dado, transformam em eventos, roteiam e devolvem a resposta (Google).

Disso vêm três ganhos que ninguém contesta. O container do site passa a hospedar “apenas as tags necessárias” para gerar eventos, o que alivia o navegador. Você pode “remover qualquer informação de identificação pessoal antes de repassar o dado aos parceiros de marketing” (Google). E, num contexto de primeira parte, o servidor consegue gravar cookies “que não são visíveis para scripts na página”, os HttpOnly (Google).

Esse último ponto é onde mora a discussão.

Ele devolve a duração do cookie no Safari?

Sob uma condição que o Google não escreve na página onde vende o benefício.

A tabela oficial de domínios é categórica: mesmo domínio e subdomínio dão “acesso total aos benefícios de segurança e durabilidade”, enquanto o domínio padrão dá “nenhum” (Google).

O WebKit descreve a mesma configuração de outro jeito: “O ITP detecta requisições de CNAME cloaking de terceiro e de IP cloaking de terceiro, e limita a validade de quaisquer cookies definidos na resposta HTTP a 7 dias”. E define o que conta como tal: “um sub-recurso de primeira parte que resolve através de um CNAME diferente do domínio de primeira parte e diferente do CNAME do host do frame superior, se houver” (WebKit).

Leia as duas em sequência. O subdomínio que o Google recomenda apontar para o servidor de tagueamento é, quase sempre, um subdomínio que resolve por CNAME para outro lugar. É exatamente a forma que o WebKit descreve.

Uma ressalva honesta: não encontrei documento do Google nem da Apple afirmando que um endpoint específico do sGTM dispara esse detector. Não vou afirmar que dispara. O que está verificado é que a definição publicada pelo WebKit descreve essa arquitetura, e que o Google omite a questão na página que promete durabilidade total. Teste no seu domínio antes de assumir qualquer um dos lados.

O cap de 7 dias é mesmo como todo mundo descreve?

Não, e essa é a parte mais desatualizada do assunto.

O texto que fundou o gênero é de fevereiro de 2019: “com o ITP 2.1, todos os cookies persistentes de client-side, ou seja, cookies persistentes criados através de document.cookie, são limitados a uma validade de sete dias” (WebKit, ITP 2.1).

A página viva do WebKit hoje descreve outra coisa: o ITP “apaga todos os cookies criados em JavaScript e todo o resto do armazenamento gravável por script após 7 dias sem interação do usuário com o site” (WebKit).

Apagar por inatividade não é o mesmo que limitar validade. Para um e-commerce com visitante recorrente, a diferença é enorme: o relógio reinicia a cada visita. Todo material de venda que apresenta um teto fixo de sete dias em cookie de primeira parte está citando texto de 2019 sem conferir a página atual.

Vale registrar o que o mesmo texto de 2019 diz e quase ninguém cita: “apenas cookies criados através de document.cookie são afetados por essa mudança”.

O que ele não conserta em hipótese nenhuma?

O dado que o navegador apaga antes de chegar ao seu servidor.

O Safari “remove um subconjunto de parâmetros de consulta identificados como usados para rastreamento entre sites” (WebKit, Private Browsing 2.0). Nenhuma arquitetura de servidor recupera um identificador de clique que foi removido da URL em trânsito. O seu servidor recebe o que sobrou.

E o Firefox tem modelo próprio, baseado em lista: para recursos classificados como rastreadores, ele vai “bloquear cabeçalhos de requisição Cookie e ignorar cabeçalhos de resposta Set-Cookie” (MDN). Ou seja, “definido pelo servidor” também não é palavra mágica ali: o que decide é a classificação e o contexto.

Resolve consentimento?

Não, e a documentação do Google é consistente nisso por omissão e por afirmação.

Por afirmação: “É sua responsabilidade, como anunciante, entender as leis que afetam você e implementar soluções de gestão de consentimento para qualquer dado que você compartilhe com o Google” (Google).

Por omissão, que é mais eloquente: a página de consent mode do próprio server-side tagging não contém nenhuma frase dizendo que a arquitetura reduz, remove ou altera obrigação de consentimento. O que ela diz é o contrário, que as tags “ajustam a quantidade e o tipo de dado que enviam com base nas preferências do usuário”, e que isso exige “uma solução de consentimento ou banner de cookies no seu site compatível com a API de consent mode” (Google).

O sinal de consentimento nasce no navegador e é encaminhado ao servidor. Mover a execução da tag para trás não muda quem precisa pedir permissão. Se alguém vender server-side como caminho para coletar sem consentimento, está vendendo risco jurídico com nome de arquitetura.

E no Brasil, a ANPD diz alguma coisa sobre isso?

Nada, e a ausência é informação.

A ANPD publicou um guia orientativo sobre cookies e proteção de dados pessoais, de outubro de 2022, que afirma que “a coleta de dados pessoais por meio de cookies deve, ainda, ser limitada ao mínimo necessário para a realização de finalidades legítimas, explícitas e específicas” (ANPD).

Procurando publicação da ANPD que trate especificamente de tagueamento no servidor, coleta server-side ou servidor de tagueamento, não encontrei nenhuma. Quem afirmar que a ANPD se posicionou sobre server-side tagging está inventando ou repetindo blog de agência.

Na prática, isso significa que o critério continua sendo o mesmo do resto: finalidade, minimização e base legal. Onde o código roda não é a pergunta que o regulador faz.

Quanto custa de verdade?

Mais do que a instância, e o próprio Google se contradiz no dimensionamento.

Item	Número	Fonte
Instância App Engine em produção	~US$ 40/mês	App Engine setup
Instância (página de planejamento)	~US$ 50/mês	Planejamento
Mínimo recomendado	3 instâncias, escalando 3 a 6	Upgrade de infra
Mínimo em outra página	2 instâncias, escalando 2 a 10	Cloud Run setup

As duas páginas de mínimo estão no ar hoje, com datas de atualização diferentes, e discordam também na vazão suportada. Não é erro de leitura: é o fornecedor contradizendo o fornecedor. Se você for defender um orçamento, cite a página específica.

Por cima disso vem o que não aparece na conta de ninguém. O Google avisa que o tráfego de saída “é calculado para todo dado de rede que sai do container”, incluindo as respostas HTTP de volta ao navegador, e que “depois de coletar requisições suficientes para ultrapassar o nível gratuito do Cloud Logging, o custo de armazenar logs pode se tornar substancial” (Google).

Três instâncias a US$ 40 ou 50 dão de US$ 120 a 150 por mês só de computação. Essa multiplicação é minha, não do Google; os valores unitários e o mínimo são deles.

Então vale a pena?

Depende de qual dos três problemas é o seu.

Vale se o problema é PII saindo do seu domínio para fornecedor, ou peso de script no navegador, ou necessidade de transformar e rotear evento antes de despachar. São os ganhos que a documentação sustenta e que não dependem de interpretação.

Não vale se foi vendido como recuperação de conversão perdida. Nenhuma fonte primária publica esse percentual, e os que circulam se contradizem.

Não resolve nada se o problema é consentimento, ou identificador removido da URL pelo navegador, ou divergência entre o que a plataforma declara e o que o ERP fechou. Esse último é problema de definição, não de coleta, e nenhum servidor conserta. O mesmo vale para a parte do dado que o consent mode preenche por modelagem: mover a tag não transforma estimativa em observação.

Antes de aprovar a nota fiscal, escreva qual dos três você está comprando. Se a resposta for “durabilidade de cookie”, releia a seção do CNAME.

O que este artigo não cobre?

Não traz o percentual de dado recuperado. A faixa que circula varia de um quinto a quatro quintos do dado conforme o blog, sem metodologia em nenhum, e o número com aparência mais séria vem de um fornecedor que hospeda server-side tagging, sem contagem de sites, sem período e sem definição do que significa “recuperado”.

Não descreve o funcionamento do cookie FPID. Não encontrei página oficial do Google documentando isso; a melhor fonte disponível é um especialista independente que também não cita documentação oficial. Um mecanismo central do produto sem documentação do fabricante é um fato relevante por si só.

Não cita o texto da LGPD nem o corpo do guia da ANPD. O site do Planalto recusou a leitura automatizada e o PDF do guia veio com o texto comprimido e ilegível. Citação de norma se faz com a norma aberta na frente, não de memória.

E não afirma que o endpoint do Google dispara o detector de cloaking do WebKit. Afirma que a definição publicada descreve a arquitetura e que o Google não menciona o assunto. A diferença entre essas duas frases é a diferença entre um artigo confiável e um que envelhece mal.