Mide el uso sin conexión

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

Stephan Giesau

Martin Schierle

En este artículo, se explica cómo hacer un seguimiento del uso sin conexión de un sitio para ayudarte a argumentar 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 las estadísticas de uso sin conexión.

Las dificultades de los eventos de navegación 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 muchos navegadores admiten), y colocar la lógica de seguimiento de estadísticas en esos objetos de escucha. Lamentablemente, este enfoque tiene varios problemas y limitaciones:

• En general, el seguimiento de cada evento de estado de conexión de red puede ser excesivo y es contraproductivo 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 durante solo una fracción de segundo de pérdida de red, 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.
• Hacer un seguimiento local de una marca de tiempo cuando un usuario se desconecta y enviar 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 hacer un seguimiento de los abandonos sin conexión es un dato fundamental para plantear 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 aún esté sin conexión y que el envío del ping de seguimiento falle.
• Incluso si el usuario permanece en la página actual mientras está sin conexión, tampoco se hace un seguimiento de ninguno de los otros eventos de estadísticas (p.ej., eventos de desplazamiento, clics, etc.), que podría ser la información más relevante y útil.
• Estar sin conexión en sí mismo tampoco es demasiado significativo en general. Como desarrollador de sitios web, puede ser más importante saber qué tipos de recursos no se cargaron. Esto es especialmente relevante en el contexto de las SPA, en las que una conexión de red interrumpida puede no conducir a una página de error sin conexión del navegador (que los usuarios entienden), pero es más probable que partes dinámicas aleatorias de la página fallen de forma silenciosa.

Puedes utilizar esta solución para obtener conocimientos básicos sobre el uso sin conexión, pero se deben 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 opción para realizar un seguimiento del uso sin conexión. La idea básica es almacenar pings de estadísticas en IndexedDB, siempre y cuando el usuario esté sin conexión, y volver a enviarlos cuando el usuario vuelva a estar en línea. En el caso de Google Analytics, esto ya está disponible mediante un módulo de Caja de trabajo, pero ten en cuenta que es posible que los hits enviados más de cuatro horas aplazadas no se procesen. En su forma más simple, 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 hace un seguimiento de todos los eventos y pings de vistas de página existentes mientras están sin conexión, pero no sabrías que ocurrieron sin conexión (ya que solo se vuelven a reproducir sin conexión). Para ello, puedes manipular las solicitudes de seguimiento con Workbox. Para ello, agrega una marca offline al ping de Analytics con 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 porque no tiene conexión, antes de que se restablezca la conexión a Internet? Aunque esto normalmente pone en modo de suspensión al service worker (porque no puede enviar los datos cuando vuelve 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.

Aún existe una desventaja: si bien esto permite que el seguimiento existente funcione sin conexión, es probable que no veas muchos datos relevantes entrantes hasta que implementes un modo sin conexión básico. Los usuarios abandonarían tu sitio rápidamente cuando se rompiera la conexión. Pero ahora puedes, al menos, 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 la de tus 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, lo que ayuda a los usuarios a comprender lo que está sucediendo. Sin embargo, las páginas creadas 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 ninguna navegación en el navegador. Los usuarios no ven la página de error del navegador cuando se desconectan. En cambio, las partes dinámicas de la página se renderizan con errores, pasan a estados definidos o simplemente dejan de ser dinámicas.

En los sitios web de varias páginas, pueden producirse efectos similares debido a la carga diferida. Por ejemplo, es posible que la carga inicial se haya realizado en línea, pero el usuario se quedó sin conexión antes de desplazarse. Todo el contenido de carga diferida que se encuentra en la mitad inferior de la página fallará silenciosamente y no estará disponible.

Como estos casos son realmente irritantes para los usuarios, tiene sentido hacerles un seguimiento. Los service workers son el lugar perfecto para detectar errores de red y, luego, 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 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 con errores, otra forma es detectar errores solo en rutas específicas. A modo de ejemplo, si queremos informar errores que ocurran 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 limpia es implementar registerRoute con un controlador personalizado. Esto encapsula la lógica empresarial en una ruta separada, 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();
    }
  }
);

Por último, 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 análisis que ocurren sin conexión en el service worker. Como se describió antes, inicializa el complemento workbox-google-analytics para obtener 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 fallidas en Google Analytics, donde se pueden analizar con 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 muestran diferentes formas de hacer un seguimiento del uso sin conexión con sus ventajas y desventajas. Si bien esto puede ayudar a cuantificar cuántos de tus usuarios se desconectan y se encuentran con problemas debido a esto, esto no es más que un comienzo. Siempre que tu sitio web no ofrezca un modo sin conexión bien compilado, obviamente no verás mucho uso sin conexión en Analytics.

Te recomendamos implementar el seguimiento completo y, luego, ampliar tus capacidades sin conexión en iteraciones teniendo en cuenta las cifras de seguimiento. Comienza con una página de error sin conexión simple (con Workbox es trivial de hacer) y, de todos modos, debería considerarse una práctica recomendada de UX similar a las páginas 404 personalizadas. Luego, abre el camino hacia resguardos sin conexión más avanzados y, por último, hacia contenido sin conexión real. Asegúrate de anunciarlo y explicárselo a los usuarios, y el uso aumentará. Después de todo, todos se desconectan de vez en cuando.

Consulta Cómo informar métricas y crear una cultura de rendimiento y Cómo corregir la velocidad del sitio web de forma multidisciplinaria para obtener sugerencias sobre cómo persuadir a las partes interesadas multifuncionales para que inviertan más en tu sitio web. Aunque esas publicaciones se enfocan 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.