Sie haben also eine progressive Web-App mit einem Service Worker, der die Offlinenutzung ermöglicht. Sehr gut! Außerdem haben Sie bereits Google Analytics für Ihre Webanwendung eingerichtet und möchten keine Analysedaten zur Nutzung im Offlinemodus verpassen. Wenn Sie jedoch versuchen, Daten im Offlinemodus an Google Analytics zu senden, schlagen diese Anfragen fehl und die Daten gehen verloren.
Die Lösung sind Service Worker. Insbesondere wird Ihrem Service Worker Code hinzugefügt, um Google Analytics-Anfragen (mit IndexedDB) zu speichern und später noch einmal zu versuchen, wenn hoffentlich ein Netzwerk verfügbar ist. Wir haben Code für die Verarbeitung dieser Logik als Teil der Open-Source-Web-App Google I/O freigegeben. Wir haben jedoch festgestellt, dass dies ein nützliches Muster ist und das Kopieren und Einfügen von Code fehleranfällig sein kann.
Heute können wir Ihnen mitteilen, dass alles, was Sie zum Verarbeiten von Offline-Google Analytics-Anfragen in Ihrem Service Worker benötigen, in einem npm-Paket zusammengefasst wurde: npm install --save-dev sw-offline-google-analytics
sw-offline-google-analytics verwenden
Fügen Sie Ihrem vorhandenen Service Worker-Code Folgendes hinzu:
// This code should live inside your service worker JavaScript, ideally
// before any other 'fetch' event handlers are defined:
// First, import the library into the service worker global scope:
importScripts('path/to/offline-google-analytics-import.js');
// Then, call goog.offlineGoogleAnalytics.initialize():
// See https://github.com/GoogleChrome/workbox/tree/main/packages/workbox-google-analytics
goog.offlineGoogleAnalytics.initialize();
// At this point, implement any other service worker caching strategies
// appropriate for your web app.
Das ist keine Kunst!
Was passiert im Hintergrund?
sw-offline-google-analytics richtet in Ihrem Service Worker einen neuen fetch-Ereignishandler ein, der auf Anfragen an die Google Analytics-Domain reagiert. Anfragen, die nicht von Google Analytics stammen, werden von der Bibliothek ignoriert. So haben die anderen fetch-Ereignishandler Ihres Dienstarbeiters die Möglichkeit, geeignete Strategien für diese Ressourcen zu implementieren. Es wird zuerst versucht, die Anfrage an das Netzwerk zu senden. Wenn der Nutzer online ist, geschieht dies wie gewohnt.
Wenn die Netzwerkanfrage fehlschlägt, speichert die Bibliothek Informationen zur Anfrage an IndexedDB zusammen mit einem Zeitstempel, der angibt, wann die Anfrage ursprünglich gesendet wurde. Jedes Mal, wenn Ihr Service Worker gestartet wird, prüft die Bibliothek, ob Anfragen in der Warteschlange sind, und versucht, sie noch einmal zu senden. Dabei werden auch einige zusätzliche Google Analytics-Parameter berücksichtigt:
- Ein
qt-Parameter, der auf die Zeit festgelegt ist, die seit dem ersten Versuch der Anfrage vergangen ist, damit die ursprüngliche Zeit korrekt zugeordnet werden kann. - Alle zusätzlichen Parameter und Werte, die in der Property
parameterOverridesdes Konfigurationsobjekts angegeben sind und angoog.offlineGoogleAnalytics.initialize()übergeben werden. Sie können beispielsweise eine benutzerdefinierte Dimension verwenden, um Anfragen zu unterscheiden, die vom Service Worker noch einmal gesendet wurden, von denen, die sofort gesendet wurden.
Wenn die Anfrage erfolgreich noch einmal gesendet wurde, ist das super. Die Anfrage wird aus IndexedDB entfernt. Wenn der Wiederholungsversuch fehlschlägt und die ursprüngliche Anfrage vor weniger als 24 Stunden gesendet wurde, wird sie in IndexedDB gespeichert, um beim nächsten Start des Service Workers noch einmal versucht zu werden. Google Analytics-Treffer, die älter als vier Stunden sind, werden nicht garantiert verarbeitet. Es schadet aber nicht, etwas ältere Treffer „nur zur Sicherheit“ noch einmal zu senden.
sw-offline-google-analytics implements außerdem eine „Netzwerk zuerst, dann Fallback auf Cache“-Strategie für den eigentlichen analytics.js JavaScript-Code, der zum Starten von Google Analytics erforderlich ist.
Weitere Funktionen sind in Planung.
sw-offline-google-analytics ist Teil des größeren sw-helpers-Projekts, einer Bibliothek, die Drop-in-Erweiterungen für vorhandene Service Worker-Implementierungen bietet.
Zu diesem Projekt gehört auch sw-appcache-behavior, eine Bibliothek, die Caching-Strategien implementiert, die in einem vorhandenen AppCache-Manifest in einem Service Worker definiert sind. Sie soll Ihnen dabei helfen, von AppCache zu Service Workern zu migrieren und dabei zumindest anfangs eine einheitliche Caching-Strategie beizubehalten.
Wenn du weitere Ideen für die Mediathek hast, freuen wir uns über deine Nachricht. Bitte senden Sie uns eine Anfrage im Issue Tracker.