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 meglio il motivo per cui il tuo sito sito richiede una modalità offline migliore. Spiega inoltre gli inconvenienti e i problemi da evitare durante l'implementazione e analisi sull'utilizzo offline.

Insidie degli eventi del browser online e offline

La soluzione più ovvia per il monitoraggio dell'uso offline è creare listener di eventi per il parametro online e offline eventi (che supportato da molti browser) e di inserire i dati di monitoraggio la logica di questi ascoltatori. Purtroppo, questo presenta diversi problemi e limitazioni dell'IA:

• In generale, il monitoraggio di ogni evento relativo allo stato della connessione di rete può essere eccessivo ed è controproduttivo in un mondo incentrato sulla privacy in cui il minor numero di dati possibile raccolte. Inoltre, gli eventi online e offline possono attivarsi solo per una frazione di secondo di una perdita di rete, che probabilmente un utente non potrebbe neanche 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 invia l'attività offline a il server di analisi dei dati quando l'utente torna online dipende dall'utente che visita di nuovo il sito. Se l'utente abbandona il sito per l'assenza della modalità offline e non visita più la pagina, significa non c'è modo di monitorarlo. La capacità di tenere traccia degli abbandoni offline è un dato fondamentale per creare un caso sul motivo per cui il tuo sito ha bisogno di una modalità offline migliore.
• L'evento online non è molto affidabile perché consiste solo dell'accesso alla rete, senza accesso a internet. Pertanto, un utente potrebbe essere ancora offline e l'invio del ping di monitoraggio può continuano a non funzionare.
• Anche se l'utente rimane offline sulla pagina corrente, nessuno degli altri di dati e analisi (ad es. eventi di scorrimento, clic e così via), il che potrebbe essere maggiore informazioni utili e pertinenti.
• Anche il fatto di essere offline di per sé non è molto significativo in generale. In qualità di sviluppatore di siti web, è più importante sapere quali tipi di risorse non sono state caricate. Ciò è particolarmente pertinente nel contesto delle APS, dove un'interruzione della connessione di rete potrebbe non portare alla modalità offline del browser pagina di errore (compresa dagli utenti), ma è più probabile che si verifichino errori in parti dinamiche casuali della pagina in silenzio.

Puoi comunque usare questa soluzione per acquisire una conoscenza di base dell'utilizzo offline, ma molti gli svantaggi e i limiti devono essere considerati con attenzione.

Un approccio migliore: il service worker

La soluzione che abilita la modalità offline si rivela la migliore per il monitoraggio offline all'utilizzo delle risorse. L'idea di base è archiviare i ping di analisi in IndexedDB finché l'utente è offline, e le invia di nuovo quando l'utente sarà di nuovo online. Per Google Analytics è già disponibile disponibile tramite un modulo Workbox, ma ricorda che gli hit hanno inviato più di di quattro ore differite potrebbero non essere elaborati. Nella sua forma più semplice, può essere attivato all'interno di un servizio basato su Workbox worker con queste due righe:

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

googleAnalytics.initialize();

Questa opzione monitora tutti gli eventi e i ping di visualizzazione di pagina esistenti quando sei offline, ma non sai che che si sono verificati offline (poiché vengono riprodotti così come sono). Per questo puoi manipolare le richieste di monitoraggio con Workbox aggiungendo un flag offline al ping di Analytics, utilizzando una dimensione personalizzata (cd1 nel codice esempio 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 stabilita una connessione a internet indietro? Anche se normalmente questa operazione attiva la modalità di sospensione del service worker (perché non è in grado di inviare i dati quando viene ripristinata la connessione), il modulo Google Analytics Workbox utilizza la funzionalità Sincronizzazione in background API, che invia dati e analisi i dati in un secondo momento, quando viene ripristinata la connessione, anche se l'utente chiude la scheda o il browser.

Esiste ancora uno svantaggio: sebbene ciò renda possibile il monitoraggio offline esistente, è probabile che non riceveremo molti dati pertinenti finché non implementi una modalità offline di base. Gli utenti continueranno a abbandonino il tuo sito rapidamente quando si interrompe la connessione. Ma ora puoi almeno misurare e e quantificarlo confrontando la durata media della sessione e il coinvolgimento degli utenti con quello offline dimensione applicata rispetto agli 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, il browser viene visualizzata una pagina offline predefinita, aiutando gli utenti a capire cosa sta succedendo. Tuttavia, le pagine create come le applicazioni a pagina singola funzionano in modo diverso. L'utente rimane sulla stessa pagina e i nuovi contenuti vengono vengono caricati in modo dinamico tramite AJAX senza bisogno di alcuna navigazione tramite browser. Gli utenti non vedono l'errore del browser quando sei offline. Le parti dinamiche della pagina vengono invece visualizzate con errori, o non sono più dinamici.

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 si arresta in modo invisibile e non verrà più visualizzato.

Poiché questi casi sono davvero irritanti per gli utenti, ha senso monitorarli. I Service worker sono il punto ideale per individuare gli errori di rete e, infine, monitorarli con l'analisi. Con Workbox, gestore del fermo a livello globale può essere configurato in modo da 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é ascoltare tutte le richieste non riuscite, un altro modo è rilevare gli errori su route specifiche . Ad esempio, se vogliamo segnalare gli errori che si verificano solo sulle route verso /products/*, possiamo aggiungi 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 include la logica di business in una route separata, con una migliore manutenibilità per i 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 in precedenza, inizializza il plug-in workbox-google-analytics per la versione integrata di Google Analytics assistenza in tempo reale.

Il seguente esempio utilizza Google Analytics, ma può essere applicato allo stesso modo per altre analisi di Google Cloud.

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

Ciò consente di tenere traccia dei caricamenti di risorse non riusciti in Google Analytics, dove possono essere analizzati report. L'insight derivato può essere utilizzata per migliorare la memorizzazione nella cache e la gestione degli errori dei service worker in generale, per 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. Sebbene ciò possa aiutare a quantificare quanti dei tuoi utenti passano alla modalità offline e riscontrano problemi a causa di ciò, è solo l'inizio. Se il tuo sito web non offre una modalità offline ben costruita, ovviamente non vedrai molto l'utilizzo offline in Analytics.

Ti consigliamo di implementare il monitoraggio completo e poi estendere le funzionalità offline in iterazioni con un occhio ai numeri di riferimento. Inizia con una semplice pagina di errore offline con Casella di lavoro per cui è banale cosa fare dovrebbe essere comunque considerata una best practice per l'esperienza utente simile alle pagine 404 personalizzate. Lavora a modo tuo verso fallback offline più avanzati e infine verso contenuti offline reali. Assicurati di fare pubblicità e di spiegarlo agli utenti. e 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. per convincere stakeholder interfunzionali a investire di più nel proprio sito web. Anche se questi post sono incentrati sul rendimento, dovrebbero aiutarti a trovare un'idea generale su come interagire le parti interessate.

Foto hero di JC Gellidon su Unsplash.