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.
Cet article vous explique comment suivre l'utilisation hors connexion de votre site afin de déterminer pourquoi votre site a besoin d'un mode hors connexion plus efficace. Il explique également les pièges et les problèmes à éviter lors de l'implémentation de l'analyse de l'utilisation hors connexion.
Les pièges liés aux é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 analyses dans ces écouteurs. Malheureusement, cette approche présente plusieurs problèmes et limites:
- 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 doit être collecté. De plus, les événements
onlineetofflinepeuvent se déclencher pour une fraction de seconde de perte de réseau, ce qu'un utilisateur ne verra probablement pas ou ne remarquera même pas. - Le suivi d'analyse de l'activité hors connexion n'atteindrait jamais le serveur d'analyse parce que l'utilisateur est... hors ligne.
- 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 parce qu'il n'a pas de mode hors connexion et ne le visite jamais, vous n'avez aucun moyen de le suivre. La possibilité de suivre les abandons hors connexion est une donnée essentielle pour déterminer pourquoi votre site a besoin d'un mode hors connexion plus efficace.
- L'événement
onlinen'est pas très fiable, car il ne connaît que l'accès au réseau, pas 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 des autres événements d'analyse (par exemple, les événements de défilement, les clics, etc.) n'est suivi non plus, ce qui pourrait être les informations les plus pertinentes et les plus 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 être plus important de savoir quels types de ressources n'ont pas pu se charger. 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 acquérir des connaissances de base sur l'utilisation hors connexion, mais vous devez étudier attentivement les 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 lorsqu'il se reconnecte. Pour Google Analytics, cette fonctionnalité est déjà disponible prête à l'emploi via un module Workbox, mais n'oubliez pas 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, elle peut être activée dans un service worker basé sur Workbox à l'aide des 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 s'ils se sont produits hors connexion (car ils sont simplement relancés tels quels). Pour cela, 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 parce qu'il est hors connexion, avant qu'une connexion Internet 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 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 existe un inconvénient: même si le suivi existant est disponible hors connexion, vous ne verrez probablement que peu de données pertinentes provenant tant que vous n'implémenterez pas un mode hors connexion de base. Les utilisateurs peuvent tout de même quitter rapidement votre site une fois la connexion interrompue. Toutefois, vous pouvez maintenant au moins mesurer et quantifier cela, en comparant la durée moyenne de session et l'engagement utilisateur des utilisateurs en appliquant la dimension hors connexion à ceux de vos utilisateurs standards.
SPA et chargement différé
Si les utilisateurs qui consultent une page créée en tant que site Web de 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. 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. 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 simplement d'être dynamiques.
Le chargement différé peut avoir des effets similaires sur les sites Web composés de plusieurs pages. Par exemple, il se peut que le chargement initial s'est produit en ligne, mais que l'utilisateur s'est déconnecté avant de faire défiler la page. Tout le contenu chargé en différé en dessous de la ligne de flottaison échouera silencieusement et sera manquant.
Comme ces situations sont très agaçantes pour les utilisateurs, il est judicieux de les suivre. Les service workers sont le point 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é, une autre méthode consiste à ne détecter les erreurs que sur des routes spécifiques. Par exemple, si vous souhaitez 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. 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 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ù vous pouvez les analyser à 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
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 d'utilisateurs qui passent hors connexion et qui rencontrent des problèmes en raison de celui-ci, ce n'est qu'un début. Tant que votre site Web n'offre pas un mode hors connexion bien conçu, l'utilisation hors connexion ne sera probablement pas significative dans les analyses.
Nous vous recommandons de mettre en place un suivi complet, puis d'étendre vos fonctionnalités hors connexion par itérations en tenant compte des numéros de suivi. Commencez par une simple page d'erreur hors connexion, avec Workbox, c'est simple à faire. Cela doit être considéré comme une bonne pratique d'expérience utilisateur semblable aux pages 404 personnalisées. Ensuite, passez à des solutions hors connexion plus avancées et enfin à du contenu hors connexion réel. Assurez-vous de bien en faire la publicité et de bien l'expliquer à vos utilisateurs. Vous constaterez alors une augmentation de l'utilisation. Après tout, tout le monde se déconnecte de temps en temps.
Consultez Comment générer des rapports sur les métriques et développer une culture de la performance et Améliorer la vitesse du site Web de manière pluridisciplinaire pour obtenir des conseils sur la façon 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 manière d'impliquer les personnes concernées.
Photo principale de JC Gellidon sur Unsplash.