Offlinenutzung analysieren

Wie Sie die Offlinenutzung Ihrer Website erfassen, um zu begründen, warum Ihre Website eine bessere Offline-Nutzung benötigt.

Stephan Giesau

Martin Schierle

Hier erfahren Sie, wie Sie die Offlinenutzung Ihrer Website erfassen, um zu begründen, warum Ihre Website einen besseren Offlinemodus benötigt. Sie erfahren, welche Fallstricke und Probleme Sie bei der Implementierung von Offline-Nutzungsanalysen vermeiden sollten.

Die Fallstricke der Online- und Offline-Browserereignisse

Die naheliegende Lösung für das Tracking der Offlinenutzung besteht darin, Event-Listener für die Ereignisse online und offline zu erstellen (die von vielen Browsern unterstützt werden) und die Tracking-Logik für die Analyse in diese Listener einzufügen. Leider gibt es bei diesem Ansatz mehrere Probleme und Einschränkungen:

• Im Allgemeinen ist es möglicherweise übertrieben, jedes Statusereignis einer Netzwerkverbindung zu erfassen. In einer datenschutzorientierten Welt, in der so wenig Daten wie möglich erhoben werden sollten, ist dies kontraproduktiv. Außerdem können die Ereignisse online und offline auch bei einem nur sekundenbruchteile langen 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 dies davon ab, ob der Nutzer Ihre Website noch einmal besucht. Wenn ein Nutzer Ihre Website verlässt, weil kein Offlinemodus vorhanden ist, und sie nie wieder besucht, können Sie das nicht nachverfolgen. Die Möglichkeit, Offline-Abbrüche zu verfolgen, liefert wichtige Daten, um zu begründen, warum Ihre Website einen besseren Offlinemodus benötigt.
• Das Ereignis online ist nicht sehr zuverlässig, da es nur den Netzwerkzugriff, nicht aber den Internetzugriff kennt. Daher ist ein Nutzer möglicherweise immer noch offline und das Senden des Tracking-Pings kann fehlschlagen.
• Auch wenn der Nutzer auf der aktuellen Seite bleibt, während er offline ist, werden keine anderen Analytics-Ereignisse (z.B. Scroll-Ereignisse, Klicks usw.) erfasst, die möglicherweise relevantere und nützlichere Informationen liefern.
• Nur offline zu sein, ist nicht sehr aussagekräftig. Am wichtigsten ist es wahrscheinlich, zu wissen, welche Ressourcen nicht geladen werden können. Dies ist besonders relevant für Single-Page-Anwendungen (SPAs), 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 unbemerkt fehlschlagen.

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

Ein besserer Ansatz: Der Service Worker

Die Lösung, die den Offlinemodus ermöglicht, ist auch eine bessere Lösung, um die Offlinenutzung zu verfolgen. Sie können Analytics-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 Treffer, die mehr als vier Stunden verzögert gesendet werden, möglicherweise nicht verarbeitet werden.

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

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

googleAnalytics.initialize();

So werden alle vorhandenen Ereignisse und Seitenaufruf-Pings erfasst, während Sie offline sind. Sie wissen jedoch nicht, dass sie offline aufgetreten sind, da sie einfach so wiedergegeben werden, wie sie sind. Sie können Tracking-Anfragen mit Workbox bearbeiten, indem Sie dem Analytics-Ping ein offline-Flag hinzufügen und eine benutzerdefinierte Dimension verwenden:

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 eine Internetverbindung wiederhergestellt wird? Normalerweise wird der Service Worker dadurch in den Ruhemodus versetzt, da er die Daten nicht senden kann, wenn die Verbindung wiederhergestellt wird. Das Workbox Google Analytics-Modul verwendet jedoch die Background Sync API. Die Hintergrundsynchronisierung sendet die Analysedaten, sobald die Verbindung wiederhergestellt ist, auch wenn der Nutzer den Tab oder Browser schließt.

Es gibt jedoch einen Nachteil: Das vorhandene Tracking wird zwar offlinefähig, aber Sie werden wahrscheinlich erst dann relevante Daten sehen, wenn Sie einen grundlegenden Offlinemodus implementieren. Nutzer würden Ihre Website immer noch schnell verlassen, wenn die Verbindung abbricht. Aber jetzt kannst du das zumindest messen und quantifizieren, indem du die durchschnittliche Sitzungsdauer und die Nutzerinteraktion für Nutzer mit der Offline-Dimension mit denen deiner regulären Nutzer vergleichst.

SPAs und Lazy Loading

Wenn Nutzer, die eine als mehrseitige Website erstellte Seite besuchen, offline gehen und versuchen, zu navigieren, wird die Standard-Offlineseite des Browsers angezeigt, damit Nutzer verstehen, 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 der Browser navigiert. Nutzer sehen die Browser-Fehlerseite nicht, wenn sie offline gehen. 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 auf Websites mit mehreren Seiten aufgrund von Lazy Loading auftreten. Beispielsweise wurde die Seite möglicherweise online geladen, aber der Nutzer ist offline gegangen, bevor er gescrollt hat. Alle verzögert geladenen Inhalte unterhalb der Seitenmitte schlagen im Hintergrund fehl und fehlen.

Da diese Fälle für Nutzer sehr irritierend sind, ist es sinnvoll, sie zu erfassen. Service Worker sind der perfekte Ort, um Netzwerkfehler zu erfassen und sie schließlich mithilfe von Analysen zu verfolgen. Mit Workbox kann ein globaler Catch-Handler konfiguriert werden, um die Seite über fehlgeschlagene Anfragen zu informieren, indem ein Nachrichtenereignis 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 alle fehlgeschlagenen Anfragen zu überwachen, können Sie auch nur Fehler auf bestimmten Routen abfangen. Wenn wir beispielsweise nur Fehler melden möchten, die auf Routen zu /products/* auftreten, können wir in setCatchHandler eine Prüfung hinzufügen, die den URI mit einem regulären Ausdruck filtert.

Eine sauberere Lösung ist die Implementierung von registerRoute mit einem benutzerdefinierten Handler. Dadurch wird die Geschäftslogik in einer separaten Route gekapselt, was die Wartbarkeit in komplexeren Service Workern verbessert:

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. Auch hier gilt: Analytische Anfragen, die offline erfolgen, müssen im Service Worker zwischengespeichert werden. Initialisieren Sie wie zuvor beschrieben das workbox-google-analytics-Plug-in für die integrierte Google Analytics-Unterstützung.

Im folgenden Beispiel wird Google Analytics verwendet. Die Vorgehensweise ist aber bei anderen Analyseanbietern ähnlich.

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 gewonnenen Erkenntnisse können verwendet werden, um das Caching und die Fehlerbehandlung von Service Workern im Allgemeinen zu verbessern und die Seite bei instabilen Netzwerkbedingungen robuster und zuverlässiger zu machen.

Nächste Schritte

Sie haben verschiedene Möglichkeiten zum Erfassen der Offlinenutzung mit ihren Vor- und Nachteilen kennengelernt. So lässt sich zwar quantifizieren, wie viele Nutzer offline gehen und dadurch Probleme haben, aber das ist nur ein Anfang. Solange Ihre Website keinen gut aufgebauten Offlinemodus bietet, werden Sie in Analytics natürlich nicht viel Offlinenutzung sehen.

Wir empfehlen, das vollständige Tracking einzurichten und dann die Offlinefunktionen schrittweise zu erweitern, wobei der Schwerpunkt auf dem Tracking liegt. Beginnen Sie mit einer Offline-Fehlerseite. Das lässt sich mit Workbox ganz einfach erstellen und ist eine Best Practice für die UX, ähnlich wie benutzerdefinierte 404-Seiten. Arbeiten Sie dann auf erweiterte Offline-Fallbacks und schließlich auf echte Offline-Inhalte hin. Wenn Sie diese Funktion gut bewerben und Ihren Nutzern erklären, werden Sie feststellen, dass sie immer häufiger verwendet wird. Schließlich ist jeder mal offline.

In den Artikeln How to report metrics and build a performance culture und Fixing website speed cross-functionally finden Sie Tipps, wie Sie funktionsübergreifende Stakeholder davon überzeugen können, mehr in Ihre Website zu investieren. Diese Beiträge konzentrieren sich zwar auf die Leistung, sollten Ihnen aber allgemeine Ideen dazu liefern, wie Sie Stakeholder einbinden können.