Mesurer l'utilisation hors connexion

Comment effectuer le suivi de l'utilisation hors connexion de votre site afin de comprendre pourquoi celui-ci nécessite une meilleure expérience hors connexion

Stephan Giesau

Martin Schierle

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

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

La solution la plus évidente pour suivre l'utilisation hors connexion consiste à créer des écouteurs d'événements pour les événements online et offline (compatibles avec de nombreux navigateurs) et à placer votre logique de suivi d'analyse 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 la connexion réseau peut s'avérer excessif et s'avère 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 pendant une fraction de seconde de perte de réseau, ce qu'un utilisateur ne verra probablement pas ni ne remarquera probablement.
• Le suivi de l'activité hors connexion n'atteindra jamais le serveur d'analyse, car l'utilisateur est... eh bien, hors connexion.
• Le suivi d'un horodatage en local lorsqu'un utilisateur se déconnecte et l'envoi de l'activité hors connexion au serveur d'analyse lorsqu'il se reconnecte dépend du fait que l'utilisateur visite à nouveau votre site. Si l'utilisateur quitte votre site en raison de l'absence d'un mode hors connexion et ne revient jamais, vous n'avez aucun moyen de suivre cela. La possibilité de suivre les abandons hors connexion est une donnée essentielle pour comprendre 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 échouer.
• Même si l'utilisateur reste sur la page actuelle alors qu'il est hors connexion, aucun des autres événements d'analyse (par exemple, les événements de défilement, les clics, etc.) ne fait l'objet d'un suivi, ce qui peut constituer l'information la plus pertinente et utile.
• De façon générale, le fait d'être hors connexion n'a pas non plus de sens. En tant que développeur de sites Web, il peut être plus important de savoir quels types de ressources ne se chargent pas. Cela est particulièrement pertinent dans le contexte des applications monopages, 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), mais plus susceptible d'entraîner l'échec silencieux des parties dynamiques aléatoires de la page.

Vous pouvez toujours utiliser cette solution pour acquérir des connaissances de base sur l'utilisation hors connexion, mais les nombreux inconvénients et limites doivent être examinés avec soin.

Une meilleure approche: le service worker

La solution qui active le mode hors connexion s'avère être la meilleure solution pour suivre l'utilisation hors connexion. L'idée de base est de stocker les pings d'analyse dans IndexedDB tant que l'utilisateur est hors connexion, et de les renvoyer simplement lorsqu'il se reconnecte. Pour Google Analytics, cette option est déjà disponible prête à l'emploi via un module Workbox, mais gardez à l'esprit que les appels envoyés plus de quatre heures différées risquent de ne pas être traités. Dans sa forme la plus simple, il peut être activé dans un service worker basé sur Workbox avec les deux lignes suivantes:

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

googleAnalytics.initialize();

Cela permet de suivre tous les événements existants et les pings de page vue hors connexion, mais vous ne pouvez pas savoir qu'ils se sont produits hors connexion (car ils sont simplement relus tels quels). Pour ce faire, vous pouvez manipuler les requêtes de suivi avec Workbox en ajoutant un indicateur offline au ping d'analyse, en utilisant une dimension personnalisée (cd1 dans l'exemple de code 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 n'est pas connecté, avant qu'une connexion Internet ne soit rétablie ? Même si cela met normalement le service worker en veille (car il est incapable d'envoyer les données lorsque la connexion est rétablie), le module Google Analytics Workbox utilise l'API de synchronisation en arrière-plan, qui envoie les données d'analyse ultérieurement lorsque la connexion est rétablie, même si l'utilisateur ferme l'onglet ou le navigateur.

Il y a toutefois un inconvénient: bien que le suivi existant puisse être effectué hors connexion, vous ne recevrez probablement pas beaucoup de données pertinentes tant que vous n'aurez pas implémenté un mode hors connexion de base. Les utilisateurs risquent tout de même de quitter rapidement votre site si la connexion s'interrompt. Toutefois, vous pouvez tout de même mesurer et quantifier cela en comparant la durée moyenne de la session et l'engagement utilisateur avec la dimension hors connexion appliquée à vos utilisateurs standards.

Applications Web monopages et chargement différé

Si les utilisateurs qui consultent une page créée sous la forme d'un site Web comportant plusieurs pages se déconnectent et tentent de naviguer, la page hors connexion par défaut du navigateur s'affiche, ce qui les aide à comprendre ce qui se passe. Cependant, les pages conçues en tant qu'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 en mode hors connexion. Au lieu de cela, les parties dynamiques de la page s'affichent avec des erreurs, passent à des états non définis ou cessent simplement d'être dynamiques.

Des effets similaires peuvent se produire sur les sites Web comportant plusieurs pages en raison du chargement différé. Par exemple, il se peut que le chargement initial ait eu lieu en ligne, mais que l'utilisateur s'est déconnecté avant de faire défiler la page. Tout le contenu à chargement différé en dessous de la ligne de flottaison échouera en mode silencieux et sera manquant.

Comme ces cas sont vraiment agaçants pour les utilisateurs, il est logique 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, vous pouvez configurer un gestionnaire d'interceptions globales 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é, vous pouvez également détecter 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 claire consiste à implémenter RegisterRoute avec un gestionnaire personnalisé. Cela encapsule la logique métier dans une route distincte, avec 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 terminer, la page doit écouter l'événement message et envoyer le ping d'analyse. Encore une fois, veillez à mettre en mémoire tampon les requêtes d'analyse qui ont lieu hors connexion au sein du service worker. Comme décrit précédemment, initialisez le plug-in workbox-google-analytics pour profiter de la compatibilité intégrée de Google Analytics.

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

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ù ils peuvent être analysés à l'aide de rapports. Les insights dérivés peuvent être utilisés 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 plus fiable dans des conditions réseau instables.

Étapes suivantes

Cet article présentait différentes méthodes pour suivre l'utilisation hors connexion, ainsi que ses avantages et ses inconvénients. Bien que cela puisse vous aider à quantifier le nombre d'utilisateurs qui se déconnectent et rencontrent des problèmes, ce n'est qu'un début. Tant que votre site Web n'offre pas un mode hors connexion bien conçu, vous ne verrez évidemment pas beaucoup d'utilisation hors connexion dans les analyses.

Nous vous recommandons de mettre en place le suivi complet, puis d'étendre vos capacités hors connexion dans les itérations en tenant compte des chiffres de suivi. Commencez par une simple page d'erreur hors connexion (avec la mention Workbox, c'est facile à faire). Elle doit être considérée comme une bonne pratique en matière d'expérience utilisateur, semblable aux pages 404 personnalisées. Vous pourrez ensuite utiliser des solutions de remplacement hors connexion plus avancées, puis accéder à du contenu hors connexion réel. Assurez-vous de bien en faire la publicité et de l'expliquer à vos utilisateurs. L'utilisation de cette fonctionnalité se développera de plus en plus. Après tout, tout le monde se déconnecte de temps en temps.

Consultez les sections Créer des rapports sur les métriques et créer une culture de la performance et Améliorer la vitesse du site Web de manière transversale pour obtenir des conseils sur la manière de persuader les personnes concernées d'investir davantage dans votre site Web. Bien que ces publications soient axées sur les performances, elles devraient vous aider à obtenir des idées générales sur la façon d'impliquer les partenaires.

Photo principale de JC Gellidon sur Unsplash.