Mesurer l'utilisation hors connexion

Comment effectuer le suivi de l'utilisation hors connexion de votre site afin de déterminer pourquoi votre site a besoin d'une meilleure expérience hors connexion.

Stephan Giesau

Martin Schierle

Cet article vous explique comment effectuer le suivi de l'utilisation hors connexion de votre site afin de vous aider à déterminer pourquoi nécessite un meilleur mode hors connexion. Il explique également les pièges et les problèmes à éviter lors de la mise en œuvre l'analyse de l'utilisation hors connexion.

Les pièges liés aux événements de navigateur en ligne et hors connexion

Pour suivre l'utilisation hors connexion, la solution évidente consiste à créer des écouteurs d'événements pour l'événement online et offline événements (qui compatible avec de nombreux navigateurs) et pour mettre en place le suivi dans ces écouteurs. Malheureusement, cette fonctionnalité présente plusieurs problèmes approche:

• En général, le suivi de chaque événement lié à l'état de la connexion réseau peut être excessif et est contre-productif dans un monde axé sur la confidentialité où le moins de données possible devrait être collectées. De plus, les événements online et offline peuvent se déclencher pendant une fraction de seconde une perte de réseau, qu’un utilisateur ne verrait probablement même pas voir ou remarquer.
• Le suivi des analyses de l'activité hors connexion n'atteindrait jamais le serveur d'analyse car l'utilisateur est... hors connexion.
• Suivi local d'un horodatage lorsqu'un utilisateur se déconnecte et envoie l'activité hors connexion à le serveur d'analyse lorsque l'utilisateur se reconnecte dépend de la présence de ce dernier sur votre site. Si l'utilisateur quitte votre site parce qu'il n'a pas de mode hors connexion et ne le retourne jamais, vous devez aucun moyen de le suivre. Le suivi des abandons hors connexion est une donnée essentielle cas où votre site a besoin d'un mode hors connexion plus efficace.
• L'événement online n'est pas très fiable, car il ne connaît que l'accès au réseau, et non un accès à Internet. Il est donc possible qu'un utilisateur soit toujours hors connexion, et l'envoi du ping de suivi échouent quand même.
• Même si l'utilisateur reste sur la page actuelle lorsqu'il est hors connexion, aucun des autres les événements d'analyse (par exemple, les événements de défilement, les clics, etc.) font également l'objet d'un suivi, ce qui peut être des informations pertinentes et utiles.
• Le fait d'être déconnecté en soi n'a pas non plus de sens en général. En tant que développeur de sites Web, il peut il est plus important de savoir quels types de ressources n'ont pas pu être chargés. C'est particulièrement pertinent dans le contexte des applications monopages, où l'interruption de la connexion réseau n'entraîne pas nécessairement la déconnexion du navigateur. page d'erreur (compréhensible par les utilisateurs), mais il est plus probable que des parties dynamiques de la page échouent de manière aléatoire. silencieusement.

Vous pouvez tout de même utiliser cette solution pour acquérir des connaissances de base sur l'utilisation hors connexion, les inconvénients et les limites doivent être pris en considération avec soin.

Une meilleure approche: le service worker

La solution qui active le mode hors connexion s'avère être la meilleure solution pour le suivi hors connexion. sur l'utilisation de l'IA générative. L'idée de base est de stocker les pings d'analyse dans IndexedDB tant que l'utilisateur est hors ligne, et les renvoyer simplement lorsque l'utilisateur se reconnecte. Cette fonctionnalité est déjà disponible pour Google Analytics. prêts à l'emploi via un module Workbox, mais gardez à l'esprit que les appels envoyés plus de report de quatre heures risque de ne pas être traité. Dans sa forme la plus simple, elle peut être activée dans un service basé sur Workbox avec ces deux lignes:

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

googleAnalytics.initialize();

Cela permet de suivre tous les événements existants et les pings de page vue tout en étant hors connexion, mais vous ne pouvez pas le savoir lorsqu'ils se sont produits hors connexion (car ils sont relancés en l'état). Pour cette Manipuler les requêtes de suivi avec Workbox en ajoutant un indicateur offline au ping d'analyse, à l'aide d'une dimension personnalisée (cd1 dans le code) ; voir l'exemple ci-dessous):

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

googleAnalytics.initialize({
  parameterOverrides: {
    cd1: 'offline',
  },
});

Que se passe-t-il si l'utilisateur quitte la page parce qu'il est hors connexion, avant qu'il ne dispose d'une connexion Internet ? en retour ? Même si cela met normalement le service worker en veille (car il est dans l'incapacité d'envoyer les données lorsque la connexion est rétablie), le module Workbox Google Analytics utilise la fonctionnalité Synchronisation en arrière-plan API, qui envoie les données des données plus tard lorsque la connexion est rétablie, même si l'utilisateur ferme l'onglet ou le navigateur.

Cela présente un inconvénient: même si le suivi existant est disponible hors connexion, vous ne verrez pas beaucoup de données pertinentes arriver tant que vous n'implémenterez pas un mode hors connexion de base. Les utilisateurs continueront abandonnent rapidement votre site lorsque la connexion est interrompue. Mais maintenant, vous pouvez au moins mesurer et quantifiez cela en comparant la durée moyenne des sessions et l'engagement utilisateur des utilisateurs hors ligne. appliquée par rapport à vos utilisateurs standards.

SPA et chargement différé

Si les utilisateurs visitant une page conçue comme un site web de plusieurs pages se déconnectent et tentent de naviguer, le navigateur par défaut s'affiche, aidant les utilisateurs à comprendre ce qui se passe. Cependant, les pages conçues les applications monopages fonctionnent différemment. L'utilisateur reste sur la même longueur d'onde et le nouveau contenu de manière dynamique via AJAX sans aucune navigation dans le navigateur. Les utilisateurs ne voient pas l'erreur du navigateur lorsque vous êtes hors connexion. Au lieu de cela, les parties dynamiques de la page s'affichent avec des erreurs, non définis, ou cessent d'être dynamiques.

Le chargement différé peut avoir des effets similaires sur les sites Web composés de plusieurs pages. Par exemple, peut-être que le le chargement initial s'est produit en ligne, mais l'utilisateur s'est déconnecté avant de faire défiler la page. Tout le contenu au chargement différé sous la ligne de flottaison échoueront silencieusement et seront absentes.

Comme ces situations sont très agaçantes pour les utilisateurs, il est judicieux de les suivre. Les service workers sont l'emplacement idéal pour détecter les erreurs réseau et les suivre à l'aide d'analyses. Avec Workbox, gestionnaire d'interception global peut être configuré pour signaler à la page les requêtes ayant échoué en envoyant un événement de message:

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();

  }());
});

Plutôt que d'écouter toutes les requêtes ayant échoué, une autre méthode consiste à détecter les erreurs sur des routes spécifiques. uniquement. Par exemple, si nous voulons signaler les erreurs qui se produisent sur les itinéraires vers /products/* uniquement, nous pouvons ajouter une vérification dans setCatchHandler qui filtre l'URI avec une expression régulière. Une solution plus propre consiste à implémenter RegisterRoute avec un gestionnaire personnalisé. Cela encapsule la logique métier dans une route distincte, offrant une meilleure gestion pour les service workers plus complexes:

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();
    }
  }
);

Pour finir, la page doit écouter l'événement message et envoyer le ping d'analyse. Là encore, veillez à mettre en mémoire tampon les requêtes d'analyse qui sont effectuées hors connexion dans le service worker. En tant que décrit précédemment, initialisez le plug-in workbox-google-analytics pour l'intégration de Google Analytics. de l'assistance.

L'exemple suivant utilise Google Analytics, mais peut s'appliquer de la même manière pour d'autres analyses fournisseurs.

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
      });
    }
  });
}

Cela permet de suivre les échecs de chargement des ressources dans Google Analytics, où vous pouvez les analyser création de rapports. L'insight ainsi obtenu peut être utilisé pour améliorer la mise en cache des service workers et la gestion des erreurs en général, afin de rendre la page plus robuste et fiable dans des conditions de réseau instables.

Étapes suivantes

Cet article présente différentes façons de suivre l'utilisation hors connexion, ainsi que leurs avantages et leurs inconvénients. Bien que cela puisse vous aider à quantifier le nombre de vos utilisateurs qui passent hors connexion et qui rencontrent des problèmes, ce n'est qu'un début. Tant que votre site Web ne propose pas un mode hors connexion bien conçu, vous les données hors connexion ne seront pas beaucoup utilisées dans les analyses.

Nous vous recommandons de mettre en place un suivi complet, puis d'étendre vos fonctionnalités hors connexion dans des itérations avec un œil sur les numéros de suivi. Commencez par une simple page d'erreur hors connexion, Workbox, il est facile À faire doit de toute façon être considérée comme une bonne pratique en matière d'expérience utilisateur, semblable aux pages 404 personnalisées. Travaillez à votre façon vers des solutions hors connexion plus avancées et enfin vers un vrai contenu hors ligne. N'oubliez pas d'en faire la publicité et de l'expliquer à vos utilisateurs. et vous constaterez une utilisation croissante. Après tout, tout le monde se déconnecte de temps en temps.

Découvrez comment générer des rapports sur les métriques et développer une culture de la performance. et comment corriger la vitesse du site Web de manière pluridisciplinaire. à persuader les partenaires pluridisciplinaires d'investir davantage dans votre site Web. Bien que ces publications axés sur les performances, ils devraient vous aider à obtenir des idées générales sur la façon d'interagir partenaires.

Photo principale de JC Gellidon sur Unsplash.