Diese Seite wurde von der Cloud Translation API übersetzt.

Offlinenutzung messen

Erfassen der Offline-Nutzung Ihrer Website, damit Sie begründen können, warum Ihre Website eine bessere Offline-Nutzung erfordert

Stephan Giesau

Martin Schierle

In diesem Artikel erfahren Sie, wie Sie die Offlinenutzung Ihrer Website erfassen, um zu begründen, warum Ihre Website einen besseren Offlinemodus benötigt. Außerdem werden Fallstricke und Probleme erläutert, die Sie bei der Implementierung von Analysen zur Offlinenutzung vermeiden sollten.

Die Fallstricke 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 Analyse-Tracking-Logik in diese Listener einzubinden. Leider gibt es bei diesem Ansatz mehrere Probleme und Einschränkungen:

Im Allgemeinen kann es zu übermäßig sein, jedes Ereignis zum Status der Netzwerkverbindung nachzuverfolgen. In einer datenschutzorientierten Welt, in der so wenig Daten wie möglich erhoben werden sollten, ist es kontraproduktiv. Außerdem können die Ereignisse online und offline nur für einen Bruchteil einer Sekunde Netzwerkverlust ausgelöst werden, den Nutzer wahrscheinlich nicht einmal sehen oder bemerken würden.
Das Analytics-Tracking von Offlineaktivitäten würde den Analyseserver nie erreichen, da der Nutzer ... eben offline ist.
Damit ein Zeitstempel lokal erfasst wird, wenn ein Nutzer offline geht und die Offlineaktivität an den Analyseserver gesendet wird, wenn der Nutzer wieder online geht, muss der Nutzer Ihre Website noch einmal besuchen. Wenn ein Nutzer Ihre Website aufgrund eines fehlenden Offlinemodus verlässt und sie nie wieder besucht, haben Sie keine Möglichkeit, dies nachzuverfolgen. Die Möglichkeit, Offline-Abbrüche zu erfassen, ist ein entscheidender Faktor, wenn Sie darüber sprechen möchten, warum Ihre Website einen besseren Offlinemodus benötigt.
Das online-Ereignis ist nicht sehr zuverlässig, da es nur den Netzwerkzugriff kennt, nicht den Internetzugriff. Daher ist es möglich, dass ein Nutzer immer noch offline ist und das Senden des Tracking-Pings trotzdem fehlschlagen kann.
Auch wenn der Nutzer offline auf der aktuellen Seite bleibt, wird auch keines der anderen Analytics-Ereignisse (z. B. Scroll-Ereignisse, Klicks) erfasst, da diese die relevantere und nützlichere Information darstellen könnten.
Offline zu sein, ist im Allgemeinen auch nicht allzu bedeutsam. Für Website-Entwickler ist es möglicherweise wichtiger zu wissen, welche Arten von Ressourcen nicht geladen werden konnten. Dies ist insbesondere im Kontext von SPAs relevant, bei denen eine unterbrochene Netzwerkverbindung möglicherweise nicht zu einer Offlinefehlerseite des Browsers führt (was die Nutzer verstehen), sondern eher dazu, dass zufällige dynamische Teile der Seite ohne Meldung ausfallen.

Sie können diese Lösung trotzdem verwenden, um ein grundlegendes Verständnis der Offlinenutzung zu erlangen, aber die vielen Nachteile und Einschränkungen müssen sorgfältig abgewogen werden.

Ein besserer Ansatz: der Service Worker

Die Lösung, mit der der Offlinemodus aktiviert wird, erweist sich als bessere Lösung zum Erfassen der Offlinenutzung. Die Grundidee besteht darin, Analyse-Pings in IndexedDB zu speichern, solange der Nutzer offline ist, und sie nur noch einmal zu senden, wenn der Nutzer wieder online ist. Für Google Analytics ist dies bereits standardmäßig über ein Workbox-Modul verfügbar. Beachten Sie jedoch, dass Treffer, die mehr als vier Stunden verzögert gesendet wurden, möglicherweise nicht verarbeitet werden. In der einfachsten Form kann es in einem Workbox-basierten Service-Worker mit diesen zwei Zeilen aktiviert werden:

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

googleAnalytics.initialize();

Damit werden alle vorhandenen Ereignisse und Seitenaufruf-Pings erfasst, während Sie offline sind. Sie werden jedoch nicht wissen, dass sie offline stattgefunden haben, da sie einfach unverändert wiedergegeben werden. Dazu können Sie Tracking-Anfragen mit Workbox bearbeiten, indem Sie dem Analyse-Ping mithilfe einer benutzerdefinierten Dimension (cd1 im Codebeispiel unten) das Flag offline hinzufügen:

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

googleAnalytics.initialize({
  parameterOverrides: {
    cd1: '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 Ruhemodus versetzt (da er die Daten nicht senden kann, wenn die Verbindung wiederhergestellt ist), das Workbox Google Analytics-Modul verwendet jedoch die Background Sync API, die die Analysedaten später sendet, wenn die Verbindung wiederhergestellt wird, auch wenn der Nutzer den Tab oder den Browser schließt.

Es gibt jedoch noch einen Nachteil: Dadurch wird zwar das vorhandene Tracking offline-fähig, jedoch erhalten Sie wahrscheinlich erst dann viele relevante Daten, wenn Sie einen einfachen Offline-Modus implementieren. Nutzer würden Ihre Website dennoch schnell verlassen, auch wenn die Verbindung unterbrochen wird. Jetzt können Sie dies zumindest messen und quantifizieren, indem Sie die durchschnittliche Sitzungsdauer und das Nutzer-Engagement für Nutzer mit der angewendeten Offline-Dimension mit Ihrer regulären Nutzer vergleichen.

SPAs und Lazy Loading

Wenn Nutzer, die eine Seite besuchen, die aus einer mehrseitigen Website erstellt wurde, offline gehen und versuchen, zu navigieren, wird die standardmäßige Offlineseite des Browsers angezeigt. So können Nutzer nachvollziehen, was passiert. Seiten, die als Single-Page-Anwendungen erstellt werden, funktionieren jedoch anders. Der Nutzer bleibt auf derselben Seite und neue Inhalte werden dynamisch über AJAX ohne Browsernavigation geladen. Nutzern wird die Browserfehlerseite nicht angezeigt, wenn sie offline gehen. Stattdessen werden die dynamischen Teile der Seite mit Fehlern gerendert, wechseln in einen nicht definierten Status oder sind einfach nicht mehr dynamisch.

Durch das Lazy Loading können ähnliche Effekte bei mehrseitigen Websites auftreten. Vielleicht fand der anfängliche Ladevorgang online statt, aber der Nutzer war vor dem Scrollen offline. Lazy Loading-Inhalte „below the fold“ (mit Scrollen sichtbar) schlagen fehl und werden nicht mehr angezeigt.

Da solche Fälle die Nutzer wirklich reizen, ist es sinnvoll, sie zu verfolgen. Service Worker sind der perfekte Ort, um Netzwerkfehler zu erkennen und mithilfe von Analysen zu verfolgen. Mit Workbox kann ein globaler Catch-Handler konfiguriert werden, um die Seite durch Senden eines Nachrichtenereignisses über fehlgeschlagene Anfragen zu informieren:

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

  }());
});

Eine andere Möglichkeit besteht darin, Fehler nur für bestimmte Routen zu erfassen, anstatt alle fehlgeschlagenen Anfragen zu überwachen. Wenn beispielsweise Fehler gemeldet werden sollen, die nur für Routen zu /products/* auftreten, können wir eine Prüfung in setCatchHandler 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 eine separate Route gekapselt, was die Verwaltbarkeit 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();
    }
  }
);

Als letzten Schritt muss die Seite auf das message-Ereignis warten und den Analyse-Ping senden. Achten Sie auch hier darauf, Analyseanfragen zu puffern, die offline innerhalb des Service Workers eingehen. Initialisieren Sie wie oben beschrieben das workbox-google-analytics-Plug-in für die integrierte Google Analytics-Unterstützung.

Im folgenden Beispiel wird Google Analytics verwendet, kann aber auch 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 mithilfe von Berichten analysiert werden können. Die abgeleitete Statistik kann verwendet werden, um das Service-Worker-Caching und die Fehlerbehandlung im Allgemeinen zu verbessern, um die Seite unter instabilen Netzwerkbedingungen robuster und zuverlässiger zu machen.

Weitere Informationen

In diesem Artikel werden verschiedene Möglichkeiten aufgezeigt, wie Sie die Offlinenutzung mit ihren Vor- und Nachteilen erfassen können. Sie können damit zwar quantifizieren, wie viele Ihrer Nutzer offline gehen und dadurch Probleme auftreten, dies ist jedoch nur ein Anfang. Wenn Ihre Website keinen gut durchdachten Offlinemodus unterstützt, sehen Sie in Analytics natürlich nicht viel Offlinenutzung.

Wir empfehlen, das vollständige Tracking einzurichten und dann Ihre Offlinefunktionen iterativ zu erweitern, um Trackingnummern im Blick zu behalten. Beginnen Sie mit einer einfachen Offline-Fehlerseite. Workbox ist einfach zu tun. Dies sollte sowieso eine Best Practice für die UX sein, die benutzerdefinierten 404-Seiten ähnelt. Anschließend arbeiten Sie sich zu erweiterten Offline-Fallbacks und schließlich zu echten Offlineinhalten vor. Wenn Sie dies Ihren Nutzern gut erklären, machen Sie Werbung und machen Sie es deutlich. Sie werden einen Anstieg der Nutzung verzeichnen. Schließlich sind alle Nutzer hin und wieder offline.

Unter Berichte zu Messwerten erstellen und eine Leistungskultur schaffen und Funktionsübergreifende Probleme mit der Websitegeschwindigkeit beheben finden Sie Tipps, wie Sie funktionsübergreifende Stakeholder davon überzeugen können, mehr in Ihre Website zu investieren. Auch wenn sich diese Beiträge auf die Leistung konzentrieren, sollten Sie allgemeine Vorstellungen davon erhalten, wie Sie Stakeholder einbeziehen können.

Hero-Foto von JC Gellidon auf Unsplash