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
Stephan Giesau
Martin Schierle
Martin Schierle

En este artículo, se explica cómo hacer un seguimiento del uso sin conexión de tu sitio para fundamentar el motivo de tu el sitio necesita un mejor modo sin conexión. También se explican las dificultades y los problemas que se deben evitar al implementar 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 el online y offline eventos (que admiten muchos navegadores) y poner el seguimiento de Analytics lógica en esos objetos de escucha. Lamentablemente, esto tiene varios problemas y limitaciones enfoque:

  • En general, el 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 la menor cantidad de datos posible de los datos recopilados. Además, los eventos online y offline pueden activarse durante una fracción de segundo de pérdida de red, que el usuario probablemente ni siquiera vería ni notaría.
  • El seguimiento analítico de la actividad sin conexión nunca llegaría al servidor de análisis porque el usuario está... bueno, sin conexión.
  • Se realiza el seguimiento local de una marca de tiempo cuando un usuario se desconecta y se envía la actividad sin conexión a del servidor de análisis 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, tienes forma de hacer un seguimiento de eso. La capacidad de realizar un seguimiento de los abandonos sin conexión es fundamental para crear un 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 con el acceso a Internet. Por lo tanto, es posible que el usuario aún esté sin conexión, por lo que enviar el ping de seguimiento aún fallan.
  • Incluso si el usuario permanece en la página actual sin conexión, los demás de Google Analytics (p.ej., eventos de desplazamiento, clics, etc.), lo que puede información 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é tipo de recursos no se cargaron. Esto es especialmente relevante en el contexto de SPA, en los que una caída de la conexión de red puede no provocar que el navegador esté sin conexión. página de error (que los usuarios entienden), pero es más probable que fallen partes dinámicas de la página. en silencio.

Puedes usar esta solución para tener conocimientos básicos del uso sin conexión, pero desventajas y limitaciones deben considerarse con cuidado.

Un mejor enfoque: el service worker

La solución que habilita el modo sin conexión resulta ser la mejor solución para el seguimiento sin conexión. de uso de la nube. La idea básica es almacenar pings de análisis en IndexedDB siempre que el usuario esté sin conexión, y volver a enviarlos cuando el usuario vuelva a conectarse. En Google Analytics, esta opción ya está disponible. lista para usar a través de un módulo de Workbox pero ten en cuenta que los hits enviaron más de cuatro horas de aplazamiento puede que no se procese. En su forma más sencilla, se puede activar dentro de un servicio 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áginas existentes mientras se trabaja sin conexión, pero esto no te sabrías. se llevan a cabo sin conexión (ya que se reproducen sin modificaciones). Para este se pueden manipular las solicitudes de seguimiento con Workbox Agregando una marca offline al ping de Analytics con una dimensión personalizada (cd1 en el código (ejemplo 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 llegue a Internet? de vuelta? A pesar de que, por lo general, se suspende el service worker (porque no puede enviar los datos cuando vuelve la conexión), el módulo Workbox de Google Analytics usa la función de sincronización en segundo plano API, que envía las estadísticas datos más tarde cuando se recupere 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 realizarse, lo más probable es que no vea que ingresan muchos datos relevantes hasta que implemente un modo sin conexión básico. Los usuarios todavía abandonan el sitio rápidamente cuando se interrumpe la conexión. Pero ahora, al menos, puedes medir para cuantificarlo comparando la duración promedio de las sesiones y la participación de los usuarios en las sesiones sin conexión dimensión aplicada en comparación con 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 e intentan navegar, la interfaz del navegador aparecerá una página sin conexión predeterminada para ayudar a los usuarios a entender lo que sucede. Sin embargo, las páginas creadas como las aplicaciones de una sola página funcionan de manera diferente. El usuario permanece en la misma página y el contenido nuevo se se cargan de forma dinámica a través de AJAX sin navegación en el navegador. Los usuarios no ven el error del navegador cuando estés sin conexión. En cambio, las partes dinámicas de la página se renderizan con errores, en estados indefinidos o simplemente dejar de ser dinámico.

Se pueden producir efectos similares en los sitios web de varias páginas debido a la carga diferida. Por ejemplo, tal vez el La carga inicial se llevó a cabo 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á y no estará disponible.

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, rastrearlos con estadísticas. Con Workbox, una controlador de captura global se puede configurar para informar a la página sobre 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 en rutas específicas solamente. Por ejemplo, si solo queremos informar errores que se producen en las rutas a /products/*, podemos Agrega 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 el 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 que se describió anteriormente, inicializa el complemento workbox-google-analytics para la versión integrada de Google Analytics y asistencia.

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

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 con errores en Google Analytics, donde se pueden analizar con de informes. La estadística derivada puede ser se usan 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

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 la cantidad de usuarios que se desconectan y tienen esto es solo el comienzo. Siempre que su sitio web no ofrezca un modo sin conexión bien diseñado, por supuesto, no se verán mucho los datos de uso sin conexión en Analytics.

Le recomendamos implementar todo el seguimiento y, luego, ampliar las capacidades sin conexión para iteraciones, prestando atención a los números de seguimiento. Comienza con una página de error sencilla sin conexión primero con La caja de trabajo es trivial hacer y de todos modos, debe considerarse una práctica recomendada de UX similar a las páginas 404 personalizadas. Luego, trabaja a tu manera hacia resguardos sin conexión más avanzados y, finalmente, hacia el contenido real sin conexión. Asegúrate de publicar anuncios y explícaselo a tus usuarios. 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 forma multidisciplinaria para obtener sugerencias. de persuadir a los interesados multidisciplinarios 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 atraer interesados.

Foto hero de JC Gellidon en Unsplash.