Marcação no lado do servidor

A marcação no servidor transfere a execução de tags do navegador da pessoa usuária para um servidor sob seu controle. Em vez de a página disparar pixels diretamente para o Google e a Meta, ela envia uma solicitação para seu próprio endpoint de marcação.

Esse servidor decide o que encaminhar, para quem e em qual formato. O navegador se comunica apenas com seu domínio de primeira parte.

No modelo clássico, o pixel de cada fornecedor é executado no navegador e faz sua própria solicitação de terceiros. Na marcação no servidor, o navegador envia um evento para um servidor de marcação, que o distribui para vários destinos.

Isso dá a você controle sobre os dados, reduz as solicitações bloqueadas e diminui o volume de código no lado do cliente que torna as páginas mais lentas.

O Server-Side Google Tag Manager (sGTM) do Google é a implementação mais comum. Ele é um contêiner executado no Cloud Run, no App Engine ou em qualquer outro ambiente de hospedagem, que recebe solicitações e as processa por meio de clientes e tags.

Um cliente analisa as solicitações recebidas e as transforma em eventos; as tags então enviam esses eventos aos destinos. É o GTM, mas executado no servidor em vez de na página.

O principal ganho de confiabilidade vem de associar o servidor de marcação a um subdomínio do seu próprio site, como sgtm.example.com, por meio de um registro A ou CNAME no DNS.

Como as solicitações agora vão para o seu domínio, os cookies definidos na resposta são de primeira parte e HttpOnly. Eles escapam dos limites mais rigorosos do ITP e têm muito menos probabilidade de ser bloqueados por bloqueadores de anúncios.

Uma compra acontece na página. O contêiner da web (ou o gtag) envia um evento para sgtm.example.com. O cliente do GA4 nesse endereço reconstrói o acesso, o enriquece, e uma tag do GA4 o encaminha para o endpoint de coleta do Google.

O mesmo evento pode simultaneamente acionar uma tag da API de Conversões da Meta, uma conversão do Google Ads no servidor e muito mais, tudo a partir de uma única solicitação recebida.

A API de Conversões da Meta, as Conversões Otimizadas do Google e a API de Eventos do TikTok são todos endpoints servidor a servidor. Eles aceitam eventos diretamente do seu servidor, ignorando completamente o pixel do navegador.

Isso recupera conversões perdidas por causa de bloqueadores de anúncios e do ITP e permite enviar identificadores de primeira parte com hash (e-mail, telefone) para obter uma correspondência melhor, desde que você tenha consentimento.

Como o servidor vê o evento bruto, você pode enriquecê-lo: incluir o valor real do pedido proveniente do seu banco de dados, remover PII que não deseja compartilhar, adicionar registros de data e hora do servidor ou eliminar duplicidades em relação a eventos do cliente.

Você se torna o editor dos seus próprios dados, enviando a cada plataforma apenas os campos mínimos de que ela precisa. Isso é minimização de dados na prática, não apenas uma política.

Se você executar tanto um pixel do navegador quanto um evento do servidor para a mesma conversão, as plataformas não poderão contabilizá-la duas vezes. A eliminação de duplicidades usa um identificador compartilhado.

Envie o mesmo event_id (e event_name) tanto pelo pixel do cliente quanto pela chamada CAPI do servidor. A Meta e outras plataformas fazem a correspondência entre eles e mantêm apenas um, oferecendo redundância sem inflação.

O servidor de marcação é uma infraestrutura real. No Google Cloud Run, ele aumenta ou reduz automaticamente a escala conforme o tráfego; você paga pela computação e pela saída de dados. Um site pequeno pode executar algumas instâncias, enquanto um site grande pode executar muitas.

Planeje o monitoramento, um servidor de prévia para depuração e a disponibilidade, pois, se o servidor de marcação cair, a mensuração também cairá. Agora ele é um serviço de produção, não um trecho de código.

A marcação no servidor não contorna o consentimento. Você ainda precisa de uma base legal, e enviar dados sem consentimento é ilegal, independentemente de onde a execução ocorre.

Ela também não restaura magicamente o rastreamento determinístico entre sites. Melhora a confiabilidade e a correspondência de dados de primeira parte obtidos com consentimento; é uma camada de resiliência, não uma brecha.

Uma implementação real segue uma sequência: configure o servidor, associe o subdomínio, conecte o contêiner da web a ele, configure clientes e tags e depois conecte os destinos CAPI.

Valide usando a visualização de prévia e depuração, confirme se a eliminação de duplicidades funciona, verifique o controle baseado em consentimento e só então transfira o tráfego. Trate isso como a implantação de qualquer serviço de backend.

Teste sua compreensão sobre marcação no servidor.

A marcação no servidor encaminha eventos do navegador para um servidor de marcação no seu próprio subdomínio, que define cookies de primeira parte e encaminha dados obtidos com consentimento para as plataformas por meio de APIs servidor a servidor, como a CAPI da Meta.

Benefícios: menos solicitações bloqueadas, cookies mais compatíveis com o ITP, enriquecimento e minimização de dados e eliminação de duplicidades de eventos. É uma camada de confiabilidade e controle, uma infraestrutura real para operar e nunca um substituto para o consentimento.