Mide el uso sin conexión

Cómo hacer un seguimiento del uso sin conexión de tu sitio para que puedas justificar por qué 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 ayudarte a justificar por qué tu sitio necesita un mejor modo sin conexión. También se explican las dificultades y los problemas que se deben evitar cuando se implementan las estadísticas de uso sin conexión.

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

La solución obvia para hacer un seguimiento del uso sin conexión es crear objetos de escucha de eventos para los eventos online y offline (que son compatibles con muchos navegadores) y colocar tu lógica de seguimiento de estadísticas en esos objetos de escucha. Lamentablemente, 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 contraproducente en un mundo centrado en la privacidad, en el que se deben recopilar la menor cantidad posible de datos. Además, los eventos online y offline pueden activarse durante una fracción de segundo de pérdida de red, que un usuario probablemente ni siquiera vería o 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á… sin conexión.
• El seguimiento de una marca de tiempo de forma 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 conectarse 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 hacer un seguimiento de las bajas sin conexión es un dato fundamental para crear un caso sobre 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 el envío del ping de seguimiento falle.
• Incluso si el usuario permanece en la página actual sin conexión, no se realiza un seguimiento de ninguno de los otros eventos de Analytics (p.ej., eventos de desplazamiento, clics, etc.), que podrían ser la información más relevante y útil.
• Estar sin conexión en sí 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 los SPA, en los que una conexión de red caída podría no generar una página de error sin conexión del navegador (que los usuarios comprenden), pero es más probable que falle de forma silenciosa en partes dinámicas aleatorias de la página.

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 trabajador de servicio

La solución que habilita el modo sin conexión resulta ser la mejor para hacer un seguimiento del uso sin conexión. La idea básica es almacenar los pings de Analytics en IndexedDB mientras el usuario esté sin conexión y volver a enviarlos cuando vuelva a conectarse. En el caso de Google Analytics, esta función ya está disponible listo 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 de demora. 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();

De esta manera, se realiza un seguimiento de todos los eventos existentes y los pings de vistas de página sin conexión, pero no sabrías que ocurrieron sin conexión (ya que solo se vuelven a reproducir tal como están). Para ello, puedes manipular las solicitudes de seguimiento con Workbox agregando una marca offline al ping de Analytics, con una dimensión personalizada (cd1 en el ejemplo de código que aparece a continuación):

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, esto pone en suspensión al trabajador del servicio (porque no puede enviar los datos cuando se restablece la conexión), el módulo de Google Analytics de Workbox usa la API de Background Sync, que envía los datos de estadísticas más adelante cuando se restablece la conexión, incluso si el usuario cierra la pestaña o el navegador.

Sin embargo, hay un inconveniente: si bien esto permite que el seguimiento existente funcione sin conexión, es probable 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 medir y cuantificar esto comparando la duración promedio de las sesiones y la participación de los usuarios con la dimensión sin conexión aplicada en comparación con tus usuarios habituales.

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, aparece la página sin conexión predeterminada del navegador, lo que ayuda a los usuarios a comprender lo que sucede. 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 se quedan sin conexión. En su lugar, las partes dinámicas de la página se renderizan con errores, entran en estados no definidos o simplemente dejan de ser dinámicas.

Debido a la carga diferida, pueden ocurrir efectos similares en los sitios web de varias páginas. Por ejemplo, es posible que la carga inicial se haya realizado en línea, pero que el usuario se haya desconectado 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á.

Dado que estos casos son muy molestos para los usuarios, tiene sentido hacerles un seguimiento. Los trabajadores de servicio son el lugar ideal para detectar errores de red y, con el tiempo, hacerles un seguimiento con estadísticas. Con Workbox, se puede configurar un controlador de captura global para informar a la página sobre las solicitudes fallidas 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 erróneas, otra forma es detectar errores solo en rutas específicas. A modo de ejemplo, si queremos informar errores que ocurren solo en las rutas a /products/*, podemos agregar una verificación en setCatchHandler que filtre el URI con una expresión regular. Una solución más clara es implementar registerRoute con un controlador personalizado. Esto encapsula la lógica empresarial en una ruta independiente, con una 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 último paso, la página debe escuchar el evento message y enviar el ping de estadísticas. Una vez más, asegúrate de almacenar en búfer las solicitudes de estadísticas que se realizan sin conexión dentro del servicio de trabajo. Como se describió antes, inicializa el complemento workbox-google-analytics para la compatibilidad integrada con Google Analytics.

En el siguiente ejemplo, se usa Google Analytics, pero se puede aplicar de la misma manera a 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. Las estadísticas derivadas se pueden usar para mejorar el almacenamiento en caché y el manejo de errores de los service workers en general, de modo 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 tienen problemas debido a esto, es solo el 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 que implementes el seguimiento completo y, luego, que extiendan tus capacidades sin conexión en iteraciones con atención a los números de seguimiento. Comienza con una página de error sin conexión simple (con Workbox es muy fácil hacerlo) y, de todos modos, se debe considerar 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 promocionar y explicar esto a tus usuarios de forma clara, y verás que el uso aumentará. 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 multifuncional 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.