Mesurer l'utilisation hors connexion

Découvrez comment suivre l'utilisation hors connexion de votre site pour justifier la nécessité d'améliorer l'expérience hors connexion.

Stephan Giesau

Martin Schierle

Découvrez comment suivre l'utilisation hors connexion de votre site pour justifier la nécessité d'un meilleur mode hors connexion. Découvrez les pièges et les problèmes à éviter lors de l'implémentation de l'analyse de l'utilisation hors connexion.

Les pièges des événements de navigateur en ligne et hors connexion

La solution évidente pour suivre l'utilisation hors connexion consiste à créer des écouteurs d'événements pour les événements online et offline (que de nombreux navigateurs prennent en charge) et à placer votre logique de suivi des données analytiques dans ces écouteurs. Malheureusement, cette approche présente plusieurs problèmes et limites :

• En général, le suivi de chaque événement d'état de connexion réseau peut être excessif et contre-productif dans un monde axé sur la confidentialité, où le moins de données possible doit être collecté. De plus, les événements online et offline peuvent se déclencher pour une perte de réseau d'une fraction de seconde, ce que l'utilisateur ne verra ni ne remarquera probablement même pas.
• Le suivi analytique de l'activité hors connexion n'atteint pas le serveur Analytics.
• Le suivi d'un code temporel en local lorsqu'un utilisateur se déconnecte et l'envoi de l'activité hors connexion au serveur Analytics lorsqu'il se reconnecte dépendent de la visite de l'utilisateur sur votre site. Si l'utilisateur quitte votre site en raison de l'absence de mode hors connexion et n'y revient jamais, vous n'avez aucun moyen de le savoir. La possibilité de suivre les abandons hors connexion est une donnée essentielle pour justifier pourquoi votre site a besoin d'un meilleur mode hors connexion.
• L'événement online n'est pas très fiable, car il ne connaît que l'accès au réseau, et non l'accès à Internet. Par conséquent, un utilisateur peut toujours être hors connexion et l'envoi du ping de suivi peut toujours échouer.
• Même si l'utilisateur reste sur la page actuelle lorsqu'il est hors connexion, aucun autre événement Analytics (par exemple, les événements de défilement, les clics, etc.) n'est suivi non plus, ce qui pourrait être l'information la plus pertinente et la plus utile.
• Le simple fait d'être hors connexion n'a pas beaucoup de sens. Il est probablement plus important de savoir quelles ressources ne se chargent pas. Cela est particulièrement important pour les applications monopages (SPA), où une perte de connexion réseau peut ne pas entraîner l'affichage d'une page d'erreur hors connexion du navigateur, que les utilisateurs comprennent. Au lieu de cela, il est probable que des parties dynamiques aléatoires de la page échouent silencieusement.

Vous pouvez toujours utiliser cette solution pour acquérir une compréhension de base de l'utilisation hors connexion, mais vous devez tenir compte des nombreux inconvénients et limites.

Une meilleure approche : le service worker

La solution qui permet le mode hors connexion est également une meilleure solution pour suivre l'utilisation hors connexion. Vous pouvez stocker les pings Analytics dans IndexedDB tant que l'utilisateur est hors connexion, puis les renvoyer lorsqu'il se reconnecte. Pour Google Analytics, cette fonctionnalité est déjà disponible dans un module Workbox. Toutefois, gardez à l'esprit que les hits envoyés avec un délai de plus de quatre heures peuvent ne pas être traités.

Dans sa forme la plus simple, il peut être activé dans un service worker basé sur Workbox avec ces deux lignes :

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

googleAnalytics.initialize();

Cela permet de suivre tous les événements et les pings de page vue existants lorsque l'utilisateur est hors connexion, mais vous ne savez pas qu'ils se sont produits hors connexion, car ils sont simplement rejoués tels quels. Vous pouvez manipuler les demandes de suivi avec Workbox en ajoutant un indicateur offline au ping Analytics, à l'aide d'une dimension personnalisée :

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

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

Que se passe-t-il si l'utilisateur quitte la page parce qu'il est hors connexion, avant que la connexion Internet ne soit rétablie ? Bien que cela mette normalement le service worker en veille, car il ne peut pas envoyer les données lorsque la connexion est rétablie, le module Workbox Google Analytics utilise l'API Background Sync. La synchronisation en arrière-plan envoie les données analytiques lorsque la connexion est rétablie, même si l'utilisateur ferme l'onglet ou le navigateur.

Il existe toutefois un inconvénient : bien que cela permette de suivre les données hors connexion existantes, vous ne verrez probablement pas beaucoup de données pertinentes arriver tant que vous n'aurez pas implémenté un mode hors connexion de base. Les utilisateurs quitteraient toujours votre site rapidement lorsque la connexion est interrompue. Vous pouvez désormais mesurer et quantifier cet aspect en comparant la durée moyenne des sessions et l'engagement des utilisateurs auxquels la dimension "Hors connexion" est appliquée à ceux de vos utilisateurs habituels.

SPA et chargement différé

Si les utilisateurs qui visitent une page conçue comme un site Web multipage se déconnectent et tentent de naviguer, la page hors connexion par défaut du navigateur s'affiche, ce qui leur permet de comprendre ce qui se passe. Toutefois, les pages conçues comme des applications monopages fonctionnent différemment. L'utilisateur reste sur la même page et le nouveau contenu est chargé de manière dynamique via AJAX, sans aucune navigation dans le navigateur. Les utilisateurs ne voient pas la page d'erreur du navigateur lorsqu'ils passent en mode hors connexion. Au lieu de cela, les parties dynamiques de la page s'affichent avec des erreurs, passent à des états indéfinis ou cessent simplement d'être dynamiques.

Des effets similaires peuvent se produire sur les sites Web multipages en raison du chargement différé. Par exemple, le chargement initial a peut-être eu lieu en ligne, mais l'utilisateur est passé hors connexion avant de faire défiler la page. Tout contenu à chargement différé sous la ligne de flottaison échouera silencieusement et sera manquant.

Ces cas étant très irritants pour les utilisateurs, il est judicieux de les suivre. Les service workers sont l'endroit idéal pour détecter les erreurs réseau et, à terme, les suivre à l'aide d'analyses. Avec Workbox, un gestionnaire d'erreur global peut être configuré pour informer la page des 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 façon de faire consiste à intercepter les erreurs sur des routes spécifiques uniquement. Par exemple, si nous voulons signaler les erreurs qui se produisent sur les routes 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 un itinéraire distinct, avec une meilleure maintenabilité dans 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();
    }
  }
);

Enfin, la page doit écouter l'événement message et envoyer le ping d'analyse. Encore une fois, veillez à mettre en mémoire tampon les demandes d'analyse qui se produisent hors connexion dans le service worker. Comme décrit précédemment, initialisez le plug-in workbox-google-analytics pour la compatibilité intégrée de Google Analytics.

L'exemple suivant utilise Google Analytics, mais peut être appliqué de la même manière à d'autres fournisseurs d'analyses.

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 permettra de suivre les échecs de chargement des ressources dans Google Analytics, où ils pourront être analysés à l'aide des rapports. L'insight dérivé 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 réseau instables.

Étapes suivantes

Vous avez découvert différentes façons de suivre l'utilisation hors connexion, ainsi que leurs avantages et leurs inconvénients. Cela peut vous aider à quantifier le nombre d'utilisateurs qui se déconnectent et rencontrent des problèmes à cause de cela, mais ce n'est qu'un début. Tant que votre site Web n'offre pas de mode hors connexion bien conçu, vous ne verrez évidemment pas beaucoup d'utilisation hors connexion dans les données analytiques.

Nous vous recommandons de mettre en place un suivi complet, puis d'étendre vos capacités hors connexion par itérations, en mettant l'accent sur le suivi. Commencez par une page d'erreur hors connexion. Il est très simple de créer une page 404 avec Workbox. Il s'agit d'une bonne pratique en termes d'UX, semblable à celle des pages 404 personnalisées. Ensuite, essayez de mettre en place des solutions de secours hors connexion plus avancées, puis des contenus hors connexion réels. Assurez-vous de faire de la publicité pour cette fonctionnalité et de l'expliquer clairement à vos utilisateurs. Vous constaterez alors une augmentation de son utilisation. Après tout, tout le monde se déconnecte de temps en temps.

Consultez Comment créer des rapports sur les métriques et développer une culture de la performance et Corriger la vitesse d'un site Web de manière transversale pour obtenir des conseils sur la façon de convaincre les parties prenantes interfonctionnelles d'investir davantage dans votre site Web. Bien que ces articles soient axés sur les performances, ils devraient vous aider à obtenir des idées générales sur la façon d'impliquer les parties prenantes.