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. Comprendere quali insidie e problemi evitare durante l'implementazione dell'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 eventi online e offline (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 e 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 un utente probabilmente non vedrebbe o non noterebbe nemmeno.
• Il monitoraggio dell'attività offline di Analytics non raggiunge il server di Analytics.
• Il monitoraggio locale di un timestamp quando un utente passa alla modalità offline e l'invio dell'attività offline al server di analisi quando l'utente torna online dipendono dal fatto che l'utente visiti nuovamente il tuo sito. Se l'utente abbandona il tuo sito a causa della mancanza di una modalità offline e non lo visita più, non hai modo di monitorarlo. La possibilità di monitorare le interruzioni offline è un dato fondamentale per dimostrare perché il tuo sito ha bisogno di una modalità offline migliore.
• L'evento online non è molto affidabile perché rileva solo l'accesso alla rete, non l'accesso a internet. Pertanto, 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 viene monitorato nessuno degli altri eventi di Analytics (ad es. eventi di scorrimento, clic e così via), che potrebbero essere le informazioni più pertinenti e utili.
• La semplice disconnessione non è molto significativa. Probabilmente è più importante sapere quali risorse non vengono caricate. Questo è particolarmente importante per le applicazioni a pagina singola (SPA), in cui una connessione di rete interrotta potrebbe non portare a una pagina di errore offline del browser, che gli utenti comprendono. Invece, è probabile che parti dinamiche casuali della pagina non vengano caricate senza che venga visualizzato un messaggio di errore.

Puoi comunque utilizzare questa soluzione per comprendere l'utilizzo offline, ma devi considerare attentamente i numerosi svantaggi e limitazioni.

Un approccio migliore: il service worker

La soluzione che attiva la modalità offline è anche una soluzione migliore per monitorare l'utilizzo offline. Puoi memorizzare i ping di analisi 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 esistenti e i ping delle visualizzazioni di pagina mentre sei offline, ma non sapresti che si sono verificati offline, poiché vengono semplicemente 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 venga ripristinata? In genere, questo mette in pausa il service worker, in quanto non può inviare i dati quando la connessione viene ripristinata. Tuttavia, il modulo Google Analytics di Workbox utilizza l'API Background Sync. La sincronizzazione in background invia i dati di analisi quando la connessione viene ripristinata, anche se l'utente chiude la scheda o il browser.

C'è ancora uno svantaggio: anche se questo rende il monitoraggio esistente compatibile con la modalità offline, molto probabilmente 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. Ma ora 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 li aiuta 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 nel browser. Gli utenti non vedono la pagina di errore del browser quando sono offline. Invece, le parti dinamiche della pagina vengono visualizzate con errori, entrano in stati non definiti o semplicemente smettono di essere dinamiche.

Effetti simili possono verificarsi nei siti web con più pagine a causa del caricamento lento. Ad esempio, forse il caricamento iniziale è avvenuto online, ma l'utente è andato offline prima di scorrere. Tutti i contenuti con caricamento lento below the fold non verranno caricati e non saranno presenti.

Poiché questi casi sono davvero fastidiosi per gli utenti, è opportuno monitorarli. I service worker sono il punto perfetto per rilevare gli errori di rete e, infine, monitorarli utilizzando l'analisi. Con Workbox, è possibile configurare un gestore catch globale per informare la pagina delle richieste non andate a buon fine 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é ascoltare tutte le richieste non riuscite, un altro modo è rilevare gli errori solo su route specifiche. Ad esempio, se vogliamo segnalare solo gli errori che si verificano sui percorsi verso /products/*, possiamo aggiungere un controllo in setCatchHandler che filtra l'URI con un'espressione regolare.

Una soluzione più pulita consiste nell'implementare registerRoute con un gestore personalizzato. In questo modo, la logica di business viene incapsulata in un percorso separato, con una migliore gestibilità 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 passaggio finale, la pagina deve ascoltare l'evento message e inviare il ping di analisi. Anche in questo caso, assicurati di memorizzare nel buffer le richieste di analisi 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 nello stesso modo per altri fornitori 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. Le informazioni ottenute possono essere utilizzate 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 appreso diversi modi per monitorare l'utilizzo offline, con i relativi vantaggi e svantaggi. Anche se questo può aiutare a quantificare quanti utenti vanno offline e riscontrano problemi a causa di ciò, è solo un inizio. Se il tuo sito web non offre una modalità offline ben strutturata, ovviamente non vedrai un utilizzo offline significativo in Analytics.

Ti consigliamo di implementare il monitoraggio completo e poi di estendere le funzionalità offline in iterazioni, con un focus sul monitoraggio. Inizia con una pagina di errore offline. È un'operazione molto semplice da eseguire con Workbox ed è una best practice per la UX simile alle pagine 404 personalizzate. Poi, passa a strategie di riserva offline più avanzate e infine ai contenuti offline reali. Assicurati di pubblicizzare e spiegare bene questa funzionalità ai tuoi utenti e vedrai un aumento dell'utilizzo. Dopotutto, tutti vanno offline di tanto in tanto.

Consulta How to report metrics and build a performance culture e Fixing website speed cross-functionally per suggerimenti su come convincere gli stakeholder interfunzionali a investire di più nel tuo sito web. Anche se questi post si concentrano sul rendimento, dovrebbero aiutarti a farti un'idea generale di come coinvolgere gli stakeholder.