Rastreamento no servidor

O que muda e o que você paga por isso

No rastreamento no navegador, o navegador do visitante manda o evento direto ao fornecedor. No rastreamento no servidor, o navegador avisa o seu backend — ou não avisa nada, porque o seu backend já sabe que aconteceu — e é o seu backend que repassa o evento. Mesmo evento, outro remetente, e o remetente é toda a diferença.

• O que você ganha: uma extensão não derruba uma requisição que nunca sai da máquina do visitante, um envio que falha pode ser repetido, o conteúdo é validado antes de sair e as chaves de API ficam do seu lado do fio.
• O que você perde: tudo o que o navegador sabia e o seu banco não — o referenciador, o tamanho da janela, qual elemento foi clicado, o quanto a página foi rolada e o identificador anônimo que costurava a sessão.
• O que fica mais difícil: o momento e a identidade. O navegador sabia que o evento aconteceu *com um visitante específico, numa página específica, naquele instante*; o seu backend sabe que uma linha mudou. Reconstruir o resto é o trabalho de verdade.

O problema de identidade sobre o qual ninguém avisa

Um evento de navegador chega já carregando contexto: qual página, qual referenciador, qual identificador anônimo, quais rótulos de campanha estavam na URL. Um evento de servidor carrega o que você lembrou de guardar. Esse é o trabalho real de migrar para o servidor, e não é o envio: é decidir, no instante em que alguém chega, o que precisa ser copiado para o seu próprio banco porque daqui a cinco minutos não vai mais existir.

Os parâmetros UTM e os identificadores de clique de anúncio são o caso mais afiado, porque existem em exatamente uma URL, logo no começo. Se o identificador de clique nunca foi guardado junto à conta no cadastro, uma conversão enviada três semanas depois não tem em que se apoiar — você terá protegido com esmero um número que já não responde à pergunta para a qual foi construído. A atribuição de marketing é essa pergunta, e ela se decide na chegada, não na conversão.

O que aprendemos enviando nossas próprias conversões pelo servidor

A AgentCeres — o AI Growth Officer em agentceres.com — envia conversões de leads qualificados a uma plataforma de anúncios a partir do seu próprio banco de dados, e não do navegador de ninguém, usando como chave o identificador de clique capturado quando a pessoa chegou. A surpresa não foi o envio. Foi que uma resposta HTTP bem-sucedida não é um recibo: nossos envios voltavam 200 enquanto as linhas dentro deles estavam sendo rejeitadas, e o resultado real só aparecia numa consulta de status separada, feita depois. O endpoint ao qual recorremos primeiro também estava fechado para novas integrações, algo que o 200 igualmente não mencionava.

O formato se generaliza. No navegador, um evento perdido é barulhento de um jeito específico: o número simplesmente falta, e o buraco aparece. No servidor, a falha é uma requisição que os seus próprios registros anotam como sucesso, então o buraco parece um fato. Tudo que você mover para o servidor precisa de uma etapa de verificação que pergunte ao fornecedor o que ele de fato guardou, em vez de confiar no que ele respondeu na hora. A outra metade desta história, a da recepção — quanto dado de navegador se perde logo de saída, e por que a falta era maior justamente no público que pagávamos para atrair —, está na nossa página sobre o PostHog.

Não é um jeito de contornar o consentimento

O rastreamento no servidor costuma ser vendido por derrotar bloqueadores de anúncio, o que mecanicamente ele faz. Vale ser direto sobre o que isso significa: o bloqueador foi instalado por uma pessoa expressando uma preferência, e mover a escrita para o seu servidor não cria uma base legal que você não tinha, nem torna próprio um dado só porque ele passou pelo seu domínio a caminho de outro lugar.

• O consentimento rege a finalidade, não o transporte. Se um evento precisa de consentimento quando o navegador manda, precisa quando o seu servidor manda.
• Um proxy no seu próprio domínio continua sendo uma transferência quando o destino é um terceiro — descreva assim no seu aviso de privacidade, em vez de reclassificar.
• A versão honesta costuma bastar. Quase tudo de que uma startup pequena realmente precisa no servidor são os próprios dados de produto — cadastros, planos, pagamentos —, que nunca foram do navegador para mandar.