Una guía práctica de seguimiento del lado del servidor

Esta guía explica seguimiento del lado del servidor de forma práctica, con un enfoque en decisiones de analítica respetuosas con la privacidad.

El seguimiento analítico del lado del servidor es útil cuando el evento ocurre en su servidor o cuando el seguimiento del lado del cliente no es confiable. Dos ejemplos comunes son los lectores y registros de blogs. Un navegador puede estimar el progreso del artículo y el tiempo visible activo; el servidor puede decirle si realmente se creó una cuenta.

La mejor configuración combina ambos sin recopilar datos personales innecesarios.

Medir la lectura real de un blog

Una página vista es una métrica de contenido débil. Alguien puede rebotar inmediatamente, dejar la pestaña abierta o desplazarse hasta el final sin leer. Un mejor evento de "lectura" combina:

• Tiempo activo mínimo basado en el recuento de palabras.
• Profundidad de desplazamiento dentro del contenedor del artículo.
• Estado de visibilidad para que las pestañas de fondo no cuenten.
• Un evento único para que las actualizaciones no dupliquen las lecturas.

Por ejemplo, un artículo de 1200 palabras puede requerir al menos 5 minutos de tiempo activo a aproximadamente 220 a 250 palabras por minuto más un 80 por ciento de desplazamiento del artículo. No trate ese número como universal. Los documentos técnicos, el contenido legal y las publicaciones comparativas se leen a diferentes velocidades.

Ejemplo de evento del lado del 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);

Esto evita contar un desplazamiento rápido hacia el final como lectura. También limita el crédito de tiempo activo, se detiene cuando la página está oculta y utiliza un marcador de profundidad a nivel de artículo en lugar de medir la profundidad de desplazamiento en todo el documento.

Seguimiento de registro del lado del servidor

Se debe realizar un seguimiento de los registros después de que el servidor confirme el éxito, no cuando el usuario hace clic en enviar. El formulario del lado del cliente envía un recuento excesivo porque la validación puede fallar, pueden ocurrir solicitudes duplicadas y los bots pueden activar formularios.

Un evento del lado del servidor debe incluir sólo campos seguros:

• Nombre del evento: registration_completed.
• Marca de tiempo.
• Visitante anónimo o referencia de sesión si está disponible y es legal.
• Ruta de plan o registro.
• Fuente UTM capturada en el aterrizaje.
• Tipo de cuenta o tamaño del espacio de trabajo.

Evite el correo electrónico, el nombre, la dirección IP, la identificación de usuario sin formato, el estado de la contraseña o los campos de texto libre en los análisis. Si necesita conectar eventos a cuentas internamente, almacene esa asignación en la base de datos de su producto, no en un evento analítico de terceros.

Deduplicación

Utilice una clave de idempotencia para eventos del servidor. Un evento de registro debe activarse una vez por creación de cuenta, incluso si el usuario actualiza la página de éxito o si un webhook lo vuelve a intentar.

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

Lista de verificación de privacidad

• No realice un seguimiento de la lectura en páginas confidenciales a menos que sea necesario.
• Mantenga los eventos del artículo agregados siempre que sea posible.
• Elimine los parámetros de consulta antes de almacenar rutas.
• No envíes datos personales en propiedades del evento.
• Retención de documentos para eventos sin procesar.
• Respete los requisitos de consentimiento para el almacenamiento o los identificadores del lado del cliente.

El seguimiento del lado del servidor no respeta automáticamente la privacidad. Es mejor cuando registra eventos comerciales verificados con cargas útiles minimizadas. Utilice el navegador para señales que sólo el navegador pueda conocer y utilice el servidor para datos que sólo el servidor pueda confirmar.

Comprobaciones de calidad de datos

Compare los eventos de lectura de artículos con las páginas vistas. Si cada página vista se convierte en lectura, el umbral es demasiado bajo o el evento se activa al cargar. Si casi no aparecen lecturas para artículos largos con una gran participación, el cálculo de desplazamiento puede ser incorrecto porque utiliza el documento completo en lugar del contenedor del artículo.

Para registros, concilie los eventos de análisis con la base de datos de la aplicación. Un recuento diario de registration_completed debería coincidir con la creación de cuentas dentro del comportamiento esperado de reintento y eliminación. Si no es así, corrija el evento del servidor antes de usarlo para atribución de marketing.

Consentimiento y transparencia

Si el seguimiento utiliza solo eventos agregados y ningún almacenamiento en el dispositivo, la carga de privacidad es menor. Si configura identificadores, vincula eventos de lectura a cuentas o utiliza los datos para personalización, actualice el consentimiento y los avisos de privacidad en consecuencia. Del lado del servidor no significa invisible; Los usuarios todavía merecen una explicación honesta.

Detalles de confiabilidad que importan

Al enviar eventos de lectura desde el navegador, prefiera métodos de entrega diseñados para descargas de páginas. Beacon API permite que el navegador envíe una pequeña solicitud asincrónica sin bloquear la navegación, lo cual es útil para eventos analíticos que se activan cerca del final de una visita (MDN Baliza API). Mantenga las cargas útiles pequeñas y no sensibles porque las balizas no son un lugar para objetos de depuración grandes.

Para eventos de registro, diseñe el evento del lado del servidor como una transacción financiera:

• Dispárelo solo después de que se confirme la cuenta o el registro de registro.
• Incluir una clave de idempotencia basada en el registro interno.
• Vuelva a intentarlo de forma segura si el punto final de análisis no está disponible temporalmente.
• Almacene un breve registro de auditoría del estado de entrega.
• Conciliar los recuentos con la base de datos del producto.

Si la atribución es importante, capture UTMs en el momento del aterrizaje y guárdelos en un registro de atribución propia con un período de retención claro. Cuando el registro se realice correctamente, adjunte campos de campaña seguros, como fuente, medio, campaña y página de destino. No adjunte el historial de navegación completo del visitante.

Para análisis del tiempo de lectura, tenga cuidado con las pestañas que quedan abiertas. Cuente el tiempo visible activo, haga una pausa cuando la página esté oculta y considere una ventana de crédito máxima para que la pestaña de la pausa para el almuerzo no se convierta en una "lectura de 40 minutos". Para publicaciones muy breves, utilice un umbral mínimo; para publicaciones largas, evite requerir un desplazamiento del 100% porque los lectores pueden obtener valor antes de la biografía final del autor o la sección de publicaciones relacionadas.

La mejor señal no es sólo el "tiempo invertido". Es tiempo más un progreso significativo más una acción de seguimiento, como suscribirse al boletín informativo, visitar la página del producto o registrarse.

Control de calidad de lectura y registro

Trate la lectura del artículo como una señal de calidad del contenido, no como una prueba de que una persona identificable consumió cada palabra. Validar que:

• Una pestaña en segundo plano no acumula tiempo.
• Un desplazamiento rápido no activa una lectura.
• Los artículos largos limitan el crédito por tiempo activo.
• El evento se activa una vez por página vista.
• Las categorías de artículos confidenciales utilizan únicamente informes agregados.
• Los eventos de registro coinciden con cuentas comprometidas, no con clics en botones.

Mantenga separadas la señal del navegador y el dato del servidor. El navegador puede estimar una lectura significativa. El servidor puede confirmar el registro. Es útil combinarlos con cuidado; pretender que cualquiera de los dos es perfecto genera análisis ruidosos.