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 suivre l'utilisation hors connexion de votre site afin de vous aider à justifier pourquoi votre site a besoin d'un meilleur mode hors connexion. Il explique également les pièges et les problèmes à éviter lors de l'implémentation de l'analyse de l'utilisation hors connexion.

Écueils 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 (compatibles avec de nombreux navigateurs) 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 la 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 en une fraction de seconde en cas de perte de réseau, ce que l'utilisateur ne verrait probablement même pas.
• Le suivi analytique de l'activité hors connexion n'atteindrait jamais le serveur d'analyse, car l'utilisateur est… hors connexion.
• Le suivi d'un horodatage local lorsqu'un utilisateur se déconnecte et l'envoi de l'activité hors connexion au 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 en raison de l'absence de mode hors connexion et ne le consulte plus jamais, vous ne pouvez pas le suivre. 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 en cours lorsqu'il est hors connexion, aucun des autres événements d'analyse (par exemple, les événements de défilement, les clics, etc.) ne sont suivis, ce qui peut être les informations les plus pertinentes et utiles.
• L'état hors connexion en soi n'a pas non plus beaucoup de sens en général. En tant que développeur de site Web, il peut être plus important de savoir quels types de ressources n'ont pas été chargées. Cela est particulièrement pertinent dans le contexte des applications monopages, où une perte de connexion réseau n'entraîne pas nécessairement l'affichage d'une page d'erreur hors connexion du navigateur (ce que les utilisateurs comprennent), mais il est plus probable que des parties dynamiques de la page tombent de manière aléatoire en mode silencieux.

Vous pouvez toujours utiliser cette solution pour obtenir 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 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 fonctionnalité est déjà disponible prêt à l'emploi via un module Workbox. Toutefois, gardez à l'esprit que les appels envoyés plus de quatre heures après ne seront peut-être pas traités. Dans sa forme la plus simple, il peut être activé dans un worker de service basé sur Workbox avec ces deux lignes:

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

googleAnalytics.initialize();

Cette option permet de suivre tous les événements existants et les pings de page vue lorsque vous êtes hors connexion, mais vous ne saurez pas qu'ils se sont produits hors connexion (car ils sont simplement lus tels quels). Pour ce faire, vous pouvez 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 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 en raison d'une connexion Internet interrompue, avant que la connexion ne soit rétablie ? Même si cela met normalement le service worker en veille (car il ne peut pas envoyer les données lorsque la connexion est rétablie), le module Google Analytics Workbox utilise l'API Background Sync, 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 existe cependant un inconvénient: bien que le suivi existant soit compatible avec le mode hors connexion, 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 rapidement votre site en cas de rupture de la connexion. Mais vous pouvez au moins le mesurer et le quantifier en comparant la durée moyenne de la session et l'engagement des utilisateurs pour lesquels la dimension "hors connexion" est appliquée par rapport à vos utilisateurs réguliers.

SPA et chargement différé

Si les utilisateurs qui accèdent à une page conçue comme un site Web multipage passent en mode hors connexion et tentent de naviguer, la page hors connexion par défaut du navigateur s'affiche, ce qui les aide à comprendre ce qui se passe. Toutefois, les pages créées en tant qu'applications monopages fonctionnent différemment. L'utilisateur reste sur la même page, et le nouveau contenu est chargé dynamiquement via AJAX sans navigation dans le navigateur. La page d'erreur du navigateur ne s'affiche pas lorsque les utilisateurs sont hors connexion. Au lieu de cela, les parties dynamiques de la page s'affichent avec des erreurs, passent à un état non défini ou cessent d'être dynamiques.

Des effets similaires peuvent se produire sur les sites Web multipages en raison du chargement différé. Par exemple, il est possible que le chargement initial ait eu lieu en ligne, mais que l'utilisateur soit passé hors connexion avant le défilement. Tout le contenu chargé en différé en dessous de la ligne de flottaison échouera silencieusement et sera manquant.

Étant donné que ces cas sont très irritants pour les utilisateurs, il est logique de les suivre. Les services workers sont l'endroit idéal pour détecter les erreurs réseau et les suivre à l'aide d'analyses. Avec Workbox, vous pouvez configurer un gestionnaire d'interception globale 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 uniquement sur des routes spécifiques. Par exemple, si nous souhaitons signaler uniquement les erreurs qui se produisent sur les routes vers /products/*, nous pouvons ajouter une vérification dans setCatchHandler qui filtre l'URI à l'aide d'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 chemin distinct, avec une meilleure facilité de maintenance 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();
    }
  }
);

Pour finir, 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 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 avec Google Analytics.

L'exemple suivant utilise Google Analytics, mais peut être appliqué de la même manière pour d'autres fournisseurs d'outils 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 chargements de ressources ayant échoué 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 le cache du service worker 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

Cet article vous a présenté différentes façons de suivre l'utilisation hors connexion, avec leurs avantages et leurs inconvénients. Bien que cela puisse vous aider à quantifier le nombre d'utilisateurs qui se déconnectent et rencontrent des problèmes à cause de cela, ce n'est qu'un début. Tant que votre site Web ne propose pas un mode hors connexion bien conçu, l'utilisation hors connexion sera peu importante dans les analyses.

Nous vous recommandons de mettre en place le suivi complet, puis d'étendre vos fonctionnalités hors connexion par itérations en gardant un œil sur les numéros de suivi. Commencez par une page d'erreur hors connexion simple (Workbox vous permet de le faire facilement). Il s'agit d'une bonne pratique UX, comme pour les pages d'erreur 404 personnalisées. Passez ensuite aux solutions de remplacement hors connexion plus avancées, puis aux contenus hors connexion réels. Veillez à en faire la promotion et à bien l'expliquer à vos utilisateurs. Vous verrez alors l'utilisation augmenter. 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 axée sur les performances et Améliorer la vitesse du site Web de manière transversale pour obtenir des conseils sur la façon de persuader les personnes concernées de tous les services d'investir davantage dans votre site Web. Bien que ces posts soient axés sur les performances, ils devraient vous aider à obtenir des idées générales sur la façon d'engager les personnes concernées.

Photo d'illustration par JC Gellidon sur Unsplash.