Você tem um Progressive Web App completo com um service worker que permite que ele funcione off-line. Ótimo! Você também tem o Google Analytics configurado para seu app da Web e não quer perder insights analíticos provenientes do uso que ocorre off-line. No entanto, se você tentar enviar dados ao Google Analytics enquanto estiver off-line, essas solicitações vão falhar e os dados serão perdidos.
Você não deve se surpreender com o aprendizado: os service workers. Especificamente, ele adiciona código ao service worker para armazenar solicitações do Google Analytics (usando IndexedDB) e repeti-las mais tarde quando houver uma rede disponível. Nós compartilhamos o código para lidar com essa lógica como parte do aplicativo de código aberto Google I/O, mas percebemos que esse é um padrão de código útil, além de copiar e colar.
Hoje, temos o prazer de anunciar que tudo o que você precisa para processar solicitações off-line do Google Analytics no seu service worker foi agrupado em um pacote npm: npm install --save-dev sw-offline-google-analytics
Como usar sw-off-line-google-analytics
No código do service worker atual, adicione o seguinte:
// 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.
Isso é tudo!
O que está acontecendo nos bastidores?
O sw-offline-google-analytics configura um novo manipulador de eventos fetch no service worker, que responde às solicitações feitas ao domínio do Google Analytics. A biblioteca ignora solicitações que não são do Google Analytics, o que dá aos outros manipuladores de eventos fetch do seu service worker a chance de implementar estratégias apropriadas para esses recursos. Primeiro, ele tentará atender à solicitação na rede. Se o usuário estiver on-line, o processo será feito normalmente.
Se a solicitação de rede falhar, a biblioteca vai armazenar automaticamente informações sobre a solicitação para IndexedDB, além de um carimbo de data/hora indicando quando a solicitação foi feita. Sempre que o service worker for iniciado, a biblioteca vai verificar se há solicitações na fila e tentar reenviá-las com alguns parâmetros adicionais do Google Analytics:
- Um parâmetro
qt, definido como o tempo decorrido desde a primeira tentativa de solicitação, para garantir que o horário original seja atribuído corretamente. - Todos os valores e parâmetros adicionais fornecidos na propriedade
parameterOverridesdo objeto de configuração transmitidos paragoog.offlineGoogleAnalytics.initialize(). Por exemplo, é possível incluir uma dimensão personalizada para diferenciar solicitações reenviadas do service worker daquelas enviadas imediatamente.
Se o reenvio da solicitação der certo, ótimo. A solicitação é removida do IndexedDB. Se a nova tentativa falhar e a solicitação inicial tiver sido feita há menos de 24 horas, ela será mantida em IndexedDB para uma nova tentativa de execução do service worker. Não há garantia de processamento dos hits do Google Analytics com mais de quatro horas. No entanto, o reenvio de hits mais antigos "por precaução" não deve prejudicar.
sw-offline-google-analytics também implements uma estratégia"Rede primeiro, voltando para o cache" para o analytics.js código JavaScript necessário para inicializar o Google Analytics.
Há muito mais por vir!
O sw-offline-google-analytics faz parte do projeto sw-helpers maior, que é um conjunto de bibliotecas criado para fornecer melhorias nas implementações do service worker.
Também faz parte desse projeto a sw-appcache-behavior, uma biblioteca que implementa estratégias de armazenamento em cache definidas em um manifesto do AppCache existente dentro de um service worker. O objetivo é ajudar você a migrar do AppCache para service workers enquanto mantém uma estratégia de armazenamento em cache consistente, pelo menos inicialmente.
Se você tiver outras ideias para a biblioteca, entre em contato. Portanto, envie uma solicitação no Issue Tracker.