Mide el uso sin conexión

Cómo hacer un seguimiento del uso sin conexión de tu sitio para que puedas argumentar por qué 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 explicar por qué necesita un mejor modo sin conexión. Comprende qué problemas y dificultades debes evitar cuando implementes las estadísticas de uso sin conexión.

Los inconvenientes 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 muchos navegadores admiten) y colocar tu lógica de seguimiento de análisis en esos objetos de escucha. Desafortunadamente, 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 debe recopilar la menor cantidad de datos posible. Además, los eventos online y offline se pueden activar por una fracción de segundo de pérdida de red, que probablemente un usuario 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.
• 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 Analytics cuando el usuario vuelve a conectarse dependen de que el usuario vuelva a visitar tu sitio. Si el usuario abandona tu sitio porque no tiene modo sin conexión y nunca vuelve a visitarlo, no tendrás forma de hacer un seguimiento de eso. La capacidad de hacer un seguimiento de las desconexiones sin conexión es un dato fundamental para argumentar 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.), lo que podría ser la información más relevante y útil.
• Estar sin conexión no es muy significativo. Probablemente, lo más importante sea saber qué recursos no se cargan. Esto es especialmente importante 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 fallas silenciosas en partes dinámicas y aleatorias de la página.

Aun así, puedes usar esta solución para comprender el uso sin conexión, pero debes tener en cuenta cuidadosamente los numerosos inconvenientes 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 estar en línea. 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 se está sin conexión, pero no sabrías que ocurrieron sin conexión, ya que solo se reproducen tal como son. 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 por no tener conexión antes de que se restablezca la conexión a Internet? Si bien esto normalmente pone en suspensión al trabajador de servicio, 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. Background Sync 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, aún existe 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án abandonando tu sitio rápidamente cuando se interrumpa la conexión. Sin embargo, ahora puedes, al menos, medir y cuantificar esto comparando la duración promedio de la sesión y la participación de los usuarios que tienen aplicada la dimensión sin conexió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, aparecerá la página sin conexión predeterminada del navegador, lo que les ayudará a comprender lo que sucede. 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 su lugar, las partes dinámicas de la página se renderizan con errores, entran en 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 realizado en línea, pero el usuario se desconectó antes de desplazarse. Todo el contenido cargado de forma diferida que se encuentre debajo del pliegue fallará de forma silenciosa y no se mostrará.

Dado que estos casos son muy 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 con estadísticas. Con Workbox, se puede configurar un controlador de captura global para informar a la página sobre las solicitudes fallidas 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 fallidas, otra forma es detectar errores solo en rutas específicas. Por ejemplo, si queremos informar los errores que ocurren en las rutas a /products/* únicamente, 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 detectar el evento message y enviar el ping de Analytics. Una vez más, 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ó anteriormente, 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 hará un seguimiento de las cargas de recursos fallidas 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 control 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 pierden la conexión y tienen problemas debido a ello, es solo el comienzo. Mientras tu sitio web no ofrezca un modo sin conexión bien desarrollado, 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. Crear con Workbox es trivial y es una práctica recomendada de UX similar a las páginas 404 personalizadas. Luego, trabaja para implementar copias de seguridad sin conexión más avanzadas y, finalmente, contenido sin conexión real. Asegúrate de promocionar y explicar bien esto a tus usuarios, y verás un aumento en el uso. Después de todo, todos nos desconectamos 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 interfuncional para obtener sugerencias sobre cómo persuadir a las partes interesadas interfuncionales para que inviertan más en tu sitio web. Si bien esas publicaciones se centran en el rendimiento, deberían ayudarte a obtener ideas generales sobre cómo involucrar a las partes interesadas.