Misurazione dell'utilizzo offline

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

Stephan Giesau

Martin Schierle

Questo articolo spiega come monitorare l'utilizzo offline del tuo sito per aiutarti a dimostrare perché il tuo sito ha bisogno di una modalità offline migliore. Vengono inoltre spiegati i problemi e le insidie da evitare durante l'implementazione dell'analisi dell'utilizzo offline.

I rischi degli eventi 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. Sfortunatamente, questo approccio presenta diversi problemi e limiti:

• 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 devono essere raccolti il minor numero possibile di dati. 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 delle analisi delle attività offline non raggiungerà mai il server di analisi perché l'utente è… offline.
• Il monitoraggio di un timestamp localmente quando un utente passa alla modalità offline e l'invio dell'attività offline al server di analisi quando l'utente torna online dipende dal fatto che l'utente visiti di nuovo il tuo sito. Se l'utente abbandona il tuo sito a causa della mancanza di una modalità offline e non torna mai più, non hai modo di monitorarlo. La possibilità di monitorare i abbandoni offline è un dato fondamentale per dimostrare perché il tuo sito ha bisogno di una modalità offline migliore.
• 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 può 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 l'offline in sé non è troppo significativo in generale. Per uno sviluppatore di siti web potrebbe essere più importante sapere quali tipi di risorse non si caricano. Questo è particolarmente importante nel contesto delle SPA, in cui l'interruzione della connessione di rete potrebbe non portare a una pagina di errore del browser offline (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 devi valutare attentamente i numerosi svantaggi e le limitazioni.

Un approccio migliore: il service worker

La soluzione che attiva la modalità offline risulta essere la migliore per monitorare l'utilizzo offline. L'idea di base è memorizzare i ping di analisi in IndexedDB finché l'utente è offline e inviare nuovamente quando l'utente torna online. Per Google Analytics, questa funzionalità è già disponibile come soluzione pronta all'uso tramite un modulo Workbox, ma tieni presente che gli hit inviati con più di quattro ore di differimento 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 in modalità offline, ma non saprai che si sono verificati offline (poiché vengono semplicemente 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',
  },
});

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

Esiste ancora uno svantaggio: anche se il monitoraggio esistente diventa compatibile con l'offline, molto probabilmente non visualizzerai molti dati pertinenti finché non implementerai una modalità offline di base. Gli utenti abbandonano il sito rapidamente anche in caso di interruzione della connessione. Ora, però, puoi almeno misurare e quantificare questo aspetto, confrontando la durata media della sessione e il coinvolgimento degli utenti per gli utenti a cui è stata applicata la dimensione offline rispetto agli utenti regolari.

APS e caricamento lento

Se gli utenti che visitano una pagina creata come sito web su più pagine passano alla modalità offline e tentano di 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 nella 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 passano alla modalità 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 è passato alla modalità offline prima di scorrere. Tutti i contenuti caricati con il metodo lazy below the fold si interrompono in silenzio e non saranno più disponibili.

Poiché questi casi sono molto irritanti per gli utenti, ha senso monitorarli. I worker di servizio sono il luogo ideale per rilevare gli errori di rete e, eventualmente, monitorarli utilizzando gli strumenti di analisi. Con Workbox, è possibile configurare un gestore di gestione degli errori 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();

  }());
});

Invece di ascoltare tutte le richieste non riuscite, un altro modo è rilevare gli errori solo su percorsi specifici. Ad esempio, se vogliamo segnalare gli errori che si verificano solo nei percorsi che portano a /products/*, possiamo aggiungere un controllo in setCatchHandler che filtra l'URI con un'espressione regolare. Una soluzione più chiara è implementare registerRoute con un gestore personalizzato. In questo modo, la logica di business viene incapsulata in un percorso separato, con una migliore manutenibilità in 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 Analytics. Ancora una volta, assicurati di mettere in coda le richieste di analisi che si verificano offline all'interno del service worker. Come описано sopra, 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. 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 ha mostrato diversi modi per monitorare l'utilizzo offline, con i relativi vantaggi e svantaggi. Sebbene questo possa aiutarti a quantificare il numero di utenti che passano alla modalità offline e riscontrano problemi a causa di questo, si tratta solo di un inizio. Finché 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 di estendere le funzionalità offline in più iterazioni, tenendo d'occhio i numeri di monitoraggio. Inizia con una semplice pagina di errore offline, con Workbox è facilissimo, e deve essere considerata una best practice per l'esperienza utente simile alle pagine 404 personalizzate. Poi, passa gradualmente a soluzioni di riserva offline più avanzate e infine a contenuti offline reali. Assicurati di pubblicizzare e spiegare bene questa funzionalità agli utenti e vedrai aumentare l'utilizzo. Dopotutto, capita a tutti di disconnettersi di tanto in tanto.

Consulta Come generare report sulle metriche e creare una cultura del rendimento e Correggere la velocità del sito web in modo cross-funzionale per suggerimenti su come convincere gli stakeholder cross-funzionali a investire di più nel tuo sito web. Anche se questi post si concentrano sul rendimento, dovrebbero aiutarti a ottenere idee generali su come coinvolgere gli stakeholder.

Foto hero di JC Gellidon su Unsplash.