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 korzystania z aplikacji 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 lokalnie, gdy użytkownik jest 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 wróci do Twojej witryny. Jeśli użytkownik opuści Twoją witrynę z powodu braku trybu offline i nigdy do niej nie wróci, nie będziesz mieć możliwości śledzenia tego faktu. Możliwość śledzenia rezygnacji z korzystania z aplikacji offline jest kluczowym źródłem danych do tworzenia uzasadnienia, dlaczego Twoja witryna potrzebuje lepszego trybu offline.
• Zdarzenie online nie jest zbyt niezawodne, ponieważ wie tylko o dostępie do sieci, a nie o dostępie 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 doprowadzi do bezgłośnego 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: usługa w tle

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 Google Analytics jest to już dostępne z wykorzystaniem gotowego modułu 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ą Workboxa, dodając do pinga Analytics flagę offline za pomocą wymiaru niestandardowego (cd1 w przykładowym kodzie poniżej):

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

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

Co się stanie, jeśli użytkownik opuści stronę, ponieważ jest offline, 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. Strony utworzone jako aplikacje jednostronicowe działają jednak 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ń, możesz też wykrywać błędy 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();
    }
  }
);

W ostatnim kroku strona musi nasłuchiwać zdarzenia message i wysyłać ping do Analytics. Ponownie pamiętaj, aby buforować żądania funkcji Analytics, 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.

W tym przykładzie używamy Google Analytics, ale ten sam sposób można zastosować w przypadku innych dostawców usług 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. Pomaga to określić, ilu użytkowników zostaje offline i z jakich powodów, ale to dopiero początek. Dopóki Twoja witryna nie będzie oferować dobrze skonstruowanego trybu offline, nie zobaczysz w statystykach wielu przypadków korzystania z tego trybu.

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 połączenie z internetem.

Sprawdź artykuły Jak raportować dane i budować kulturę skuteczności oraz Jak poprawić szybkość witryny w ujęciu przekrojowym, aby uzyskać wskazówki dotyczące przekonywania interesariuszy do zwiększenia inwestycji w witrynę. Chociaż te posty koncentrują się na skuteczności, powinny pomóc Ci w ogólnych pomysłach na to, jak zaangażować interesariuszy.

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