Offlinenutzung analysieren

So erfassen Sie die Offline-Nutzung Ihrer Website, um zu belegen, warum Ihre Website eine bessere Offline-Nutzung benötigt.

Stephan Giesau

Martin Schierle

Hier erfahren Sie, wie Sie die Offline-Nutzung Ihrer Website erfassen können, um zu argumentieren, warum Ihre Website einen besseren Offlinemodus benötigt. Informationen zu Fallstricken und Problemen, die bei der Implementierung von Offline-Nutzungsanalysen vermieden werden sollten.

Die Tücken der Online- und Offline-Browserereignisse

Die naheliegende Lösung für das Tracking der Offlinenutzung besteht darin, Ereignis-Listener für die Ereignisse online und offline zu erstellen (die viele Browser unterstützen) und die Analysetracking-Logik in diese Listener einzufügen. Leider gibt es bei diesem Ansatz mehrere Probleme und Einschränkungen:

• Im Allgemeinen ist es möglicherweise übertrieben, jedes Ereignis zum Status der Netzwerkverbindung zu erfassen. Dies ist in einer datenschutzorientierten Welt, in der so wenige Daten wie möglich erhoben werden sollten, kontraproduktiv. Außerdem können die Ereignisse online und offline bei einem nur sehr kurzen Netzwerkausfall ausgelöst werden, den ein Nutzer wahrscheinlich nicht einmal bemerken würde.
• Das Analytics-Tracking von Offlineaktivitäten erreicht den Analytics-Server nicht.
• Wenn Sie einen Zeitstempel lokal erfassen, wenn ein Nutzer offline geht, und die Offlineaktivität an den Analytics-Server senden, wenn der Nutzer wieder online ist, hängt das davon ab, ob der Nutzer Ihre Website noch einmal besucht. Wenn ein Nutzer Ihre Website aufgrund des fehlenden Offlinemodus verlässt und nicht wieder aufruft, können Sie das nicht nachvollziehen. Die Möglichkeit, Offline-Abbrüche zu erfassen, ist entscheidend, um zu belegen, warum Ihre Website einen besseren Offline-Modus benötigt.
• Das online-Ereignis ist nicht sehr zuverlässig, da es nur über den Netzwerkzugriff informiert ist, nicht über den Internetzugriff. Ein Nutzer kann also weiterhin offline sein und das Senden des Tracking-Pings kann weiterhin fehlschlagen.
• Auch wenn der Nutzer offline auf der aktuellen Seite bleibt, werden keine anderen Analytics-Ereignisse (z. B. Scroll-Ereignisse, Klicks usw.) erfasst. Das sind aber möglicherweise die relevanteren und nützlicheren Informationen.
• Einfach nur offline zu sein, ist nicht sehr aussagekräftig. Am wichtigsten ist es wahrscheinlich, zu wissen, welche Ressourcen nicht geladen werden. Das ist besonders für Single-Page-Anwendungen (SPAs) relevant, bei denen eine unterbrochene Netzwerkverbindung möglicherweise nicht zu einer Browser-Offline-Fehlerseite führt, die Nutzer verstehen. Stattdessen führt es wahrscheinlich dazu, dass zufällige, dynamische Teile der Seite im Hintergrund fehlschlagen.

Sie können diese Lösung weiterhin verwenden, um ein grundlegendes Verständnis der Offline-Nutzung zu erhalten. Die vielen Nachteile und Einschränkungen müssen jedoch sorgfältig berücksichtigt werden.

Besserer Ansatz: der Service Worker

Die Lösung, die den Offlinemodus ermöglicht, ist auch besser geeignet, um die Offline-Nutzung zu erfassen. Sie können Analyse-Pings in IndexedDB speichern, solange der Nutzer offline ist, und sie noch einmal senden, wenn der Nutzer wieder online ist. Für Google Analytics ist dies bereits in einem Workbox-Modul verfügbar. Beachten Sie jedoch, dass Hits, die mehr als vier Stunden verzögert gesendet werden, möglicherweise nicht verarbeitet werden.

In der einfachsten Form kann sie in einem auf Workbox basierenden Service Worker mit diesen beiden Zeilen aktiviert werden:

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

googleAnalytics.initialize();

Damit werden alle vorhandenen Ereignisse und Seitenaufruf-Pings im Offlinemodus erfasst. Sie wissen jedoch nicht, dass sie offline stattgefunden haben, da sie unverändert wiedergegeben werden. Sie können Tracking-Anfragen mit Workbox bearbeiten, indem Sie dem Analytics-Ping mit einer benutzerdefinierten Dimension das Flag offline hinzufügen:

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

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

Was passiert, wenn der Nutzer die Seite verlässt, weil er offline ist, bevor die Internetverbindung wiederhergestellt wird? Normalerweise wird der Service Worker dadurch in den Ruhezustand versetzt, da er die Daten nicht senden kann, wenn die Verbindung wiederhergestellt wird. Das Workbox Google Analytics-Modul verwendet jedoch die Background Sync API. Bei der Hintergrundsynchronisierung werden die Analysedaten gesendet, wenn die Verbindung wiederhergestellt wird, auch wenn der Nutzer den Tab oder Browser schließt.

Es gibt jedoch einen Nachteil: Dadurch wird das vorhandene Tracking zwar offlinefähig, aber Sie werden wahrscheinlich erst dann viele relevante Daten erhalten, wenn Sie einen einfachen Offlinemodus implementieren. Nutzer würden Ihre Website weiterhin schnell verlassen, wenn die Verbindung unterbrochen wird. Sie können diese Daten jetzt aber zumindest messen und quantifizieren, indem Sie die durchschnittliche Sitzungslänge und die Nutzerinteraktionen für Nutzer mit der Offlinedimension mit denen Ihrer regulären Nutzer vergleichen.

SPAs und Lazy Loading

Wenn Nutzer, die eine Seite besuchen, die als mehrseitige Website erstellt wurde, offline gehen und versuchen, zu navigieren, wird die Standard-Offlineseite des Browsers angezeigt. So können Nutzer nachvollziehen, was passiert. Seiten, die als Single-Page-Anwendungen erstellt wurden, funktionieren jedoch anders. Der Nutzer bleibt auf derselben Seite und neue Inhalte werden dynamisch über AJAX geladen, ohne dass eine Browsernavigation erfolgt. Nutzer sehen beim Offlinegehen nicht die Fehlerseite des Browsers. Stattdessen werden die dynamischen Teile der Seite mit Fehlern gerendert, gehen in undefinierte Zustände über oder sind einfach nicht mehr dynamisch.

Ähnliche Effekte können bei mehrseitigen Websites durch Lazy Loading auftreten. Vielleicht wurde die Seite beispielsweise online geladen, aber der Nutzer hat erst gescrollt, nachdem er offline gegangen ist. Alle Inhalte, die unterhalb des Falzes lazy geladen werden, schlagen fehl und fehlen.

Da diese Fälle für Nutzer sehr ärgerlich sind, ist es sinnvoll, sie zu erfassen. Service Worker sind der perfekte Ort, um Netzwerkfehler abzufangen und sie schließlich mit Analysen zu verfolgen. Mit Workbox kann ein globaler Catch-Handler konfiguriert werden, um die Seite über fehlgeschlagene Anfragen zu informieren, indem ein Message-Ereignis gesendet wird:

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();

  }());
});

Anstatt auf alle fehlgeschlagenen Anfragen zu reagieren, können Sie auch nur Fehler bei bestimmten Routen abfangen. Wenn wir beispielsweise Fehler nur für Routen zu /products/* melden möchten, können wir in setCatchHandler eine Prüfung hinzufügen, die den URI mit einem regulären Ausdruck filtert.

Eine sauberere Lösung besteht darin, registerRoute mit einem benutzerdefinierten Handler zu implementieren. Dadurch wird die Geschäftslogik in einer separaten Route gekapselt, was die Wartung in komplexeren Service-Workern erleichtert:

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();
    }
  }
);

Im letzten Schritt muss die Seite auf das message-Ereignis warten und den Analyse-Ping senden. Achten Sie auch hier darauf, Analyseanfragen, die offline im Service Worker erfolgen, zu puffern. Wie bereits beschrieben, initialisieren Sie das workbox-google-analytics-Plug-in für die integrierte Google Analytics-Unterstützung.

Im folgenden Beispiel wird Google Analytics verwendet. Es kann aber auf dieselbe Weise auf andere Analyseanbieter angewendet werden.

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
      });
    }
  });
}

Dadurch werden fehlgeschlagene Ressourcenladevorgänge in Google Analytics erfasst, wo sie mit Berichten analysiert werden können. Die abgeleiteten Statistiken können verwendet werden, um das Service Worker-Caching und die Fehlerbehandlung im Allgemeinen zu verbessern und die Seite bei instabilen Netzwerkbedingungen robuster und zuverlässiger zu machen.

Nächste Schritte

Sie haben verschiedene Möglichkeiten kennengelernt, die Offline-Nutzung zu erfassen, sowie die jeweiligen Vor- und Nachteile. So lässt sich zwar quantifizieren, wie viele Ihrer Nutzer offline gehen und dadurch Probleme haben, aber das ist erst der Anfang. Solange Ihre Website keinen gut funktionierenden Offlinemodus bietet, werden Sie in Analytics natürlich nicht viele Offlinenutzungsdaten sehen.

Wir empfehlen, das vollständige Tracking einzurichten und dann Ihre Offline-Funktionen in Iterationen zu erweitern, wobei der Schwerpunkt auf dem Tracking liegen sollte. Beginnen Sie mit einer Offline-Fehlerseite. Das Erstellen mit Workbox ist ganz einfach und es handelt sich um eine Best Practice für die Nutzerfreundlichkeit, ähnlich wie bei benutzerdefinierten 404-Seiten. Arbeiten Sie dann auf erweiterte Offline-Fallbacks und schließlich auf echten Offline-Content hin. Wenn Sie diese Funktion gut bewerben und Ihren Nutzern erklären, wird sie auch häufiger verwendet. Schließlich ist jeder mal offline.

Im Artikel Messwerte präsentieren und eine Leistungskultur schaffen und Funktionsübergreifende Optimierung der Website-Geschwindigkeit finden Sie Tipps, wie Sie funktionsübergreifende Stakeholder davon überzeugen, mehr in Ihre Website zu investieren. Obwohl sich diese Beiträge auf die Leistung konzentrieren, sollten sie Ihnen helfen, allgemeine Ideen für die Interaktion mit Stakeholdern zu erhalten.