Misurare l'utilizzo offline

Come monitorare l'utilizzo offline del tuo sito in modo da poter dimostrare perché il tuo sito ha bisogno di un'esperienza offline migliore.

Stephan Giesau

Martin Schierle

Scopri come monitorare l'utilizzo offline del tuo sito, in modo da poter dimostrare perché il tuo sito ha bisogno di una modalità offline migliore. Scopri quali insidie e problemi evitare quando implementi l'analisi dell'utilizzo offline.

Le insidie degli eventi del browser online e offline

La soluzione ovvia per monitorare l'utilizzo offline è creare listener di eventi per gli online e offline eventi (supportati da molti browser) e inserire la logica di monitoraggio di Analytics in questi listener. Purtroppo, questo approccio presenta diversi problemi e limitazioni:

• In generale, il monitoraggio di ogni evento di stato della connessione di rete potrebbe essere eccessivo ed è controproducente in un mondo incentrato sulla privacy in cui è necessario raccogliere il minor numero possibile di dati. Inoltre, gli eventi online e offline possono essere attivati per una frazione di secondo di perdita di rete, che probabilmente un utente non vedrebbe o noterebbe nemmeno.
• Il monitoraggio di Analytics dell'attività offline non raggiunge il server di Analytics.
• Il monitoraggio di un timestamp in locale quando un utente va offline e l'invio dell'attività offline al server di Analytics quando l'utente torna online dipende dalla visita dell'utente al tuo sito. Se l'utente abbandona il tuo sito a causa della mancanza di una modalità offline e non lo visita mai più, non hai modo di monitorarlo. La possibilità di monitorare gli abbandoni offline è fondamentale per dimostrare perché il tuo sito ha bisogno di una modalità offline migliore.
• L'evento online non è molto affidabile perché conosce solo l'accesso alla rete, non l'accesso a internet. Di conseguenza, un utente potrebbe essere ancora offline e l'invio del ping di monitoraggio potrebbe comunque non riuscire.
• Anche se l'utente rimane sulla pagina corrente mentre è offline, non vengono monitorati nemmeno gli altri eventi di Analytics (ad es. eventi di scorrimento, clic e così via), che potrebbero essere le informazioni più pertinenti e utili.
• Essere offline non è molto significativo. È probabile che sia più importante sapere quali risorse non vengono caricate. Ciò è particolarmente importante per le applicazioni a pagina singola (SPA), in cui una connessione di rete interrotta potrebbe non comportare la visualizzazione di una pagina di errore offline del browser, che gli utenti comprendono. Al contrario, è probabile che le parti dinamiche casuali della pagina non funzionino in modo silenzioso.

Puoi comunque utilizzare questa soluzione per ottenere una comprensione di base dell'utilizzo offline, ma è necessario considerare attentamente i numerosi svantaggi e limitazioni.

Un approccio migliore: il service worker

La soluzione che consente la modalità offline è anche una soluzione migliore per monitorare l'utilizzo offline. Puoi archiviare i ping di Analytics in IndexedDB finché l'utente è offline e inviarli di nuovo quando l'utente torna online. Per Google Analytics, questa funzionalità è già disponibile in un modulo Workbox, ma tieni presente che gli hit inviati con un ritardo superiore a quattro ore potrebbero non essere elaborati.

Nella sua forma più semplice, può essere attivato all'interno di un service worker basato su Workbox con queste due righe:

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

googleAnalytics.initialize();

In questo modo vengono monitorati tutti gli eventi e i ping di visualizzazione di pagina esistenti mentre sei offline, ma non saresti in grado di sapere che si sono verificati offline, perché vengono riprodotti così come sono. Puoi manipolare le richieste di monitoraggio con Workbox aggiungendo un flag offline al ping di Analytics, utilizzando una dimensione personalizzata:

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

googleAnalytics.initialize({
  parameterOverrides: {
    customDimension1: 'offline',
  },
});

Cosa succede se l'utente abbandona la pagina perché è offline, prima che la connessione a internet torni? Anche se in genere il service worker viene messo in sospensione, poiché non può inviare i dati quando la connessione torna, il modulo Workbox Google Analytics utilizza l'API Background Sync. Background Sync invia i dati di Analytics quando la connessione torna, anche se l'utente chiude la scheda o il browser.

Esiste ancora uno svantaggio: anche se in questo modo il monitoraggio esistente è in grado di funzionare offline, è molto probabile che non vedrai molti dati pertinenti fino a quando non implementerai una modalità offline di base. Gli utenti abbandonerebbero comunque rapidamente il tuo sito quando la connessione si interrompe. Ora, però, puoi almeno misurare e quantificare questo aspetto, confrontando la durata media della sessione e il coinvolgimento degli utenti con la dimensione offline applicata rispetto agli utenti normali.

SPA e caricamento lento

Se gli utenti che visitano una pagina creata come sito web multipagina vanno offline e provano a navigare, viene visualizzata la pagina offline predefinita del browser, che aiuta gli utenti a capire cosa sta succedendo. Tuttavia, le pagine create come applicazioni a pagina singola funzionano in modo diverso. L'utente rimane sulla stessa pagina e i nuovi contenuti vengono caricati dinamicamente tramite AJAX senza alcuna navigazione del browser. Gli utenti non vedono la pagina di errore del browser quando vanno offline. Al contrario, le parti dinamiche della pagina vengono visualizzate con errori, passano a stati non definiti o semplicemente smettono di essere dinamiche.

Effetti simili possono verificarsi all'interno di siti web multipagina a causa del caricamento lento. Ad esempio, il caricamento iniziale potrebbe essere avvenuto online, ma l'utente è andato offline prima di scorrere. Tutti i contenuti a caricamento lento below the fold non verranno caricati e non saranno visualizzati.

Poiché questi casi sono davvero fastidiosi per gli utenti, è opportuno monitorarli. I service worker sono il punto ideale per rilevare gli errori di rete e, infine, monitorarli utilizzando Analytics. Con Workbox, è possibile configurare un gestore di rilevamento globale per informare la pagina delle richieste non riuscite inviando un evento di messaggio:

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

  }());
});

Anziché rimanere in ascolto di tutte le richieste non riuscite, un altro modo è rilevare gli errori solo su route specifiche. Ad esempio, se vogliamo segnalare gli errori che si verificano solo sulle route a /products/*, possiamo aggiungere un controllo in setCatchHandler che filtri l'URI con un'espressione regolare.

Una soluzione più pulita è implementare registerRoute con un gestore personalizzato. In questo modo la logica di business viene incapsulata in una route separata, con una migliore manutenibilità nei service worker più complessi:

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

Come ultimo passaggio, la pagina deve rimanere in ascolto dell'evento message e inviare il ping di Analytics. Anche in questo caso, assicurati di memorizzare nel buffer le richieste di Analytics che si verificano offline all'interno del service worker. Come descritto in precedenza, inizializza il plug-in workbox-google-analytics per il supporto integrato di Google Analytics.

L'esempio seguente utilizza Google Analytics, ma può essere applicato allo stesso modo per altri fornitori di servizi di analisi.

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

In questo modo, i caricamenti delle risorse non riusciti verranno monitorati in Google Analytics, dove potranno essere analizzati con i report. L'approfondimento derivato può essere utilizzato per migliorare la memorizzazione nella cache del service worker e la gestione degli errori in generale, per rendere la pagina più solida e affidabile in condizioni di rete instabili.

Passaggi successivi

Hai imparato diversi modi per monitorare l'utilizzo offline con i relativi vantaggi e svantaggi. Anche se questo può aiutarti a quantificare quanti utenti vanno offline e riscontrano problemi a causa di questa situazione, è solo l'inizio. Se il tuo sito web non offre una modalità offline ben strutturata, ovviamente non vedrai molto utilizzo offline in Analytics.

Ti consigliamo di implementare il monitoraggio completo e poi di estendere le funzionalità offline in modo iterativo, concentrandoti sul monitoraggio. Inizia con una pagina di errore offline. È facile da creare con Workbox ed è una best practice UX simile alle pagine 404 personalizzate. Poi, passa a fallback offline più avanzati e, infine, a contenuti offline reali. Assicurati di pubblicizzare e spiegare bene questa funzionalità ai tuoi utenti e vedrai un aumento dell'utilizzo. Dopo tutto, tutti vanno offline di tanto in tanto.

Consulta Come creare report sulle metriche e una cultura delle prestazioni e Risolvere i problemi di velocità dei siti web in modo interfunzionale per suggerimenti su come convincere gli stakeholder interfunzionali a investire di più nel tuo sito web. Anche se questi post sono incentrati sul rendimento, dovrebbero aiutarti a farti un'idea generale su come coinvolgere gli stakeholder.