Misurazione dell'utilizzo offline

Come monitorare l'utilizzo offline del tuo sito per evidenziare il motivo per cui il sito ha bisogno di un'esperienza offline migliore.

Stephan Giesau

Martin Schierle

Questo articolo spiega come monitorare l'utilizzo offline del sito per capire meglio perché il sito ha bisogno di una modalità offline migliore. Spiega inoltre gli inconvenienti e i problemi da evitare quando si implementa l'analisi dell'utilizzo offline.

Le insidie degli eventi del browser online e offline

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

• In generale, il monitoraggio di ogni evento relativo allo 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 attivarsi solo per una frazione di secondo di perdita di rete, che probabilmente un utente non vedrebbe nemmeno.
• Il monitoraggio analitico delle attività offline non raggiungerebbe mai il server di analisi perché l'utente è... offline.
• Il monitoraggio locale di un timestamp relativo al momento in cui un utente è offline e l'invio dell'attività offline al server di analisi quando l'utente torna online dipende dalla visita di nuovo sito dell'utente. Se l'utente abbandona il sito a causa dell'assenza di una modalità offline e non visita mai di nuovo il sito, non hai modo di monitorarlo. La possibilità di monitorare gli abbandoni offline è un dato fondamentale per elaborare un'argomentazione del motivo per cui il 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 non riuscire.
• Anche se l'utente rimane sulla pagina corrente mentre è offline, non viene monitorato nemmeno nessuno degli altri eventi di analisi (ad es. eventi di scorrimento, clic e così via), che potrebbero rappresentare le informazioni più pertinenti e utili.
• Essere offline di per sé non è poi molto significativo in generale. Per gli sviluppatori di siti web potrebbe essere più importante sapere quali tipi di risorse non sono state caricate. Ciò è particolarmente importante nel contesto delle APS, in cui una connessione di rete interrotta potrebbe non portare a una pagina di errore offline del browser (comprensibile agli utenti), ma più probabilmente a parti dinamiche casuali della pagina non funzionano in silenzio.

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 consente la modalità offline si rivela quella migliore per monitorare l'utilizzo offline. L'idea di base è archiviare 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 disponibile tramite un modulo Workbox, ma tieni presente che gli hit inviati più di quattro ore differiti 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 relativi alle visualizzazioni di pagina esistenti anche offline, ma non sai se si sono verificati offline (dal momento che vengono riprodotti così come sono). Per farlo, puoi manipolare le richieste di monitoraggio con Workbox aggiungendo un flag offline al ping di Analytics e utilizzando una dimensione personalizzata (cd1 nell'esempio di codice riportato di seguito):

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

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

Che cosa succede se l'utente esce dalla pagina perché è offline prima che ritorni a essere connessi a internet? Anche se questo di solito mette in modalità di sospensione il service worker (perché non è in grado di inviare i dati quando viene ripristinata la connessione), il modulo Google Analytics di Workbox utilizza l'API Workbox Google Analytics, 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'è ancora uno svantaggio: anche se questo rende il monitoraggio esistente compatibile, è molto probabile che non vedresti molti dati pertinenti finché non implementi una modalità offline di base. Gli utenti escono comunque rapidamente dal tuo sito non appena la connessione viene interrotta. Tuttavia, ora è possibile almeno misurare e quantificare questo aspetto, confrontando la durata media delle sessioni 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 un sito web di più pagine passano offline e provano a navigare, viene visualizzata la pagina offline predefinita del browser, che aiuta gli utenti a capire che cosa sta succedendo. Tuttavia, le pagine create come applicazioni a pagina singola funzionano in modo diverso. L'utente rimane nella stessa pagina e i nuovi contenuti vengono caricati in modo dinamico tramite AJAX senza alcuna navigazione nel 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 in stati non definiti o smettono semplicemente di essere 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 è passato offline prima di scorrere. Tutti i contenuti caricati con il metodo lazy below the fold non riusciranno e non saranno pubblicati.

Dato che questi casi sono molto irritanti per gli utenti, è opportuno tenerne traccia. I service worker sono il punto perfetto per rilevare gli errori di rete e alla fine monitorarli utilizzando l'analisi. Con Workbox, è possibile configurare un gestore catch globale per informare la pagina sulle 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 vuoi segnalare errori che si verificano solo nelle route /products/*, possiamo aggiungere un controllo in setCatchHandler che filtra l'URI con un'espressione regolare. Una soluzione più pulita consiste nell'implementazione di registerRoute con un gestore personalizzato. Ciò incapsula la logica di business 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 rimanere in ascolto dell'evento message e inviare il ping di analisi. Assicurati di nuovo di eseguire il buffer 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.

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

Questa operazione monitorerà i caricamenti di risorse non riusciti in Google Analytics, dove potranno essere analizzati con i report. L'insight derivato può essere utilizzato per migliorare la memorizzazione nella cache dei service worker e la gestione degli errori in generale, al fine di rendere la pagina più solida e affidabile in condizioni di rete instabili.

Passaggi successivi

Questo articolo illustra diversi modi per monitorare l'utilizzo offline e ne illustra i vantaggi e le carenze. Anche se può essere utile per quantificare il numero di utenti che passano alla modalità offline e riscontrano problemi dovuti, è comunque solo un punto di partenza. Finché il tuo sito web non offre una modalità offline ben strutturata, ovviamente non vedrai un utilizzo della modalità offline molto utile in Analytics.

Ti consigliamo di attivare il monitoraggio completo e di estendere le funzionalità offline nelle iterazioni prestando attenzione ai numeri di riferimento. Inizia con una semplice pagina di errore offline, con Workbox è banale e deve essere comunque considerata una best practice per l'esperienza utente simile alle pagine 404 personalizzate. Poi, procedi verso i fallback offline più avanzati e infine scopri i contenuti offline reali. Se pubblicizzi e spieghi bene questo concetto agli utenti, noterai che l'utilizzo è aumentato. Dopotutto, di tanto in tanto tutti passano offline.

Consulta gli articoli 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 gli stakeholder interfunzionali a investire di più nel tuo sito web. Sebbene questi post siano incentrati sul rendimento, dovrebbero aiutarti a trovare idee generali su come coinvolgere le parti interessate.

Foto hero di JC Gellidon su Unsplash.