Diese Seite wurde von der Cloud Translation API übersetzt.

Offlinenutzung messen

Hier erfahren Sie, wie Sie die Offlinenutzung Ihrer Website erfassen, um zu begründen, warum Ihre Website offline verbessert werden sollte.

Stephan Giesau

Martin Schierle

In diesem Artikel erfahren Sie, wie Sie die Offlinenutzung Ihrer Website erfassen, um die Gründe für Ihre wenn die Website einen besseren Offlinemodus benötigt. Es werden auch Fallstricke und Probleme erläutert, die bei der Implementierung zu vermeiden sind. Analyse der Offlinenutzung.

Die Fallstricke von Online- und Offline-Browserereignissen

Die naheliegendste Lösung für das Tracking der Offline-Nutzung besteht darin, Ereignis-Listener für den online und offline-Ereignisse, die Unterstützung von vielen Browsern) und Ihr Analytics-Tracking Logik in diesen Listenern. Leider gibt es hier einige Probleme und Einschränkungen Ansatz:

Generell kann die Verfolgung jedes Statusereignisses der Netzwerkverbindung übermäßig sein. in einer datenschutzorientierten Welt, in der so wenig Daten wie möglich verfügbar sein sollten, gesammelt. Außerdem können die Ereignisse online und offline für den Bruchteil einer Sekunde den ein Nutzer wahrscheinlich gar nicht bemerken würde.
Das Analyse-Tracking der Offline-Aktivität würde den Analyseserver nie erreichen, weil und der Nutzer ist offline.
Lokal einen Zeitstempel erfassen, wenn ein Nutzer offline geht, und die Offlineaktivität senden an wenn der Nutzer wieder online geht, hängt davon ab, ob er Ihre Website erneut besucht. Wenn der Nutzer die Website verlässt, weil kein Offlinemodus vorhanden ist, und die Website nie wieder besucht, haben Sie keine Möglichkeit, das nachzuverfolgen. Die Möglichkeit, Offlineabbrüche zu erfassen, ist entscheidend für den Aufbau einer warum Ihre Website einen besseren Offlinemodus benötigt.
Das online-Ereignis ist nicht sehr zuverlässig, da es nur den Netzwerkzugriff kennt, und nicht auf das Internet. Daher ist ein Nutzer möglicherweise immer noch offline und das Senden des Tracking-Pings kann dazu führen, schlagen immer noch fehl.
Selbst wenn der Nutzer weiterhin auf der aktuellen Seite bleibt, während er offline ist, kann keiner der anderen werden erfasst (z. B. Scroll-Ereignisse, Klicks usw.). relevanten und nützlichen Informationen.
Es ist auch nicht allzu bedeutsam, offline zu sein. Als Website-Entwickler kann es Es ist wichtiger, zu wissen, welche Ressourcen nicht geladen werden konnten. Das ist besonders relevant, im Kontext von SPAs, bei denen eine unterbrochene Netzwerkverbindung den Browser nicht offline führt. Fehlerseite (die Nutzer verstehen), aber wahrscheinlicher, dass zufällige dynamische Teile der Seite fehlschlagen lautlos.

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

Ein besserer Ansatz: der Service Worker

Die Lösung, die den Offline-Modus ermöglicht, stellt sich als bessere Lösung für das Offline-Tracking heraus. Nutzung. Die Grundidee besteht darin, Analyse-Pings in IndexedDB zu speichern, solange der Nutzer offline ist. und senden Sie sie erneut, wenn der Nutzer wieder online geht. Für Google Analytics ist dies bereits verfügbar. über ein Workbox-Modul direkt fertig Die Treffer haben jedoch mehr als vier Stunden verschoben verarbeitet werden. In ihrer einfachsten Form kann sie in einem Workbox-basierten Dienst aktiviert werden. mit diesen beiden Zeilen:

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

googleAnalytics.initialize();

Damit werden auch offline alle vorhandenen Ereignisse und Seitenaufruf-Pings erfasst. sie offline abgespielt werden (wie sie sind). In diesem Fall Sie können Tracking-Anfragen mit Workbox bearbeiten, Durch Hinzufügen eines offline-Flags zum Analyse-Ping mithilfe einer benutzerdefinierten Dimension (cd1 im Code) Beispiel unten):

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 eine Internetverbindung hergestellt wird? zurück? Der Service Worker wird dabei normalerweise in den Ruhemodus versetzt, da er die Daten sobald die Verbindung wiederhergestellt wird), verwendet das Workbox-Modul von Google Analytics die Hintergrundsynchronisierung API, die die Analysedaten sendet, später wieder, wenn die Verbindung wiederhergestellt wird, selbst wenn der Nutzer den Tab oder den Browser schließt.

Es gibt immer noch einen Nachteil: Obwohl dadurch das bestehende Tracking offline möglich ist, würdet ihr wahrscheinlich viele relevante Daten erst eingehen, wenn Sie einen einfachen Offline-Modus implementieren. Nutzende würden immer noch Ihre Website schnell wieder verlassen, wenn die Verbindung unterbrochen wird. Aber jetzt können Sie zumindest messen und durch einen Vergleich der durchschnittlichen Sitzungsdauer und des Nutzer-Engagements für Nutzer mit Offline-Conversions. angewendeten Dimension im Vergleich zu Ihren normalen Nutzern.

SPAs und Lazy Loading

Wenn Nutzer, die eine als mehrseitige Website erstellte Seite besuchen, offline gehen und versuchen, zu navigieren, wird die standardmäßige Offlineseite angezeigt, sodass Nutzer verstehen, was gerade passiert. Allerdings werden Seiten, die als Single-Page-Anwendungen funktionieren anders. Der Nutzer bleibt auf derselben Seite und neue Inhalte werden ohne Browsernavigation dynamisch über AJAX geladen werden. Nutzer sehen den Browserfehler nicht wenn Sie offline gehen. Stattdessen werden die dynamischen Teile der Seite mit Fehlern gerendert. oder einfach nicht mehr dynamisch sein.

Ähnliche Auswirkungen können durch Lazy Loading bei mehrseitigen Websites auftreten. Zum Beispiel könnte der Das anfängliche Laden erfolgte online, aber der Nutzer ist vor dem Scrollen offline gegangen. Alle Lazy-Loading-Inhalte „Below the fold“ (mit Scrollen sichtbar) wird ohne Meldung fehlschlagen und nicht angezeigt.

Da diese Fälle die Nutzer sehr stören, ist es sinnvoll, sie zu beobachten. Service Worker sind der perfekte Ort, um Netzwerkfehler aufzuspüren und sie schließlich mithilfe von Analysen zu verfolgen. Mit Workbox ist ein Globaler Catch-Handler kann so konfiguriert werden, dass die Seite durch Senden eines Nachrichtenereignisses über fehlgeschlagene Anfragen informiert 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 Fehler auf bestimmten Routen abfangen. . Wenn Sie beispielsweise Fehler melden möchten, die nur auf Routen nach /products/* auftreten, können Sie Fügen Sie eine Prüfung in setCatchHandler hinzu, die den URI mit einem regulären Ausdruck filtert. Eine übersichtlichere Lösung besteht darin,registerRoute mit einem benutzerdefinierten Handler zu implementieren. Diese kapselt die Geschäftslogik in eine separate Route verschieben, mit besserer Verwaltbarkeit bei komplexeren Service Workern:

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 im Service Worker erfolgen. Als beschrieben, initialisieren Sie das workbox-google-analytics-Plug-in für das integrierte Google Analytics Support.

Im folgenden Beispiel wird Google Analytics verwendet, es kann jedoch auf die gleiche Weise auf andere Analysen angewendet werden. Zulieferunternehmen.

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

Hiermit werden fehlgeschlagene Ressourcenladevorgänge in Google Analytics nachverfolgt, wo sie mit Berichterstellung. Die abgeleitete Erkenntnis kann Wird verwendet, um das Service Worker-Caching und die Fehlerbehandlung im Allgemeinen zu verbessern, um die Seite robuster zu machen und auch unter instabilen Netzwerkbedingungen zuverlässig sind.

Nächste Schritte

In diesem Artikel wurden verschiedene Möglichkeiten zum Erfassen der Offlinenutzung mit ihren Vor- und Nachteilen beschrieben. So können Sie ermitteln, wie viele Ihrer Nutzer offline gehen und auf Probleme stoßen. ist das erst der Anfang. Solange Ihre Website keinen funktionstüchtigen Offlinemodus bietet, ist die Offlinenutzung in Analytics natürlich nicht sehr hoch.

Wir empfehlen, das vollständige Tracking einzurichten und dann Ihre Offline-Funktionen in Iterationen unter Berücksichtigung der Tracking-Zahlen. Beginnen Sie mit einer einfachen Offline-Fehlerseite, Workbox ist einfach, tun – und als Best Practice für die Nutzererfahrung, die einer benutzerdefinierten 404-Seite ähnelt. Arbeiten Sie sich dann entsprechend Ihren Bedürfnissen vor. für erweiterte Offline-Fallbacks und schließlich hin zu Offline-Inhalten. Machen Sie Werbung und erklären Sie dies Ihren Nutzern und die Nutzung wird zunehmen. Schließlich gehen alle hin und wieder offline.

Lesen Sie den Artikel Bericht zu Messwerten erstellen und eine Leistungskultur aufbauen. und Websitegeschwindigkeit funktionsübergreifend korrigieren, um Tipps zu erhalten funktionsübergreifende Stakeholder davon zu überzeugen, mehr in Ihre Website zu investieren. Obwohl diese Beiträge auf Leistung ausgerichtet sind, sollten sie Ihnen allgemeine Vorstellungen davon geben, wie Sie Stakeholdern.

Hero-Foto von JC Gellidon auf Unsplash