Pomiary wykorzystania offline

Jak śledzić korzystanie z witryny offline, aby uzasadnić, dlaczego warto ją ulepszyć w trybie offline.

Stephan Giesau

Martin Schierle

Z tego artykułu dowiesz się, jak śledzić korzystanie z Twojej witryny offline, aby uzasadnić, dlaczego potrzebujesz lepszego trybu offline. Wyjaśniamy też, jakich pułapek i problemów należy unikać podczas wdrażania analityki offline.

Wpadki związane ze zdarzeniami online i offline w przeglądarce

Oczywiste rozwiązanie polega na utworzeniu odbiorników zdarzeń online i offline (które są obsługiwane przez wiele przeglądarek) oraz umieszczeniu w nich logiki śledzenia analityki. Niestety ta metoda ma kilka problemów i ograniczeń:

• Ogólnie śledzenie każdego zdarzenia stanu połączenia z siecią może być niepotrzebne i nie przynosić oczekiwanych rezultatów w świecie, w którym kładzie się nacisk na ochronę prywatności i gdzie należy zbierać jak najmniej danych. Dodatkowo zdarzenia online i offline mogą być wywoływane przez utratę połączenia z siecią trwającą ułamek sekundy, której użytkownik prawdopodobnie nie zauważy.
• Śledzenie aktywności offline przez Analytics nigdy nie dotrze do serwera Analytics, ponieważ użytkownik jest… offline.
• Śledzenie sygnatury czasowej na poziomie lokalnym, gdy użytkownik przejdzie w tryb offline, i przesyłanie aktywności offline na serwer analityki, gdy użytkownik wróci do trybu online, zależy od tego, czy użytkownik powróci do Twojej witryny. Jeśli użytkownik opuszcza Twoją witrynę z powodu braku trybu offline i nigdy nie wróci z niej ponownie, nie będzie można tego śledzić. Możliwość śledzenia rezygnacji z korzystania z witryny offline jest kluczowym źródłem danych do tworzenia uzasadnienia, dlaczego Twoja witryna potrzebuje lepszego trybu offline.
• Zdarzenie online nie jest bardzo niezawodne, ponieważ zna tylko dostęp do sieci, a nie do internetu. Użytkownik może być nadal offline, więc wysyłanie pingowania śledzenia może się nie udać.
• Nawet jeśli użytkownik pozostaje na bieżącej stronie w trybie offline, nie są śledzone żadne inne zdarzenia analityczne (np. zdarzenia przewijania, kliknięcia itp.), które mogłyby być bardziej przydatne i trafne.
• Samo wyłączenie internetu nie ma też większego znaczenia. Jako deweloper witryny możesz być bardziej zainteresowany tym, jakie zasoby nie zostały wczytane. Jest to szczególnie ważne w kontekście aplikacji SPA, w których przypadku utrata połączenia z internetem może nie spowodować wyświetlenia użytkownikowi strony błędu (co jest zrozumiałe), ale raczej cichego niepowodzenia losowych dynamicznych części strony.

Nadal możesz używać tego rozwiązania, aby uzyskać podstawowe informacje o używaniu offline, ale musisz wziąć pod uwagę wiele wad i ograniczeń.

Lepsze podejście: skrypt service worker

Rozwiązanie, które umożliwia korzystanie z trybu offline, okazuje się lepszym rozwiązaniem do śledzenia korzystania z usługi offline. Zasada jest taka, że pingi analityczne są przechowywane w IndexedDB, dopóki użytkownik jest offline, a gdy wróci do sieci, są ponownie wysyłane. W przypadku Google Analytics ta funkcja jest już dostępna w ramach gotowego rozwiązania w module Workbox, ale pamiętaj, że działania wysyłane z opóźnieniem dłuższym niż 4 godziny mogą nie zostać przetworzone. W najprostszej formie można go aktywować w ramach usługi dla pracowników w Workbox za pomocą tych dwóch wierszy:

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

googleAnalytics.initialize();

W trybie offline rejestruje wszystkie dotychczasowe zdarzenia i pingi odsłon, ale nie będziesz wiedzieć, że miały one miejsce offline (są one tylko odtwarzane w takim stanie, w jakim były). 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 przejście do trybu uśpienia usługi (ponieważ nie może ona wysył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 zostanie przywrócone połączenie, nawet jeśli użytkownik zamknie kartę lub przeglądarkę.

Jest jednak pewien minus: chociaż dzięki temu obecne śledzenie będzie działać w trybie offline, prawdopodobnie nie będziesz otrzymywać zbyt wielu odpowiednich danych, dopóki nie wdrożysz podstawowego trybu offline. Użytkownicy i tak szybko opuszczają Twoją witrynę, gdy połączenie zostanie zerwane. Teraz możesz jednak mierzyć i określać to w liczbowej postaci, porównując średnią długość sesji i zaangażowanie użytkowników z zaimplementowanym wymiarem offline z zaangażowaniem zwykłych użytkowników.

Aplikacje SPA i leniwe ładowanie

Jeśli użytkownicy odwiedzający stronę utworzoną jako witryna wielostronicowa przełączą się w tryb offline i spróbują się poruszać po stronie, wyświetli się domyślna strona offline przeglądarki, która pomoże im 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ą wczytywane dynamicznie za pomocą AJAX bez konieczności nawigowania w przeglądarce. Użytkownicy nie widzą strony błędu przeglądarki, gdy przechodzą w tryb offline. Zamiast tego dynamiczne części strony są renderowane z błędami, przechodzą w nieokreślone stany lub przestają być dynamiczne.

Podobne efekty mogą występować w witrynach wielostronicowych z powodu leniwego ładowania. Na przykład początkowe wczytanie mogło nastąpić online, ale użytkownik przeszedł w tryb offline, zanim przewinął stronę. Wszystkie treści ładowane z opóźnieniem poniżej widocznego obszaru będą pobierane bez potwierdzenia i nie będą widoczne.

Takie przypadki są bardzo irytujące dla użytkowników, dlatego warto je śledzić. Service worker to idealne miejsce do wykrywania błędów sieci i ich śledzenia za pomocą funkcji analitycznej. W Workbox możesz skonfigurować globalny handler, który będzie 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 chcemy zgłaszać błędy występujące tylko na trasach do /products/*, możemy dodać do funkcji setCatchHandler sprawdzenie, które odfiltrowuje identyfikator URI za pomocą wyrażenia regularnego. Lepszym rozwiązaniem jest implementacja registerRoute z niestandardowym modułem obsługi. Umożliwia to umieszczenie logiki biznesowej w oddzielnej ścieżce, co ułatwia utrzymanie bardziej złożonych usług:

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 koniec strona musi nasłuchiwać zdarzenia message i wysyłać ping do Analytics. Pamiętaj, aby buforować żądania funkcji analitycznych, które występują offline w ramach usługi workera. Jak opisano wcześniej, zainicjuj wtyczkę workbox-google-analytics, aby korzystać z wbudowanej obsługi 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
      });
    }
  });
}

Dzięki temu w Google Analytics będzie można śledzić nieudane wczytania zasobów, które można analizować za pomocą raportów. Uzyskanych informacji można używać do ogólnego ulepszania buforowania i obsługi błędów przez skrypt service worker, aby strona była bardziej stabilna i niezawodna w niestabilnych warunkach sieciowych.

Dalsze kroki

Z tego artykułu dowiesz się, jak śledzić korzystanie z usługi offline, a także jakie są zalety i wady poszczególnych metod. Możesz dzięki temu określić, ilu użytkowników korzysta z Twojej aplikacji offline i z jakimi problemami się borykają, ale to dopiero początek. O ile Twoja witryna nie ma dobrze zaprojektowanego trybu offline, najprawdopodobniej nie będzie widoczny w statystykach offline.

Zalecamy wdrożenie pełnego śledzenia, a potem rozszerzenie możliwości offline w kolejnych iteracjach z uwzględnieniem liczby śledzenia. Najpierw zacznij od prostej strony błędu offline. Dzięki Workbox możesz to zrobić bez problemu. Poza tym jest to sprawdzona metoda w zakresie UX, podobna do niestandardowych stron błędu 404. Następnie przejdź do bardziej zaawansowanych alternatyw offline, a na końcu do prawdziwych treści offline. Dobrze reklamuj i wyjaśniaj użytkownikom tę funkcję, a będziesz obserwować wzrost jej wykorzystania. W końcu każdy od czasu do czasu traci łączność z internetem.

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 w nich skupiają się na skuteczności, powinny pomóc Ci zdobyć ogólne informacje o tym, jak budować zaangażowanie zainteresowanych osób.

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