Mesurer l'utilisation hors connexion

Comment suivre l'utilisation hors connexion de votre site afin de pouvoir expliquer pourquoi votre site a besoin d'une meilleure expérience hors connexion.

Stephan Giesau

Martin Schierle

Découvrez comment suivre l'utilisation hors connexion de votre site afin de pouvoir expliquer pourquoi votre site a besoin d'un meilleur mode hors connexion. Comprendre 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 (compatibles avec de nombreux navigateurs) et à placer votre logique de suivi analytique 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 en cas de perte de réseau pendant une fraction de seconde, ce que l'utilisateur ne verra ou ne remarquera probablement même pas.
• Le suivi analytique de l'activité hors connexion n'atteint pas le serveur d'analyse.
• Le suivi d'un code temporel localement lorsqu'un utilisateur passe hors connexion et l'envoi de l'activité hors connexion au serveur d'analyse lorsque l'utilisateur se reconnecte dépendent du fait que l'utilisateur revienne 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 expliquer 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 alors qu'il est hors connexion, aucun des autres événements d'analyse (par exemple, les événements de défilement, les clics, etc.) n'est suivi, ce qui peut être l'information la plus pertinente et la plus utile.
• Le simple fait d'être hors connexion n'est pas très significatif. Il est probablement plus important de savoir quelles ressources ne se chargent pas. Cela est particulièrement pertinent pour les applications monopages (SPA), où une connexion réseau interrompue peut ne pas entraîner l'affichage d'une page d'erreur de navigateur hors connexion, que les utilisateurs comprennent. Au lieu de cela, il est probable que des parties dynamiques aléatoires de la page échouent de manière silencieuse.

Vous pouvez toujours utiliser cette solution pour comprendre les principes 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 est également une meilleure solution pour suivre l'utilisation hors connexion. Vous pouvez stocker les pings d'analyse 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, mais n'oubliez pas que les appels envoyés avec un délai de plus de quatre heures 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 ces deux lignes :

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

googleAnalytics.initialize();

Cela permet de suivre tous les événements et pings de pages vues existants lorsque vous êtes hors connexion, mais vous ne saurez pas qu'ils se sont produits hors connexion, car ils sont simplement rejoués tels quels. Vous pouvez manipuler les requêtes 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 d'analyse lorsque la connexion est rétablie, même si l'utilisateur ferme l'onglet ou le navigateur.

Il existe toujours un inconvénient : bien que cela rende le suivi existant 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 lorsque la connexion est interrompue. Mais vous pouvez désormais au moins mesurer et quantifier cela en comparant la durée moyenne des sessions et l'engagement utilisateur pour les utilisateurs avec la dimension hors connexion appliquée par rapport à vos utilisateurs standards.

Applications monopages 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 les aide à 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 hors connexion. À la place, 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 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 le contenu chargé de manière différée sous la ligne de flottaison échouera silencieusement et sera manquant.

Comme ces cas sont vraiment irritants 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 les suivre à l'aide d'outils d'analyse. Avec Workbox, un gestionnaire d'interception 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é, vous pouvez également intercepter les erreurs sur des routes spécifiques uniquement. Par exemple, si nous voulons signaler uniquement les erreurs qui se produisent sur les routes vers /products/*, 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, 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();
    }
  }
);

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 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 de Google Analytics.

L'exemple suivant utilise Google Analytics, mais peut être appliqué de la même manière pour d'autres fournisseurs 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 permettra de suivre les échecs de chargement des ressources dans Google Analytics, où ils pourront ê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 de réseau instables.

Étapes suivantes

Vous avez découvert différentes façons de suivre l'utilisation hors connexion, avec leurs avantages et leurs inconvénients. Cela peut vous aider à quantifier le nombre d'utilisateurs qui se déconnectent et rencontrent des problèmes, mais ce n'est qu'un début. Tant que votre site Web ne propose 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 fonctionnalités hors connexion de manière itérative, en mettant l'accent sur le suivi. Commencez par une page d'erreur hors connexion. Il est très facile de créer cette page avec Workbox. Il s'agit d'une bonne pratique d'expérience utilisateur, semblable aux pages 404 personnalisées. Ensuite, passez à des solutions de remplacement hors connexion plus avancées, puis à du contenu réellement hors connexion. Veillez à promouvoir et à expliquer clairement cette fonctionnalité à vos utilisateurs, et vous constaterez une augmentation de l'utilisation. Après tout, tout le monde se déconnecte de temps en temps.

Consultez How to report metrics and build a performance culture (Comment créer des rapports sur les métriques et développer une culture de la performance) et Fixing website speed cross-functionally (Corriger la vitesse du site Web de manière interfonctionnelle) 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 donner des idées générales sur la manière d'impliquer les parties prenantes.