Pomiary wykorzystania offline

Dowiedz się, jak śledzić korzystanie z witryny w trybie offline, aby uzasadnić, dlaczego warto korzystać z niej w trybie offline.

Stephan Giesau

Martin Schierle

Z tego artykułu dowiesz się, jak śledzić korzystanie z witryny w trybie offline. W ten sposób dowiesz się, dlaczego warto korzystać z lepszego trybu offline witryny. Poznasz też pułapki i problemy, których należy unikać przy wdrażaniu analityki użytkowania offline.

Przyczyny pułapek zdarzeń online i offline w przeglądarce

Oczywistym rozwiązaniem do śledzenia użytkowania w trybie offline jest utworzenie detektorów zdarzeń online i offline (które obsługuje wiele przeglądarek) oraz umieszczenie w nich logiki śledzenia analityki. Takie podejście wiąże się jednak z kilkoma problemami i ograniczeniami:

• Ogólnie rzecz biorąc, śledzenie każdego zdarzenia stanu połączenia sieciowego może być nadmierne i odwrotne do zamierzone w świecie skupionym na prywatności, w którym należy zbierać jak najmniej danych. Dodatkowo zdarzenia online i offline mogą uruchamiać się na ułamek sekundy, której użytkownik prawdopodobnie nie zobaczy ani nie zauważy.
• Śledzenie aktywności offline nie dociera do serwera analitycznego, bo użytkownik jest offline.
• Śledzenie sygnatury czasowej, gdy użytkownik przełącza się w tryb offline, i wysyłanie aktywności offline do serwera analitycznego, kiedy użytkownik wróci do trybu online, zależy od tego, czy użytkownik ponownie odwiedzi Twoją witrynę. Jeśli użytkownik opuszcza witrynę z powodu braku trybu offline i nigdy nie wróci z niej ponownie, nie będzie można tego śledzić. Możliwość śledzenia porzuceń w trybie offline to kluczowe dane, które uzasadniają, dlaczego warto zoptymalizować witrynę w trybie offline.
• Zdarzenie online nie jest bardzo niezawodne, ponieważ zna tylko dostęp do sieci, a nie do internetu. W związku z tym użytkownik może być offline, a wysyłanie pingu śledzącego może się nie udać.
• Nawet wtedy, gdy użytkownik pozostaje na bieżącej stronie offline, żadne inne zdarzenia analityczne (np. zdarzenia przewijania, kliknięcia itp.) również nie są śledzone, co może okazać się bardziej trafne i przydatne.
• Działanie w trybie offline również nie jest zbyt istotne dla ogółu użytkowników. Jako programista witryn warto wiedzieć, jakiego rodzaju zasoby nie udało się wczytać. Jest to szczególnie istotne w przypadku aplikacji SPA, w których przerwa w połączeniu sieciowym może nie prowadzić do wyświetlenia strony błędu offline w przeglądarce (co rozumieją użytkownicy), ale z dużym prawdopodobieństwem dochodzi do cichych, losowych, dynamicznych części strony.

Możesz nadal korzystać z tego rozwiązania, aby poznać podstawowe informacje o korzystaniu z internetu w trybie offline, ale musisz dokładnie przeanalizować liczne wady i ograniczenia.

Lepsze podejście: mechanizm Service Worker

Rozwiązanie, które włącza tryb offline, okazuje się lepszym rozwiązaniem do śledzenia użytkowania offline. Podstawowym założeniem jest przechowywanie pingów analityki w IndexedDB, dopóki użytkownik jest offline, i wysyłanie ich ponownie, gdy użytkownik znowu połączy się z internetem. W przypadku Google Analytics jest to wstępnie dostępne w module Workbox, ale pamiętaj, że działania wysłane dłużej niż odłożone na 4 godziny mogą nie zostać przetworzone. W najprostszej formie można to aktywować w środowisku service worker opartym na Workbox za pomocą tych 2 wierszy:

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

googleAnalytics.initialize();

Spowoduje to śledzenie wszystkich zdarzeń i pingów odsłon w trybie offline, ale nie wiadomo, że miały miejsce offline (ponieważ są one ponownie odtwarzane w takiej postaci, w jakiej są). W tym celu możesz manipulować żądaniami śledzenia za pomocą Workbox, dodając do pingu analitycznego flagę offline za pomocą wymiaru niestandardowego (cd1 w poniższym kodzie przykładowym):

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

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

Co zrobić, jeśli użytkownik opuści stronę z powodu braku połączenia z internetem, zanim połączenie z internetem zostanie przywrócone? Mimo że zwykle powoduje to uśpienie skryptu service worker (ponieważ nie może wysłać danych po przywróceniu połączenia), moduł Workbox Google Analytics korzysta z interfejsu API synchronizacji w tle, który wysyła dane analityczne później, gdy połączenie zostanie przywrócone, nawet jeśli użytkownik zamknie kartę lub przeglądarkę.

Nadal ma jednak wadę: chociaż umożliwia to korzystanie z dotychczasowego śledzenia w trybie offline, to dopóki nie wdrożysz podstawowego trybu offline, najprawdopodobniej nie zobaczysz wielu istotnych danych. Jeśli połączenie zostanie przerwane, użytkownicy będą szybko opuszczali witrynę. Teraz jednak możesz to przynajmniej zmierzyć i określić, porównując średnią długość sesji i zaangażowanie użytkowników po zastosowaniu wymiaru offline z wynikami zwykłych użytkowników.

SPA i leniwe ładowanie

Jeśli użytkownicy odwiedzający stronę utworzoną jako witryna wielostronicowa przechodzą w tryb offline i próbują się poruszać, wyświetli się domyślna strona offline przeglądarki, co pomoże mu zrozumieć, co się dzieje. Jednak strony stworzone jako aplikacje jednostronicowe działają inaczej. Użytkownik pozostaje na tej samej stronie, a nowe treści są dynamicznie ładowane przez mechanizm AJAX bez konieczności przechodzenia w przeglądarce. Po przejściu do trybu offline użytkownicy nie widzą strony błędu przeglądarki. Zamiast tego dynamiczne części strony renderują się z błędami, przechodzą do stanu nieokreślonego lub przestają być dynamiczne.

Podobne efekty może wystąpić w witrynach wielostronicowych z powodu leniwego ładowania. Na przykład początkowe wczytanie nastąpiło online, ale użytkownik przeszedł w tryb offline przed przewijaniem. Wszystkie treści wczytywane metodą leniwego ładowania w części strony widocznej po przewinięciu będą dyskretne i nie będą widoczne.

Takie przypadki są naprawdę irytujące dla użytkowników, dlatego warto je śledzić. Skrypty service worker są idealnym miejscem do wychwytywania błędów sieci, a następnie śledzenia ich za pomocą analityki. W Workbox można skonfigurować globalny moduł obsługi przechwytywania, aby informować stronę o nieudanych żądaniach, wysyłając zdarzenie wiadomości:

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

  }());
});

Zamiast nasłuchiwać wszystkich nieudanych żądań, innym sposobem jest wychwytywanie błędów tylko na określonych trasach. Jeśli na przykład chcesz zgłosić błędy występujące tylko na trasach do: /products/*, możemy dodać w tabeli setCatchHandler kontrolę, która filtruje identyfikator URI za pomocą wyrażenia regularnego. Lepszym rozwiązaniem jest wdrożenie requestRoute za pomocą niestandardowego modułu obsługi. To sprawia, że logika biznesowa jest wyodrębniona, co ułatwia obsługę bardziej złożonych mechanizmów Service Worker:

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

Na ostatnim etapie strona musi nasłuchiwać zdarzenia message i wysłać ping analityczny. Pamiętaj też, aby buforować żądania analityczne, które są realizowane offline w skrypcie service worker. Jak opisano wcześniej, zainicjuj wtyczkę workbox-google-analytics, aby uzyskać wbudowaną obsługę Google Analytics.

Poniższy przykład korzysta z Google Analytics, ale można go też zastosować w ten sam sposób w przypadku innych dostawców narzędzi analitycznych.

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

Spowoduje to śledzenie nieudanych wczytań zasobów w Google Analytics, gdzie będzie można je przeanalizować za pomocą raportów. Obserwacje pochodne można wykorzystać do ulepszenia buforowania skryptu service worker i ogólnie obsługi błędów, aby zwiększyć niezawodność i niezawodność strony w niestabilnych warunkach sieciowych.

Dalsze kroki

W tym artykule przedstawiliśmy różne sposoby śledzenia użytkowania offline, a także ich zalety i wady. Te dane pozwalają oszacować, ilu użytkowników przełącza się na tryb offline i ma z tego powodu problemy, ale to dopiero początek. O ile Twoja witryna nie ma dobrze zaprojektowanego trybu offline, najprawdopodobniej nie będzie widoczny w statystykach offline.

Zalecamy, by włączyć pełne śledzenie, a następnie stopniowo rozszerzać możliwości offline, obserwując numery śledzenia. Zacznij od utworzenia prostej strony z komunikatem o błędzie offline – Workbox to proste do zrobienia – i tak należy traktować to jako sprawdzoną metodę UX podobną do niestandardowych stron 404. Następnie spójrz na bardziej zaawansowane opcje zastępcze offline, a na koniec na rzeczywiste treści offline. Pamiętaj, by dobrze je reklamować i wyjaśnić użytkownikom, a uzyskasz wzrost wykorzystania. W końcu wszyscy na jakiś czas przełączają się w tryb offline.

Zapoznaj się z artykułami Jak tworzyć raporty dotyczące danych i tworzyć kulturę skuteczności oraz Zwiększanie szybkości witryny z różnych funkcji, aby dowiedzieć się, jak przekonać osoby z różnych działów do zainwestowania większych środków w Twoją witrynę. Choć posty te skupiają się na skuteczności, powinny pomóc Ci zdobyć ogólne pomysły na temat angażowania zainteresowanych osób.

Zdjęcie główne: JC Gellidon, Unsplash.