É uma das soluções mais faladas e das menos bem explicadas. Não é um truque para contornar o consentimento, nem uma obrigação. É uma arquitetura de medição que faz sentido em certos casos.
Como difere do tracking normal
| Aspeto | No navegador | No servidor |
|---|---|---|
| Código no site | Uma etiqueta por plataforma | Um fluxo único enviado ao servidor1 |
| Controlo dos dados | Cada plataforma recebe o que o navegador lhe dá | Podes filtrar e remover dados antes de partilhar1 |
| Cookies | Mais expostos a limitações do navegador | Mais duradouros se o servidor estiver no mesmo domínio1 |
| Custo e manutenção | Baixos | Servidor, configuração e acompanhamento |
Quando faz sentido
- Investes bastante em anúncios e cada ponto de precisão na medição se paga.
- Tens vários destinos de dados (GA4, Google Ads, Meta, CRM) e queres um ponto único.
- Precisas de controlar dados sensíveis antes de chegarem às plataformas.
- O site é pesado e as etiquetas contribuem para a lentidão2.
Quando é cedo demais
- O tracking básico ainda não está certo. Primeiro configura as conversões e o consentimento.
- O investimento é pequeno e o custo de servidor e manutenção pesa mais do que o ganho.
- Ninguém na equipa pode acompanhar a configuração.
Nota sobre consentimento
O servidor não substitui o consentimento. Se o utilizador recusa, os dados não podem ser usados como se tivesse aceitado. O benefício está na qualidade e no controlo do que é recolhido legitimamente.
Não. Muitos negócios medem bem com tracking no navegador. É uma evolução, não um requisito.
Depende do tráfego e do fornecedor de servidor. Pede sempre uma estimativa baseada no teu volume de eventos.
Fontes e leituras
- Server-side taggingDocumentação do Google. Funcionamento, controlo de dados e cookies.
- Why and when to use server-side tagging?Google. Casos em que compensa.