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

El seguimiento del lado del servidor sirve cuando el evento ocurre en tu servidor o cuando el navegador no es fiable, como en lecturas de blog y registros.

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. Los lectores rebotan inmediatamente, dejan la pestaña abierta o se desplazan 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 es incorrecto: 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.

Preguntas frecuentes

¿Por qué una página vista subestima y sobreestima la lectura al mismo tiempo?

Una página vista se dispara en cuanto carga la página, así que cuenta un rebote, una pestaña dejada abierta y un scroll rápido hasta el final igual que una lectura real. Combinarla con un tiempo activo mínimo, la profundidad de scroll y el estado de visibilidad separa la lectura real de esos casos. Un evento de una sola vez encima evita que las recargas inflen el conteo todavía más.

¿Qué rango de palabras por minuto debería usar para el umbral de tiempo activo?

El artículo usa aproximadamente 220 a 250 palabras por minuto como punto de partida, lo que sitúa el tiempo activo mínimo de un artículo de 1.200 palabras en unos 5 minutos. Trátalo como una base, no como un número universal. La documentación técnica, el contenido legal y los artículos comparativos se leen a velocidades distintas, así que hay que recalibrar según el tipo de contenido.

¿Por qué medir la profundidad de scroll contra el contenedor del artículo en vez de todo el documento?

Medir contra todo el documento distorsiona el número cuando el encabezado, el pie de página o los artículos relacionados cambian el largo de la página. El ejemplo del lado del cliente ancla un marcador de profundidad del 80 por ciento dentro del propio elemento del artículo con un IntersectionObserver, de modo que el cálculo sigue al artículo y no al resto del diseño. Ese es también el arreglo cuando casi no aparecen lecturas en artículos largos con buen engagement.

¿Debería usar 100 por ciento de scroll como umbral de lectura?

Exigir un scroll completo en artículos largos puede dejar fuera a lectores que ya obtuvieron el valor antes de la biografía del autor o del bloque de artículos relacionados al final. El ejemplo usa 80 por ciento de profundidad de scroll en su lugar. En contenido extenso, evitar el umbral del 100 por ciento mantiene la métrica más cerca de lo que realmente significa "leer".

¿Cómo evito que una pestaña en segundo plano infle el tiempo activo?

Comprobar document.visibilityState junto con un IntersectionObserver que vigile si el artículo está en pantalla. El intervalo de un segundo del ejemplo solo incrementa activeSeconds cuando el artículo es visible y el estado de visibilidad de la pestaña es "visible", así que una pestaña dejada en segundo plano deja de acumular tiempo de inmediato.

¿Cuál es un límite razonable para el crédito de tiempo activo en artículos largos?

El artículo limita el tiempo activo acreditado para que una pestaña dejada abierta durante el almuerzo no cuente como una lectura de 40 minutos. La implementación de ejemplo acota activeSeconds con Math.min contra un techo maxCreditSeconds derivado del tiempo de lectura estimado del artículo. Los artículos largos siguen teniendo una ventana generosa, solo que no ilimitada.

¿Por qué deberían dispararse los eventos de registro al confirmar el servidor y no al enviar el formulario?

Los envíos de formulario del lado del cliente sobreestiman porque la validación puede fallar, pueden ocurrir solicitudes duplicadas y los bots pueden disparar formularios sin crear nada. Un evento confirmado por el servidor solo se dispara cuando la cuenta realmente existe, que es justo lo que se supone que representa el analytics. Por eso el artículo trata el evento como una transacción financiera, confirmada primero y registrada después.

¿Qué campos son seguros para incluir en un evento registration_completed?

Limítate al nombre del evento, la marca de tiempo, una referencia anónima de visitante o sesión donde sea posible y lícito, el plan o la vía de registro, la fuente UTM capturada en el aterrizaje, y el tipo de cuenta o el rango de tamaño del workspace. Deja fuera el correo, el nombre, la IP, el ID de usuario en bruto, el estado de la contraseña y los campos de texto libre. Si necesitas conectar eventos con cuentas internamente, guarda esa relación en la base de datos del producto, no en el evento de analytics.

¿Cómo evita la clave de idempotencia los eventos de registro duplicados?

La clave se construye a partir del propio ID de la cuenta, por ejemplo registration:${account.id}, de modo que la plataforma de analytics reconoce un envío repetido como el mismo evento en vez de uno nuevo. Eso protege contra que un usuario recargue la página de éxito o que un webhook reintente tras un tiempo de espera agotado. El evento igual se dispara exactamente una vez por cuenta creada sin importar cuántas veces se dispare el trigger.

¿Cómo compruebo si el tracking de registros es realmente preciso?

Concilia el conteo diario de eventos registration_completed contra la creación de cuentas en la base de datos de la aplicación. Los dos números deberían coincidir dentro del comportamiento esperado de reintentos y eliminaciones. Si difieren, corrige primero el evento del lado del servidor antes de usar los números para atribución de marketing.