Mide el uso sin conexión

Cómo hacer un seguimiento del uso sin conexión de tu sitio para justificar por qué tu sitio necesita una mejor experiencia sin conexión

Stephan Giesau

Martin Schierle

En este artículo, se muestra cómo hacer un seguimiento del uso sin conexión de tu sitio para fundamentar por qué este necesita un mejor modo sin conexión. También se explican las dificultades y los problemas que se deben evitar cuando se implementan estadísticas de uso sin conexión.

Las dificultades de los eventos en línea y sin conexión del navegador

La solución obvia para realizar un seguimiento del uso sin conexión es crear objetos de escucha de eventos para los eventos online y offline (compatibles con muchos navegadores) y colocar tu lógica de seguimiento de estadísticas en esos objetos de escucha. Por desgracia, este enfoque tiene varios problemas y limitaciones:

• En general, hacer un seguimiento de cada evento de estado de conexión de red puede ser excesivo y es contraproducente en un mundo centrado en la privacidad en el que se debe recopilar la menor cantidad de datos posible. Además, los eventos online y offline pueden activarse solo durante una fracción de segundo de pérdida de red, algo que un usuario probablemente no vería ni notaría.
• El seguimiento de estadísticas de la actividad sin conexión nunca llegaría al servidor de estadísticas porque el usuario está... bueno, sin conexión.
• El seguimiento de una marca de tiempo local cuando un usuario se desconecta y el envío de la actividad sin conexión al servidor de estadísticas cuando el usuario vuelve a estar en línea depende de que el usuario vuelva a visitar tu sitio. Si el usuario abandona tu sitio debido a la falta de un modo sin conexión y nunca vuelve a visitarlo, no tienes forma de hacer un seguimiento de eso. La capacidad de realizar un seguimiento de los abandonos sin conexión es un dato fundamental para justificar por qué tu sitio necesita un mejor modo sin conexión.
• El evento online no es muy confiable, ya que solo conoce el acceso a la red, no el acceso a Internet. Por lo tanto, es posible que un usuario siga sin conexión y que falle el envío del ping de seguimiento.
• Incluso si el usuario permanece en la página actual sin conexión, no se hace un seguimiento de ninguno de los demás eventos de estadísticas (p.ej., eventos de desplazamiento, clics, etc.), lo que podría ser la información más relevante y útil.
• Estar sin conexión en sí mismo tampoco es muy significativo en general. Como desarrollador de sitios web, puede ser más importante saber qué tipos de recursos no se pudieron cargar. Esto es especialmente relevante en el contexto de las SPA, en los que una caída de la conexión de red no genera una página de error del navegador sin conexión (que los usuarios entienden), pero es más probable que partes dinámicas aleatorias de la página fallen silenciosamente.

Puedes usar esta solución para obtener una comprensión básica del uso sin conexión, pero debes considerar con cuidado las numerosas desventajas y limitaciones.

Un mejor enfoque: el service worker

La solución que habilita el modo sin conexión resulta ser la mejor solución para realizar un seguimiento del uso sin conexión. La idea básica es almacenar pings de estadísticas en IndexedDB siempre que el usuario esté sin conexión y solo reenviarlos cuando el usuario vuelva a estar en línea. Para Google Analytics, esto ya está disponible lista para usar a través de un módulo de Workbox, pero ten en cuenta que es posible que no se procesen los hits enviados con más de cuatro horas aplazadas. En su forma más sencilla, se puede activar dentro de un service worker basado en Workbox con estas dos líneas:

import * as googleAnalytics from 'workbox-google-analytics';

googleAnalytics.initialize();

Esto realiza un seguimiento de todos los eventos y pings de vistas de páginas existentes mientras está sin conexión, pero no sabrías que ocurrieron sin conexión (ya que se vuelven a reproducir tal como están). Para ello, puedes manipular las solicitudes de seguimiento con Workbox. Para ello, agrega una marca offline al ping de estadísticas mediante una dimensión personalizada (cd1 en la siguiente muestra de código):

import * as googleAnalytics from 'workbox-google-analytics';

googleAnalytics.initialize({
  parameterOverrides: {
    cd1: 'offline',
  },
});

¿Qué sucede si el usuario abandona la página debido a que no tiene conexión, antes de que vuelva a conectarse a Internet? Aunque, por lo general, se suspende el service worker (porque no puede enviar los datos cuando se restablece la conexión), el módulo de Google Analytics de Workbox usa la API de sincronización en segundo plano, que envía los datos de estadísticas más tarde cuando se restablece la conexión, incluso si el usuario cierra la pestaña o el navegador.

Todavía existe una desventaja: si bien esto permite que el seguimiento sin conexión existente pueda usarse, lo más probable es que no veas muchos datos relevantes hasta que implementes un modo sin conexión básico. De todos modos, los usuarios abandonarían tu sitio rápidamente si se rompía la conexión. Pero ahora, al menos, puedes medirlo y cuantificarlo comparando la duración promedio de la sesión y la participación de los usuarios con la dimensión sin conexión aplicada en comparación con los usuarios normales.

SPA y carga diferida

Si los usuarios que visitan una página creada como un sitio web de varias páginas se desconectan y tratan de navegar, se muestra la página sin conexión predeterminada del navegador, que ayuda a los usuarios a comprender lo que está sucediendo. Sin embargo, las páginas compiladas como aplicaciones de una sola página funcionan de manera diferente. El usuario permanece en la misma página y el contenido nuevo se carga de forma dinámica a través de AJAX sin navegación en el navegador. Los usuarios no ven la página de error del navegador cuando están sin conexión. En cambio, las partes dinámicas de la página se renderizan con errores, pasan a estados indefinidos o simplemente dejan de ser dinámicas.

Se pueden producir efectos similares en los sitios web de varias páginas debido a la carga diferida. Por ejemplo, es posible que la carga inicial se haya producido en línea, pero el usuario se desconectó antes de desplazarse. Todo el contenido de carga diferida en la parte inferior de la página fallará de manera silenciosa y no se mostrará.

Como estos casos son muy molestos para los usuarios, tiene sentido realizar un seguimiento de ellos. Los service workers son el lugar perfecto para detectar errores de red y, con el tiempo, hacerles un seguimiento mediante estadísticas. Con Workbox, se puede configurar un controlador de captura global para informar a la página sobre las solicitudes con errores mediante el envío de un evento de mensaje:

import { setCatchHandler } from 'workbox-routing';

setCatchHandler(({ event }) => {
  // https://developer.mozilla.org/docs/Web/API/Client/postMessage
  event.waitUntil(async function () {
    // Exit early if we don't have access to the client.
    // Eg, if it's cross-origin.
    if (!event.clientId) return;

    // Get the client.
    const client = await clients.get(event.clientId);
    // Exit early if we don't get the client.
    // Eg, if it closed.
    if (!client) return;

    // Send a message to the client.
    client.postMessage({
      action: "network_fail",
      url: event.request.url,
      destination: event.request.destination
    });

    return Response.error();

  }());
});

En lugar de escuchar todas las solicitudes con errores, otra forma es detectar solo los errores en rutas específicas. Por ejemplo, si queremos informar errores que se producen en las rutas a /products/* solamente, podemos agregar una verificación en setCatchHandler que filtre el URI con una expresión regular. Una solución más limpia es implementar registerRoute con un controlador personalizado. Esto encapsula la lógica empresarial en una ruta independiente, con mejor capacidad de mantenimiento en service workers más complejos:

import { registerRoute } from 'workbox-routing';
import { NetworkOnly } from 'workbox-strategies';

const networkOnly = new NetworkOnly();
registerRoute(
  new RegExp('https:\/\/example\.com\/products\/.+'),
  async (params) => {
    try {
      // Attempt a network request.
      return await networkOnly.handle(params);
    } catch (error) {
      // If it fails, report the error.
      const event = params.event;
      if (!event.clientId) return;
      const client = await clients.get(event.clientId);
      if (!client) return;

      client.postMessage({
        action: "network_fail",
        url: event.request.url,
        destination: "products"
      });

      return Response.error();
    }
  }
);

Como paso final, la página debe escuchar el evento message y enviar el ping de estadísticas. Nuevamente, asegúrate de almacenar en búfer las solicitudes de análisis que se producen sin conexión dentro del service worker. Como se describió antes, inicializa el complemento workbox-google-analytics para obtener la compatibilidad integrada con Google Analytics.

En el siguiente ejemplo, se usa Google Analytics, pero se puede aplicar de la misma manera para otros proveedores de estadísticas.

if ("serviceWorker" in navigator) {
  // ... SW registration here

  // track offline error events
  navigator.serviceWorker.addEventListener("message", event => {
    if (gtag && event.data && event.data.action === "network_fail") {
      gtag("event", "network_fail", {
        event_category: event.data.destination,
        // event_label: event.data.url,
        // value: event.data.value
      });
    }
  });
}

Esto realizará un seguimiento de las cargas de recursos con errores en Google Analytics, donde se pueden analizar con los informes. La estadística derivada se puede usar para mejorar el almacenamiento en caché del service worker y el manejo de errores en general, con el objetivo de que la página sea más sólida y confiable en condiciones de red inestables.

Próximos pasos

En este artículo, se mostraban diferentes formas de realizar un seguimiento del uso sin conexión, así como sus ventajas y desventajas. Si bien esto puede ayudar a cuantificar cuántos de tus usuarios se desconectan y encuentran problemas debido a ello, solo es un comienzo. Siempre que tu sitio web no ofrezca un modo sin conexión bien diseñado, no verás mucho uso sin conexión en Analytics.

Te recomendamos implementar el seguimiento completo y, luego, ampliar tus capacidades sin conexión de forma iterativa con atención a los números de seguimiento. Comienza con una página de error simple sin conexión primero con Workbox es sencillo y debe considerarse una práctica recomendada de UX similar a las páginas 404 personalizadas. Luego, busca opciones para usar resguardos sin conexión más avanzados y, por último, contenido sin conexión real. Asegúrate de anunciar y explicar esto a los usuarios bien y verás un aumento en el uso. Después de todo, todos se desconectan de vez en cuando.

Consulta Cómo generar informes sobre métricas y crear una cultura de rendimiento y Cómo corregir la velocidad del sitio web de manera interfuncional para obtener sugerencias sobre cómo persuadir a las partes interesadas interfuncionales para que inviertan más en tu sitio web. Aunque esas publicaciones se centran en el rendimiento, deberían ayudarte a obtener ideas generales sobre cómo interactuar con las partes interesadas.

Foto hero de JC Gellidon en Unsplash.