Um guia prático de rastreamento server-side de analytics

Nem todo evento precisa sair do navegador, mas cadastro e pagamento pedem rastreamento server-side de analytics para não depender do que o browser deixa passar.

O rastreamento analítico do lado do servidor é útil quando o evento acontece no seu servidor ou quando o rastreamento do lado do cliente não é confiável. Dois exemplos comuns são leitores e registros de blogs. Um navegador pode estimar o progresso do artigo e o tempo visível ativo; o servidor pode informar se uma conta foi realmente criada.

A melhor configuração combina ambos sem coletar dados pessoais desnecessários.

Medindo a leitura real do blog

Uma visualização de página é uma métrica de conteúdo fraca. Os leitores pulam imediatamente, deixam a aba aberta ou rolam até o final sem ler. Um evento de "leitura" melhor combina:

• Tempo mínimo ativo com base na contagem de palavras.
• Profundidade de rolagem no contêiner do artigo.
• Estado de visibilidade para que as guias em segundo plano não contem.
• Um evento único para que as atualizações não dupliquem as leituras.

Por exemplo, um artigo de 1.200 palavras pode exigir pelo menos 5 minutos de tempo ativo com aproximadamente 220 a 250 palavras por minuto, mais 80% de rolagem do artigo. Não trate esse número como universal. Documentos técnicos, conteúdo jurídico e postagens de comparação são lidos em velocidades diferentes.

Exemplo de evento do lado do cliente

const article = document.querySelector('[data-article]');
const words = Number(article?.dataset.words || 0);
const estimatedSeconds = Math.round((words / 230) * 60);
const minSeconds = Math.min(420, Math.max(30, estimatedSeconds * 0.6));
const maxCreditSeconds = Math.min(900, Math.max(90, estimatedSeconds * 1.5));
let activeSeconds = 0;
let articleVisible = false;
let reachedDepth = false;
let sent = false;
 
const depthMarker = document.createElement('span');
depthMarker.setAttribute('aria-hidden', 'true');
depthMarker.style.cssText = 'position:absolute;top:75%;left:0;width:1px;height:1px;';
if (article) {
  article.style.position ||= 'relative';
  article.appendChild(depthMarker);
}
 
function maybeSendRead() {
  if (sent || !article || !reachedDepth || activeSeconds < minSeconds) return;
  sent = true;
  navigator.sendBeacon(
    '/analytics/article-read',
    JSON.stringify({
      slug: article.dataset.slug,
      wordCount: words,
      activeSeconds,
    })
  );
}
 
const observer = new IntersectionObserver(
  (entries) => {
    for (const entry of entries) {
      if (entry.target === article) articleVisible = entry.isIntersecting;
      if (entry.target === depthMarker && entry.isIntersecting) reachedDepth = true;
    }
    maybeSendRead();
  },
  { threshold: 0 }
);
 
if (article) {
  observer.observe(article);
  observer.observe(depthMarker);
}
 
setInterval(() => {
  if (sent || !articleVisible || document.visibilityState !== 'visible') return;
  activeSeconds = Math.min(activeSeconds + 1, maxCreditSeconds);
  maybeSendRead();
}, 1000);

Isso evita contar uma rolagem rápida até o final como uma leitura. Ele também limita o crédito de tempo ativo, pausa quando a página está oculta e usa um marcador de profundidade no nível do artigo em vez de medir scroll depth em relação ao documento inteiro.

Rastreamento de registro do lado do servidor

Os registros devem ser rastreados depois que o servidor confirmar o sucesso, e não quando o usuário clicar em enviar. O formulário do lado do cliente envia uma contagem excessiva porque a validação pode falhar, solicitações duplicadas podem ocorrer e os bots podem acionar formulários.

Um evento do lado do servidor deve incluir apenas campos seguros:

• Nome do evento: registration_completed.
• Carimbo de data e hora.
• Visitante anônimo ou referência de sessão, se disponível e legal.
• Plano ou caminho de inscrição.
• Fonte UTM capturada no pouso.
• Tipo de conta ou intervalo de tamanho do espaço de trabalho.

Evite email, nome, endereço IP, ID de usuário bruto, status de senha ou campos de texto livre em análises. Se você precisar conectar eventos a contas internamente, armazene esse mapeamento no banco de dados do produto, e não em um evento analítico de terceiros.

Desduplicação

Use uma chave de idempotência para eventos do servidor. Um evento de registro deve ser acionado uma vez por criação de conta, mesmo que o usuário atualize a página de sucesso ou um webhook tente novamente.

await analytics.track({
  event: 'registration_completed',
  idempotencyKey: `registration:${account.id}`,
  properties: {
    plan: account.plan,
    source: attribution.source,
    campaign: attribution.campaign,
  },
});

Lista de verificação de privacidade

• Não rastreie a leitura em páginas confidenciais, a menos que seja necessário.
• Mantenha os eventos do artigo agregados sempre que possível.
• Remova os parâmetros de consulta antes de armazenar caminhos.
• Não envie dados pessoais nas propriedades do evento.
• Retenção de documentos para eventos brutos.
• Respeite os requisitos de consentimento para armazenamento ou identificadores do lado do cliente.

O rastreamento do lado do servidor não é automaticamente compatível com a privacidade. É melhor quando registra eventos de negócios verificados com cargas minimizadas. Use o navegador para sinais que somente o navegador pode saber e use o servidor para fatos que somente o servidor pode confirmar.

Verificações de qualidade de dados

Compare eventos de leitura de artigo com pageviews. Se cada visualização de página se tornar uma leitura, o limite será muito baixo ou o evento será acionado durante o carregamento. Se quase nenhuma leitura aparecer para artigos longos com forte envolvimento, o cálculo de rolagem está errado: usa o documento inteiro em vez do contêiner do artigo.

Para registros, reconcilie os eventos analíticos com o banco de dados do aplicativo. Uma contagem diária de registration_completed deve corresponder à criação da conta dentro do comportamento esperado de novas tentativas e exclusão. Caso contrário, corrija o evento do servidor antes de usá-lo para atribuição de marketing.

Consentimento e transparência

Se o rastreamento usar apenas eventos agregados e nenhum armazenamento no dispositivo, a carga de privacidade será menor. Se você definir identificadores, vincular eventos de leitura a contas ou usar os dados para personalização, atualize os avisos de consentimento e privacidade adequadamente. O lado do servidor não significa invisível; os usuários ainda merecem uma explicação honesta.

Detalhes de confiabilidade que importam

Ao enviar eventos de leitura do navegador, prefira métodos de entrega projetados para descarregamento de páginas. O Beacon API permite que o navegador envie uma pequena solicitação assíncrona sem bloquear a navegação, o que é útil para eventos analíticos que são acionados perto do final de uma visita (MDN Beacon API). Mantenha as cargas pequenas e não sensíveis porque os beacons não são um local para grandes objetos de depuração.

Para eventos de registro, projete o evento do lado do servidor como uma transação financeira:

• Dispare-o somente depois que a conta ou registro de registro for confirmado.
• Incluir uma chave de idempotência baseada no registro interno.
• Tente novamente com segurança se o endpoint de análise estiver temporariamente indisponível.
• Armazene um breve registro de auditoria do status da entrega.
• Reconcilie contagens com o banco de dados do produto.

Se a atribuição for importante, capture UTMs no momento do destino e armazene-os em um registro de atribuição primário com um período de retenção claro. Quando o registro for bem-sucedido, anexe campos de campanha seguros, como origem, meio, campanha e página de destino. Não anexe o histórico de navegação completo do visitante.

Para análises do tempo de leitura, tome cuidado com as guias deixadas abertas. Conte o tempo visível ativo, faça uma pausa quando a página estiver oculta e considere uma janela de crédito máxima para que a guia do intervalo para o almoço não se torne uma "leitura de 40 minutos". Para postagens muito curtas, use um limite mínimo; para postagens longas, evite exigir 100% de rolagem porque os leitores podem obter valor antes da biografia final do autor ou da seção de postagem relacionada.

O melhor sinal não é apenas o “tempo gasto”. É hora de um progresso significativo e uma ação de acompanhamento, como inscrição no newsletter, visita à página do produto ou registro.

Controle de qualidade de leitura e registro

Trate a leitura do artigo como um sinal de qualidade do conteúdo, não como uma prova de que uma pessoa identificável consumiu cada palavra. Valide isso:

• Uma guia em segundo plano não acumula tempo.
• Uma rolagem rápida não dispara uma leitura.
• Artigos longos limitam o crédito de tempo ativo.
• O evento é acionado uma vez por visualização de página.
• Categorias de artigos sensíveis usam apenas relatórios agregados.
• Os eventos de registro correspondem às contas confirmadas, não aos cliques de botão.

Mantenha o sinal do navegador e o fato do servidor separados. O navegador pode estimar uma leitura significativa. O servidor pode confirmar o registro. Combiná-los cuidadosamente é útil; fingir que qualquer um deles é perfeito cria análises barulhentas.

Perguntas Frequentes

Por que um pageview subconta e superconta a leitura ao mesmo tempo?

Um pageview dispara assim que a página carrega, então conta um abandono imediato, uma aba deixada aberta e uma rolagem rápida até o final da mesma forma que uma leitura real. Combiná-lo com um tempo ativo mínimo, a profundidade de rolagem e o estado de visibilidade separa a leitura real desses casos. Um evento único por cima impede que recarregamentos inflem ainda mais a contagem.

Que faixa de palavras por minuto devo usar para o limite de tempo ativo?

O artigo usa cerca de 220 a 250 palavras por minuto como ponto de partida, o que coloca o tempo ativo mínimo de um artigo de 1.200 palavras em torno de 5 minutos. Trate isso como uma base, não como um número universal. Documentação técnica, conteúdo jurídico e posts comparativos são lidos em velocidades diferentes, então recalibre por tipo de conteúdo.

Por que medir a profundidade de rolagem em relação ao contêiner do artigo em vez do documento inteiro?

Medir em relação ao documento inteiro distorce o número sempre que o cabeçalho, o rodapé ou os posts relacionados mudam o comprimento da página. O exemplo do lado do cliente ancora um marcador de profundidade de 80 por cento dentro do próprio elemento do artigo com um IntersectionObserver, de modo que o cálculo acompanha o artigo, não o layout ao redor. Esse também é o ajuste quando quase nenhuma leitura aparece em artigos longos com bom engajamento.

Devo usar 100 por cento de rolagem como limite de leitura?

Exigir rolagem completa em posts longos pode deixar de fora leitores que já obtiveram o valor antes da bio do autor ou do bloco de posts relacionados no final. O exemplo usa 80 por cento de profundidade de rolagem em vez disso. Em conteúdo longo, evitar a marca de 100 por cento mantém a métrica mais próxima do que "ler" realmente significa.

Como evito que uma aba em segundo plano infle o tempo ativo?

Verificar document.visibilityState junto com um IntersectionObserver que observa se o artigo está na tela. O intervalo de um segundo do exemplo só incrementa activeSeconds quando o artigo está visível e o estado de visibilidade da aba é "visible", então uma aba deixada em segundo plano para de acumular tempo imediatamente.

Qual é um limite razoável para o crédito de tempo ativo em artigos longos?

O artigo limita o tempo ativo creditado para que uma aba deixada aberta durante o almoço não vire uma leitura de 40 minutos. A implementação de exemplo restringe activeSeconds com Math.min contra um teto maxCreditSeconds derivado do tempo de leitura estimado do artigo. Artigos longos continuam com uma janela generosa, só que não ilimitada.

Por que os eventos de registro devem disparar na confirmação do servidor e não no envio do formulário?

Envios de formulário do lado do cliente supercontam porque a validação pode falhar, requisições duplicadas podem acontecer e bots podem disparar formulários sem criar nada. Um evento confirmado pelo servidor só dispara quando a conta realmente existe, que é exatamente o que o analytics deveria representar. É por isso que o artigo trata o evento como uma transação financeira, confirmada primeiro e rastreada depois.

Quais campos são seguros para incluir em um evento registration_completed?

Fique com o nome do evento, o timestamp, uma referência anônima de visitante ou sessão quando disponível e permitida, o plano ou caminho de cadastro, a fonte UTM capturada na chegada, e o tipo de conta ou a faixa de tamanho do workspace. Deixe de fora email, nome, endereço IP, ID de usuário bruto, status de senha e campos de texto livre. Se precisar conectar eventos a contas internamente, guarde esse mapeamento no banco de dados do produto, não no evento de analytics.

Como a chave de idempotência evita eventos de registro duplicados?

A chave é construída a partir do próprio ID da conta, por exemplo registration:${account.id}, de modo que a plataforma de analytics reconhece um envio repetido como o mesmo evento em vez de um novo. Isso protege contra um usuário recarregando a página de sucesso ou um webhook tentando novamente após um timeout. O evento ainda assim dispara exatamente uma vez por conta criada, não importa quantas vezes o gatilho rodar.

Como verifico se o rastreamento de registro está realmente correto?

Reconciliar a contagem diária de eventos registration_completed com a criação de contas no banco de dados da aplicação. Os dois números devem bater dentro do comportamento esperado de novas tentativas e exclusões. Se divergirem, corrija primeiro o evento do lado do servidor antes de usar os números para atribuição de marketing.