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

Este guia explica rastreamento server-side de analytics na prática, com foco em decisões de analytics que respeitam a privacidade.

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. Alguém pode pular imediatamente, deixar a aba aberta ou rolar 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 pode estar errado porque 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.