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é tu sitio necesita una mejor experiencia sin conexión

Stephan Giesau

Martin Schierle

Aprende a hacer un seguimiento del uso sin conexión de tu sitio para que puedas justificar por qué tu sitio necesita un mejor modo sin conexión. Comprender qué dificultades y problemas se deben evitar cuando se implementan las estadísticas de uso sin conexión

Las dificultades de los eventos de 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 muchos navegadores admiten) 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 de datos posible. Además, los eventos online y offline pueden activarse por solo una fracción de segundo de pérdida de red, lo que un usuario probablemente ni siquiera vería o notaría.
• El seguimiento de estadísticas de la actividad sin conexión no llega al servidor de estadísticas.
• Hacer un seguimiento de una marca de tiempo de forma local cuando un usuario se desconecta y enviar la actividad sin conexión al servidor de Analytics 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 desconexiones 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 aún esté sin conexión y que el envío del ping de seguimiento siga fallando.
• 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 Analytics (p.ej., eventos de desplazamiento, clics, etc.), que podrían ser la información más relevante y útil.
• Estar sin conexión no es muy significativo. Es probable que lo más importante sea saber qué recursos no se cargan. Esto es especialmente relevante para las aplicaciones de una sola página (SPA), en las que una conexión de red interrumpida podría no generar una página de error sin conexión del navegador, que los usuarios comprenden. En cambio, es probable que provoque que partes dinámicas y aleatorias de la página fallen de forma silenciosa.

Aún puedes usar esta solución para obtener una comprensión básica del uso sin conexión, pero debes considerar cuidadosamente las numerosas desventajas y limitaciones.

Un mejor enfoque: El service worker

La solución que habilita el modo sin conexión también es una mejor solución para hacer un seguimiento del uso sin conexión. Puedes almacenar 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, esto ya está disponible en un módulo de Workbox, pero ten en cuenta que es posible que no se procesen los hits que se envíen con más de cuatro horas de retraso.

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 existentes y los pings de vistas de página mientras no hay conexión, pero no sabrías que ocurrieron sin conexión, ya que solo se reproducen tal como están. Puedes manipular las solicitudes de seguimiento con Workbox agregando una marca offline al ping de Analytics, con una dimensión personalizada:

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

googleAnalytics.initialize({
  parameterOverrides: {
    customDimension1: '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? Si bien esto normalmente pone en suspensión al service worker, ya que 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. La sincronización en segundo plano envía los datos de Analytics 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 hace que el seguimiento existente sea compatible con el modo sin conexión, es probable que no veas muchos datos relevantes hasta que implementes un modo sin conexión básico. Los usuarios seguirían abandonando tu sitio rápidamente cuando se interrumpa la conexión. Sin embargo, ahora puedes medir y cuantificar esto, al menos, comparando la duración promedio de las sesiones y la participación de los usuarios que tienen aplicada la dimensión sin conexión con las de los usuarios habituales.

SPAs 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 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 del 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, entran en estados indefinidos o simplemente dejan de ser dinámicas.

Pueden ocurrir efectos similares en sitios web de varias páginas debido a la carga diferida. Por ejemplo, tal vez la carga inicial se realizó en línea, pero el usuario se desconectó antes de desplazarse. Todo el contenido de carga diferida debajo de la mitad inferior de la página fallará de forma silenciosa y faltará.

Como estos casos son muy molestos para los usuarios, tiene sentido hacer un seguimiento de ellos. Los service workers son el lugar perfecto para detectar errores de red y, con el tiempo, hacer un seguimiento de ellos con las estadísticas. Con Workbox, se puede configurar un controlador de captura global para informar a la página sobre las solicitudes con errores enviando 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. Por ejemplo, si solo queremos informar los errores que se producen 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();
    }
  }
);

Como paso final, la página debe escuchar el evento message y enviar el ping de Analytics. Una vez más, asegúrate de almacenar en búfer las solicitudes de estadísticas que se producen sin conexión dentro del service worker. 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 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 hará un seguimiento de las cargas de recursos fallidas en Google Analytics, donde se pueden analizar con informes. La información derivada se puede usar para mejorar el almacenamiento en caché del service worker y el manejo de errores en general, para que la página sea más sólida y confiable en condiciones de red inestables.

Próximos pasos

Aprendiste 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 tienen problemas debido a ello, es solo el comienzo. Mientras tu sitio web no ofrezca un modo sin conexión bien diseñado, obviamente no verás mucho uso sin conexión en las estadísticas.

Te recomendamos que implementes el seguimiento completo y, luego, extiendas tus capacidades sin conexión en iteraciones, con un enfoque en el seguimiento. Comienza con una página de error sin conexión. Esto es fácil de crear con Workbox y es una práctica recomendada de UX similar a las páginas 404 personalizadas. Luego, trabaja para lograr resguardos sin conexión más avanzados y, por último, contenido real sin conexión. Asegúrate de promocionar y explicar bien esta función a tus usuarios, y verás que el uso aumentará. Después de todo, todo el mundo se desconecta 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 interdisciplinaria para obtener sugerencias sobre cómo persuadir a las partes interesadas interdisciplinarias 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.