Tienes una aplicación web progresiva, completa con un service worker que le permite funcionar sin conexión. ¡Genial! También tienes configurado Google Analytics para tu aplicación web y no quieres perderte ninguna estadística de las interacciones que se producen sin conexión. Sin embargo, si intentas enviar datos a Google Analytics sin conexión, esas solicitudes fallarán y se perderán los datos.
La solución, no debería sorprenderte, son los trabajadores de servicio. Específicamente, agrega código a tu trabajador de servicio para almacenar las solicitudes de Google Analytics (con IndexedDB) y volver a intentarlas más tarde, cuando haya una red disponible. Compartimos código para controlar esta lógica como parte de la app web de Google I/O de código abierto, pero nos dimos cuenta de que este era un patrón útil y que copiar y pegar código puede ser frágil.
Hoy, nos complace anunciar que todo lo que necesitas para controlar las solicitudes de Google Analytics sin conexión en tu trabajador de servicio se empaquetó en un paquete npm: npm install --save-dev sw-offline-google-analytics
Con sw-offline-google-analytics
Desde el código de tu servicio de trabajo existente, agrega lo siguiente:
// 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.
¡Esto es todo lo que hay sobre este tema!
¿Qué sucede en el interior?
sw-offline-google-analytics configura un nuevo controlador de eventos fetch en tu trabajador de servicio, que responde a las solicitudes realizadas al dominio de Google Analytics. (La biblioteca ignora las solicitudes que no son de Google Analytics, lo que les brinda a los otros controladores de eventos fetch de tu trabajador del servicio la oportunidad de implementar estrategias adecuadas para esos recursos). Primero, intentará entregar la solicitud a la red. Si el usuario está en línea, se realizará de forma normal.
Si la solicitud de red falla, la biblioteca almacenará automáticamente la información sobre la solicitud en IndexedDB, junto con una marca de tiempo que indica cuándo se realizó la solicitud inicialmente. Cada vez que se inicia tu trabajador de servicio, la biblioteca comprueba si hay solicitudes en cola y intenta volver a enviarlas, junto con algunos parámetros adicionales de Google Analytics:
- Un parámetro
qt, establecido en la cantidad de tiempo que transcurrió desde que se intentó la solicitud inicialmente, para garantizar que el tiempo original se atribuya correctamente. - Cualquier parámetro adicional y valor proporcionado en la propiedad
parameterOverridesdel objeto de configuración que se pasa agoog.offlineGoogleAnalytics.initialize()Por ejemplo, puedes incluir una dimensión personalizada para distinguir las solicitudes que se volvieron a enviar desde el trabajador de servicio de las que se enviaron de inmediato.
Si la solicitud se vuelve a enviar correctamente, ¡genial! La solicitud se quita de IndexedDB. Si el reintento falla y la solicitud inicial se realizó hace menos de 24 horas, se mantendrá en IndexedDB para volver a intentarlo la próxima vez que se inicie el service worker. Ten en cuenta que no se garantiza que se procesen los hits de Google Analytics que tengan más de cuatro horas, pero no debería haber ningún problema si vuelves a enviar los hits más antiguos “por si acaso”.
sw-offline-google-analytics también implements una estrategia de"prioridad a la red, con resguardo en la caché" para el código JavaScript analytics.js real que se necesita para iniciar Google Analytics.
¡Pronto agregaremos más!
sw-offline-google-analytics forma parte del proyecto sw-helpers más grande, que es una colección de bibliotecas diseñada para proporcionar mejoras integradas a las implementaciones de trabajadores del servicio existentes.
También forma parte de ese proyecto sw-appcache-behavior, una biblioteca que implementa estrategias de almacenamiento en caché definidas en un manifiesto de AppCache existente dentro de un service worker. Su objetivo es ayudarte a migrar de AppCache a service workers y, al mismo tiempo, mantener una estrategia de almacenamiento en caché coherente, al menos al principio.
Si tienes otras ideas para la biblioteca, nos encantaría escucharlas. Envía una solicitud en el seguimiento de problemas.