Tracking server-side: o que é, o que muda e quando precisa dele

Durante anos, medir uma campanha consistia em colar no site o píxel de cada plataforma. Funcionava, mas perdem-se cada vez mais dados por causa da rejeição de cookies, das restrições dos navegadores e dos bloqueadores, e o site enche-se de código de terceiros que não controla.

O tracking server-side, também chamado etiquetagem do lado do servidor, muda o percurso desses dados. Neste artigo explicamos como funciona, o que melhora, o que não resolve e quando vale a pena.

O que é o tracking server-side

Na etiquetagem do lado do cliente (client-side), o navegador do utilizador carrega a etiqueta de cada plataforma e envia os eventos diretamente para o Google, a Meta ou o TikTok. Cada fornecedor recebe o que o seu script recolhe.

Na etiquetagem do lado do servidor (server-side), o site envia os eventos para um único destino: um servidor de etiquetagem que vive num subdomínio seu. Esse servidor recebe o evento, processa-o e reencaminha-o para cada plataforma pelas suas APIs.

O que muda face à etiquetagem no navegador

Os pedidos vão para o seu próprio domínio

O navegador já não fala com dezenas de domínios de terceiros, mas com um subdomínio seu. Para o navegador, é tráfego próprio (first-party).

O servidor decide o que chega a cada plataforma

Pode retirar o IP ou parâmetros do URL antes de reencaminhar, enviar a cada plataforma apenas os eventos que lhe dizem respeito e descartar tráfego que não quer contar, como bots ou testes internos. É a mudança mais importante: a decisão sobre o que se partilha passa a ser sua.

Cookies próprios que duram mais

O Safari, com a sua Intelligent Tracking Prevention (ITP), limita a sete dias os cookies criados por JavaScript, e os de terceiros simplesmente não os aceita. Os cookies que o seu servidor define numa resposta HTTP a partir do seu domínio podem durar mais, por isso um utilizador que volta ao fim de duas semanas continua a ser reconhecível. Uma ressalva: o Safari também limita os cookies de servidor quando o subdomínio de etiquetagem aponta para uma infraestrutura muito diferente da do seu site, por isso a forma como se configura importa.

Menos código de terceiros na página

Se várias plataformas forem alimentadas a partir do servidor, pode retirar alguns dos seus scripts do site. Menos JavaScript de terceiros costuma significar uma página que carrega mais depressa.

O que o tracking server-side não faz

• Não evita o consentimento. Se o utilizador rejeitar os cookies de publicidade ou de análise, esses dados não podem ser enviados, quer vão pelo navegador, quer pelo servidor. O servidor tem de ler o sinal do seu CMP e respeitá-lo.
• Não é medição sem cookies por artes mágicas. Continua a usar cookies, só que próprios. O que melhora é a sua duração e o controlo, não a necessidade de autorização.
• Não contorna todos os bloqueadores. Um subdomínio próprio resiste melhor do que os domínios conhecidos das plataformas, mas alguns bloqueadores também detetam os scripts ou os caminhos habituais da etiquetagem.

Que peças são precisas

1. Um servidor de etiquetagem. A opção mais difundida é o Google Tag Manager server-side, que pode ser implementado no Google Cloud Run ou num fornecedor gerido que o aloja por si.
2. Um subdomínio próprio. Por exemplo, tag.seudominio.com, a apontar para esse servidor.
3. Um contentor web. O GTM de sempre ou a etiqueta Google na página, configurados para enviar os eventos para o seu servidor em vez de para cada plataforma.
4. Um contentor de servidor. Recebe os pedidos através de «clientes» que os interpretam e dispara as etiquetas de cada destino.
5. As etiquetas de cada plataforma. A API de Conversões da Meta, as conversões otimizadas do Google Ads, a Events API do TikTok e o Measurement Protocol do GA4, entre outras.

A peça da Meta é explicada no guia da API de Conversões.

Desduplicação: quando o navegador e o servidor enviam o mesmo evento

Muitas instalações mantêm o píxel no navegador e acrescentam o envio a partir do servidor. É razoável, mas a mesma compra chega duas vezes. Para que a plataforma a conte uma só vez, os dois envios têm de levar o mesmo identificador: na Meta e no TikTok, o mesmo nome de evento e o mesmo event_id; no Google Ads, o mesmo ID de transação. Sem isso, as conversões ficam inflacionadas e os lances aprendem com dados duplicados.

Enriquecer os eventos com dados do seu negócio

O navegador só sabe o que acontece no site. O seu servidor pode consultar outros sistemas antes de reencaminhar o evento: a margem da encomenda a partir do ERP, a qualidade do lead a partir do CRM ou se o cliente já tinha comprado antes. O que acontece dias depois, como uma venda fechada por telefone ou uma devolução, completa-se com conversões offline a partir da sua fonte da verdade.

Custos e manutenção

Um servidor de etiquetagem é infraestrutura e custa dinheiro todos os meses. No Cloud Run, a Google recomenda várias instâncias para produção, e o custo cresce com o tráfego. Um fornecedor gerido simplifica a implementação em troca de uma mensalidade.

O custo menos visível é o da manutenção. Alguém tem de vigiar se o servidor responde, atualizar os modelos e verificar se o consentimento e a desduplicação continuam a funcionar depois de cada alteração no site. Sem um responsável técnico, uma montagem server-side degrada-se em silêncio.

Quando precisa dele e quando não

Compensa-lhe se se cumprirem várias destas condições:

• Investe em várias plataformas e os seus lances automáticos dependem das conversões que recebem.
• Uma parte relevante do seu tráfego chega a partir do Safari ou do iOS.
• Quer controlar que dados pessoais recebe cada fornecedor.
• Quer enviar valores de negócio, como a margem ou a qualidade do lead, e não apenas o evento.
• Tem alguém, interno ou externo, que se encarregue de o manter.

Provavelmente ainda não precisa dele se investe pouco em meios, usa uma só plataforma com a sua integração nativa ou as suas conversões já chegam a partir do CRM como conversões offline.

Erros habituais

• Montá-lo para contornar o consentimento. É um risco legal e, além disso, não é para isso que serve.
• Duplicar eventos. Enviar a partir do navegador e do servidor sem um event_id comum.
• Usar um domínio que não é o seu. Sem subdomínio próprio, perde-se boa parte da vantagem dos cookies first-party.
• Não ter dono. Ninguém revê o servidor até as conversões caírem.

Como o Babuin o faz

Na MonkeyFlux, os eventos do seu site e da sua app passam por um servidor no seu próprio domínio, como tag.seudominio.com, com cookies first-party. Aí aplica-se o consentimento, desduplicam-se os eventos por event_id e enriquecem-se com dados do seu CRM e do seu ERP, como margem, LTV, qualidade do lead ou devoluções. Depois são enviados para cada plataforma por Conversions API, Enhanced Conversions, Events API ou Measurement Protocol. É compatível com o seu contentor server-side do GTM.

Com esses sinais, o Babuin mede cada meio contra os resultados do seu negócio, o MonkeyBot faz lances orientados para valor real e o DBA distribui todos os dias o orçamento entre canais.

Perguntas frequentes