Misurazione dell'utilizzo offline

Come monitorare l'utilizzo offline del sito in modo da poter capire perché il sito necessita di una migliore esperienza offline.

Stephan Giesau

Martin Schierle

Questo articolo spiega come monitorare l'utilizzo offline del tuo sito per capire perché il tuo sito necessita di una modalità offline migliore. Spiega inoltre gli inconvenienti e i problemi da evitare durante l'implementazione dell'analisi dell'utilizzo offline.

Insidie degli eventi del browser online e offline

La soluzione più ovvia per il monitoraggio dell'utilizzo offline è creare listener di eventi per gli eventi online e offline (supportati da molti browser) e inserire la logica di monitoraggio di analisi in questi listener. Sfortunatamente, questo approccio presenta diversi problemi e limitazioni:

• In generale, il monitoraggio di ogni evento relativo allo stato della connessione di rete può essere eccessivo ed è controproducente in un mondo incentrato sulla privacy in cui deve essere raccolta la minor quantità di dati possibile. Inoltre, gli eventi online e offline possono attivarsi solo per una frazione di secondo di perdita di rete, cosa che un utente probabilmente non potrebbe nemmeno vedere o notare.
• Il monitoraggio analitico dell'attività offline non raggiungerebbe mai il server di analisi perché l'utente è... beh, offline.
• 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 dipende dall'utente che visita di nuovo il sito. Se l'utente abbandona il sito per mancanza di una modalità offline e non visita più la pagina, non hai modo di monitorarlo. La capacità di monitorare gli abbandoni offline è un dato fondamentale per capire perché il tuo sito necessita di una migliore modalità offline.
• L'evento online non è molto affidabile in quanto conosce 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 ancora non riuscire.
• Anche se l'utente rimane offline sulla pagina corrente, non viene monitorato neppure nessuno degli altri eventi di analisi (ad es. eventi di scorrimento, clic e così via), che potrebbero rappresentare le informazioni più pertinenti e utili.
• Anche il fatto di essere offline di per sé non è molto significativo in generale. Per uno sviluppatore di siti web potrebbe essere più importante sapere quali tipi di risorse non si caricano. Ciò è particolarmente importante nel contesto delle APS, dove un'interruzione della connessione di rete potrebbe non indirizzare a una pagina di errore offline del browser (che gli utenti comprendono), ma è più probabile che si verifichino errori silenziosi in parti dinamiche casuali della pagina.

Puoi comunque utilizzare questa soluzione per acquisire una conoscenza di base dell'utilizzo offline, ma i numerosi svantaggi e limitazioni devono essere considerati con attenzione.

Un approccio migliore: il service worker

La soluzione che abilita la modalità offline si rivela la migliore per monitorare l'utilizzo offline. L'idea di base è quella di archiviare i ping di analisi in IndexedDB finché l'utente è offline e di inviarli di nuovo quando l'utente torna online. Per Google Analytics, questa funzionalità è già disponibile tramite un modulo Workbox, ma tieni presente che gli hit inviati più di quattro ore differite 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();

Questa opzione consente di tenere traccia di tutti gli eventi e dei ping di visualizzazione di pagina esistenti mentre sei offline, ma potresti non sapere che si sono verificati offline (perché vengono riprodotti così come sono). A questo scopo, puoi manipolare le richieste di monitoraggio con Workbox aggiungendo un flag offline al ping di Analytics, utilizzando una dimensione personalizzata (cd1 nell'esempio di codice riportato di seguito):

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

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

Cosa succede se l'utente esce dalla pagina perché è offline prima che venga ripristinata la connessione a internet? Anche se in genere questa operazione mette in sospensione il service worker (perché non è in grado di inviare i dati quando la connessione viene ripristinata), il modulo Google Analytics Workbox utilizza l'API Background Sync, che invia i dati di analisi in un secondo momento quando viene ripristinata la connessione, anche se l'utente chiude la scheda o il browser.

C'è comunque uno svantaggio: sebbene ciò renda disponibile il monitoraggio offline esistente, molto probabilmente non riceverai molti dati rilevanti finché non implementi una modalità offline di base. Gli utenti abbandonano il sito rapidamente anche in caso di interruzione della connessione. Ma ora puoi almeno misurarlo e quantificarlo confrontando la durata media della sessione e il coinvolgimento degli utenti per gli utenti con la dimensione offline applicata con quella degli utenti normali.

APS e caricamento lento

Se gli utenti che visitano una pagina creata come sito web con più pagine passano alla modalità 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 navigazione tramite browser. Gli utenti non vedono la pagina di errore del browser quando sono offline. Al contrario, le parti dinamiche della pagina vengono visualizzate con errori, passano a stati indefiniti o semplicemente non sono più dinamiche.

Effetti simili possono verificarsi nei siti web con più pagine 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 caricati con il metodo lazy below the fold si disattivano automaticamente e non saranno più disponibili.

Poiché questi casi sono davvero irritanti per gli utenti, ha senso monitorarli. I Service worker sono il punto perfetto per individuare gli errori di rete e, infine, monitorarli mediante l'analisi. Con Workbox, è possibile configurare un gestore di raccolta globale che informa 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é ascoltare tutte le richieste non riuscite, un altro modo è rilevare gli errori solo su route specifiche. Ad esempio, se vogliamo segnalare errori che si verificano solo sulle route verso /products/*, possiamo aggiungere un segno di spunta in setCatchHandler che filtra l'URI con un'espressione regolare. Una soluzione più pulita è implementare registryRoute con un gestore personalizzato. Questo incapsula la logica di business 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 ascoltare l'evento message e inviare il ping di Analytics. Anche in questo caso, assicurati di eseguire il buffering delle richieste di analisi che si verificano offline all'interno del service worker. Come descritto prima, inizializza il plug-in workbox-google-analytics per il supporto integrato di Google Analytics.

Il seguente esempio utilizza Google Analytics, ma può essere applicato allo stesso modo per altri fornitori di soluzioni 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 verranno tracciati i caricamenti di risorse non riusciti in Google Analytics, dove potranno essere analizzati mediante report. Gli insight derivati possono essere utilizzati per migliorare la memorizzazione nella cache e la gestione degli errori dei service worker in generale, al fine di rendere la pagina più solida e affidabile in condizioni di rete instabili.

Passaggi successivi

Questo articolo mostra diversi modi per monitorare l'utilizzo offline con i relativi vantaggi e limiti. Anche se questo può aiutare a quantificare quanti dei tuoi utenti vanno offline e riscontrano i problemi dovuti, si è comunque solo l'inizio. Se il tuo sito web non offre una modalità offline ben strutturata, ovviamente non vedrai un utilizzo elevato della modalità offline in Analytics.

Ti consigliamo di implementare il monitoraggio completo e poi estendere le funzionalità offline in iterazioni tenendo d'occhio i numeri di riferimento. Inizia con una semplice pagina di errore offline, in cui Workbox è semplice e dovrebbe comunque essere considerata una best practice per l'esperienza utente simile alle pagine 404 personalizzate. Procedi poi verso fallback offline più avanzate e infine su contenuti offline reali. Assicurati di pubblicizzare e spiegare meglio questa cosa ai tuoi utenti: noterai un aumento dell'utilizzo. Dopotutto, ogni tanto tutti passano alla modalità offline.

Consulta Come generare report sulle metriche e creare una cultura del rendimento e Correggere la velocità del sito web in modo interfunzionale per suggerimenti su come convincere stakeholder interfunzionali a investire di più nel tuo sito web. Anche se questi post sono incentrati sul rendimento, dovrebbero aiutarti a trovare idee generali su come coinvolgere le parti interessate.

Foto hero di JC Gellidon su Unsplash.