O debate "server-side vs client-side" passou anos a ser um daqueles tópicos onde a resposta é genuinamente "depende" e toda a gente odeia isso. Aqui está a versão em linguagem clara, sem argumentos de venda, e com uma tabela honesta que pode enviar ao seu CTO.
O que cada um é realmente
O tracking client-side corre no browser do visitante. Um pequeno script é executado, lê o que aconteceu (visualização de página, clique, profundidade de scroll) e envia essa informação diretamente para um endpoint de recolha. O tracking server-side corre na sua infraestrutura. O browser envia dados mínimos para o seu servidor (ou um edge worker leve), que decide então o que reencaminhar e para onde.
Nenhum é inerentemente mais "amigo da privacidade" ou "preciso" do que o outro. Ambos podem ser as duas coisas, dependendo de como são configurados. O que difere é onde está o ponto de controlo — e quanto da verdade chega até si.
A tabela honesta de trade-offs
| Dimensão | Client-side | Server-side |
|---|---|---|
| Esforço de configuração | Baixo — colar um snippet | Superior — um serviço e uma pequena camada de routing |
| Resiliência a Ad-blockers | Fraca — script bloqueado na origem | Forte — endpoint first-party no seu próprio domínio |
| Perda de dados em browsers modernos | Significativa (Safari ITP, bloqueadores, modos de proteção) | Pequena — a superfície é sua |
| Latência no first paint | Adiciona um pedido de terceiros | Não adiciona nada se o coletor estiver em cache na edge |
| Controlo sobre o que sai da infra | O que o script do fornecedor decidir | O que você decidir |
| Facilidade de debugging | Separador Network do DevTools | Logs do servidor — competência diferente, mas mais completa |
| Custo em escala | Baixo, até o fornecedor subir de escalão | Pequena fatura de edge / functions que consegue ver |
| Identificação B2B ao nível da empresa | Funciona, mas é frágil | Ajuste ideal — o servidor pode resolver IP → empresa de forma privada |
Esta última linha é aquela para a qual as equipas B2B devem olhar com mais atenção. A identificação client-side depende de um script que uma fatia crescente de visitantes bloqueia ou neutraliza agressivamente. O server-side coloca a lógica de identificação na sua própria infraestrutura, onde não pode ser desativada silenciosamente por uma atualização do browser.
Onde se encaixa a identificação ao nível da empresa
A identificação ao nível da empresa é um workload natural de server-side. O browser só precisa de fazer um pedido muito pequeno para um endpoint first-party no seu próprio domínio. Esse endpoint corre na edge (tipicamente <20 ms na Europa), faz a resolução de IP para empresa de forma privada e não devolve nada que revele o que aconteceu ao cliente. A experiência do utilizador não muda. O cenário de bloqueadores é contornado. O caminho dos dados permanece dentro de um limite que você controla.
Isto não é um truque. É uma consequência direta de mover a questão "quem é este visitante" do cliente para um serviço que você opera. Nada sobre a navegação do visitante é alterado; algo sobre a sua capacidade de ver a resposta é.
O que o server-side não é
O tracking server-side não é uma forma de contornar o consentimento. Se uma atividade de processamento requer consentimento, requer consentimento independentemente de onde o código corre. O que o server-side altera é a perda de dados e o controlo — não a base legal.
Uma nota sobre performance
Muitas vezes teme-se que o "tracking" seja o que torna uma página lenta. Nas configurações modernas, esse é um medo do passado. Um loader bem construído tem poucos kilobytes, é diferido e disparado após a página estar interativa; um endpoint de servidor bem construído responde em milissegundos de um só dígito a partir da edge mais próxima. Nenhum deles é o que tornará os seus Core Web Vitals maus. O que os torna maus é o gestor de tags com catorze scripts de terceiros que ninguém audita há três anos. Menos caminhos de dados, e mais bem controlados, são quase sempre mais rápidos.
Quando o client-side ainda ganha
O client-side não está errado. Para analytics de baixo risco onde já aceita a perda de dados causada por bloqueadores (amostragem de utilização de produto, eventos de UX in-app, testes rápidos de landing pages), o client-side é mais rápido de implementar e mais barato de manter. O ponto não é que uma abordagem seja universalmente melhor; é que se o seu trabalho depende dos dados — o pipeline B2B é um bom exemplo — o caminho server-side é mais resiliente e mais honesto sobre o que está a fazer.
A pergunta certa não é "qual é o melhor?" É "para que decisão estes dados estão a contribuir e quanta perda de dados pode essa decisão tolerar?" Para "quem nos visitou esta semana" — idealmente, nenhuma. Portanto, a resposta de arquitetura segue essa lógica.
Publicado por
lead.box Team
Mais artigos
Veja o lead.box no seu próprio tráfego
Comece gratuitamente — sem cartão, sem necessidade de chamada de vendas. Ou reserve uma demonstração de 20 minutos se preferir uma visita guiada.