Rastreamento server-side vs. client-side

Qual é a diferença, em uma frase?

O rastreamento client-side vê o contexto; o rastreamento server-side vê a verdade. O navegador conhece os parâmetros UTM, o referrer, o dispositivo e a página — e perde eventos para os bloqueadores. O seu back-end sabe o que de fato aconteceu — uma assinatura começou, um pagamento falhou — e não sabe nada sobre como o usuário chegou ali. Este guia trata de onde instrumentar. Para o que rastrear — nomes e a lista inicial de eventos —, veja o plano de rastreamento de eventos para startups; para entender por que os dados devem ser first-party, veja dados first-party e rastreamento. As duas metades cabem em um único plano de rastreamento.

O que o rastreamento client-side vê — e o que ele perde?

O lado do cliente é onde o contexto vive. O SDK no navegador captura os parâmetros UTM, o referrer, a página de entrada, o dispositivo e o comportamento na sessão — tudo de que a atribuição e a análise de funil precisam. O que ele perde são usuários inteiros: segundo dados da GWI compilados pelo Backlinko, 29,5% dos usuários de internet no mundo usaram bloqueador de anúncios pelo menos às vezes no 2º trimestre de 2025 — cerca de 1,77 bilhão de pessoas. Muitos bloqueadores barram os scripts de análise junto com os anúncios, então uma parcela mensurável dos seus eventos client-side nem chega a ser enviada.

Mesmo sem bloqueador, o Safari faz o rastreamento client-side perder dados. Segundo a documentação do ITP do WebKit, o Safari limita a sete dias a validade dos cookies definidos por JavaScript e apaga todo o restante do armazenamento gravável por script — localStorage, IndexedDB — depois de sete dias de uso do Safari sem interação com o seu site. Passada essa janela de sete dias de uso, um visitante que volta parece totalmente novo, e a identidade se quebra. A perda é mensurável: quando o Plausible comparou as próprias contagens com as do Google Analytics em um site que estava em alta no Hacker News e no Reddit, em um teste no fim de agosto de 2021, o Google Analytics deixou de contar 58,67% dos visitantes — um caso extremo, com público muito técnico; o Plausible cita pesquisas anteriores que situam o bloqueio abaixo de 10% em sites de estilo de vida e acima de 25% em sites focados em tecnologia.

O que o rastreamento server-side vê — e o que ele perde?

O rastreamento server-side é o seu back-end informando mudanças de estado à API de eventos: subscription_started, payment_failed, plan_changed. Esses eventos acontecem nos seus servidores, não no navegador — registrá-los ali não é um contorno, é a fonte honesta. Nenhum bloqueador fica no caminho, nenhum limite de armazenamento os faz expirar, e a contagem bate com o seu banco de dados porque vem do seu banco de dados. Um evento server-side é confiável porque registra o que o seu sistema fez, não o que um navegador conseguiu relatar. O ponto cego é o contexto: o seu back-end não faz ideia de qual campanha, referrer ou dispositivo trouxe o usuário — esse contexto só existiu do lado do cliente.

Cliente vs. servidor: quais eventos vão para onde?

Como uma equipe pequena deve dividir?

• Tudo o que envolve dinheiro — testes, assinaturas, pagamentos, reembolsos — vai para o servidor. Quando o churn ou o MRR precisam estar certos, o servidor é a fonte de verdade.
• Tudo o que envolve atribuição — visualizações de página, campanhas, referrers — fica no cliente. Esse contexto não pode ser reconstruído depois.
• Identifique o usuário nos dois caminhos com o mesmo ID, para que os funis se encaixem e os testes A/B com pouco tráfego atribuam cada usuário a uma única variante em todos os dispositivos.
• Aceite a diferença. As contagens do cliente ficam mais baixas por natureza; use-as para a direção e os eventos do servidor para tudo o que você reporta.

Por que os dois números nunca batem?

Rode os dois e as contagens vão divergir — para sempre. O número do cliente fica mais baixo porque os bloqueadores e o ITP comem eventos; o número do servidor não tem o contexto para dizer de onde os usuários vieram. Isso não é um bug a corrigir, mas uma propriedade a reconhecer: conte com uma diferença permanente entre as análises do cliente e a verdade do servidor, saiba o tamanho aproximado dela para o seu público e pare de persegui-la. Reporte cada número a partir do lado em que ele é honesto — a atribuição e a direção do funil com os dados do cliente; tudo o que chega a uma apresentação para investidores ou a uma fatura — taxa de churn, MRR, assinaturas ativas — calculado a partir dos eventos do servidor. Plataformas de engajamento como o Iterable e o Ortto aceitam as duas fontes pelo mesmo motivo.

Como o fromHello lida com isso?

O fromHello trata a divisão como padrão. O SDK JS/TS rastreia do lado do cliente e mantém uma fila offline apoiada no localStorage — os eventos registrados durante uma queda de conexão ficam guardados e são reenviados quando o navegador volta a ficar online —, enquanto a mesma API de eventos aceita envios do lado do servidor, então subscription_started vem direto do seu back-end com uma chave de API. Os dois caminhos gravam em um único perfil: a atribuição que o SDK capturou e os eventos de receita que o seu servidor enviou descrevem a mesma pessoa. Segmentos, jornadas e análises leem esse perfil único — você divide a instrumentação, não a identidade.