Pomiar korzystania w trybie offline

Jak śledzić korzystanie z witryny offline, aby móc uzasadnić, dlaczego witryna potrzebuje lepszego działania offline.

Stephan Giesau

Martin Schierle

Dowiedz się, jak śledzić korzystanie z witryny offline, aby móc uzasadnić, dlaczego Twoja witryna potrzebuje lepszego trybu offline. Dowiedz się, jakich pułapek i problemów unikać podczas wdrażania statystyk korzystania offline.

Pułapki związane ze zdarzeniami online i offline w przeglądarce

Oczywistym rozwiązaniem do śledzenia korzystania z aplikacji offline jest utworzenie detektorów zdarzeń dla zdarzeń online i offline (które obsługuje wiele przeglądarek) i umieszczenie w nich logiki śledzenia analitycznego. Niestety takie podejście wiąże się z kilkoma problemami i ograniczeniami:

• Ogólnie śledzenie każdego zdarzenia stanu połączenia sieciowego może być nadmierne i nieproduktywne w świecie, w którym prywatność jest najważniejsza i należy zbierać jak najmniej danych. Poza tym zdarzenia online i offline mogą zostać wywołane nawet przy chwilowej utracie połączenia z siecią, której użytkownik prawdopodobnie nawet nie zauważy.
• Śledzenie aktywności offline przez Analytics nie dociera do serwera Analytics.
• Śledzenie sygnatury czasowej lokalnie, gdy użytkownik przechodzi w tryb offline, i wysyłanie aktywności offline do serwera Analytics, gdy użytkownik wraca do trybu online, zależy od tego, czy użytkownik ponownie odwiedzi Twoją witrynę. 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 zdarzenia. Możliwość śledzenia rezygnacji offline to kluczowe dane, które pozwalają uzasadnić, dlaczego Twoja witryna potrzebuje lepszego trybu offline.
• Zdarzenie online nie jest zbyt wiarygodne, ponieważ zawiera tylko informacje o dostępie do sieci, a nie o dostępie do internetu. Użytkownik może więc nadal być offline, a wysłanie pingu śledzącego może się nie powieść.
• Nawet jeśli użytkownik pozostaje na bieżącej stronie, będąc offline, nie są śledzone żadne inne zdarzenia Analytics (np. zdarzenia przewijania, kliknięcia itp.), które mogą być bardziej istotne i przydatne.
• Samo przejście w tryb offline nie jest zbyt istotne. Najważniejsze jest, aby wiedzieć, które zasoby nie zostały wczytane. Jest to szczególnie istotne w przypadku aplikacji jednostronicowych (SPA), w których utrata połączenia sieciowego może nie prowadzić do wyświetlenia strony błędu przeglądarki w trybie offline, którą użytkownicy rozumieją. Zamiast tego prawdopodobnie spowoduje to, że losowe, dynamiczne części strony będą się niepostrzeżenie psuć.

Nadal możesz używać tego rozwiązania, aby uzyskać podstawowe informacje o korzystaniu z aplikacji offline, ale musisz dokładnie rozważyć liczne wady i ograniczenia.

Lepsze podejście: skrypt service worker

Rozwiązanie, które umożliwia korzystanie z trybu offline, jest też lepszym rozwiązaniem do śledzenia korzystania z trybu offline. Możesz przechowywać pingi analityczne w IndexedDB, gdy użytkownik jest offline, i wysyłać je ponownie, gdy użytkownik znów będzie online. W przypadku Google Analytics jest to już dostępne w module Workbox, ale pamiętaj, że działania wysłane z opóźnieniem przekraczającym 4 godziny mogą nie zostać przetworzone.

W najprostszej postaci można go aktywować w skrypcie service worker opartym na Workbox za pomocą tych 2 linii:

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

googleAnalytics.initialize();

Śledzi to wszystkie istniejące zdarzenia i pingi odsłon, gdy użytkownik jest offline, ale nie będziesz wiedzieć, że miały miejsce offline, ponieważ są odtwarzane w niezmienionej postaci. Możesz manipulować żądaniami śledzenia za pomocą Workbox, dodając flagę offline do pingu Analytics za pomocą wymiaru niestandardowego:

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

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

Co się stanie, jeśli użytkownik opuści stronę, ponieważ jest offline, zanim połączenie z internetem zostanie przywrócone? Zwykle powoduje to uśpienie skryptu service worker, ponieważ nie może on wysłać danych, gdy połączenie zostanie przywrócone. Moduł Google Analytics Workbox korzysta jednak z interfejsu Background Sync API. Synchronizacja w tle wysyła dane analityczne po przywróceniu połączenia, nawet jeśli użytkownik zamknie kartę lub przeglądarkę.

Jest jednak pewien minus: chociaż dzięki temu istniejące śledzenie będzie działać offline, prawdopodobnie nie zobaczysz wielu istotnych danych, dopóki nie wdrożysz podstawowego trybu offline. Użytkownicy nadal szybko opuszczaliby Twoją witrynę, gdyby połączenie zostało przerwane. Teraz możesz jednak przynajmniej zmierzyć i określić ilościowo ten wpływ, porównując średnią długość sesji i zaangażowanie użytkowników, którzy korzystają z wymiaru offline, z danymi dotyczącymi zwykłych użytkowników.

Aplikacje jednostronicowe i leniwe ładowanie

Jeśli użytkownicy odwiedzający stronę utworzoną jako witryna wielostronicowa przejdą w tryb offline i spróbują się po niej poruszać, wyświetli się domyślna strona przeglądarki w trybie offline, która pomoże im zrozumieć, co się dzieje. Jednak strony utworzone jako aplikacje jednostronicowe działają inaczej. Użytkownik pozostaje na tej samej stronie, a nowe treści są wczytywane dynamicznie za pomocą protokołu AJAX bez konieczności nawigacji w przeglądarce. Użytkownicy nie widzą strony błędu przeglądarki, gdy przechodzą w tryb offline. Zamiast tego dynamiczne części strony renderują się z błędami, przechodzą w niezdefiniowane stany lub po prostu przestają być dynamiczne.

Podobne efekty mogą wystąpić w witrynach wielostronicowych z powodu leniwego ładowania. Na przykład początkowe wczytanie mogło nastąpić online, ale użytkownik przeszedł do trybu offline przed przewinięciem. Wszystkie treści ładowane leniwie poniżej linii przewijania nie zostaną załadowane i będą niewidoczne.

Takie przypadki są bardzo irytujące dla użytkowników, dlatego warto je śledzić. Skrypty service worker to idealne miejsce do wychwytywania błędów sieci i śledzenia ich za pomocą statystyk. W Workbox można skonfigurować globalny moduł obsługi błędów, 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ż przechwytywać 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ć w setCatchHandler test, który filtruje identyfikator URI za pomocą wyrażenia regularnego.

Lepszym rozwiązaniem jest wdrożenie registerRoute z niestandardowym modułem obsługi. Dzięki temu logika biznesowa jest zamknięta w osobnej trasie, co ułatwia utrzymanie bardziej złożonych skryptó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();
    }
  }
);

Ostatnim krokiem jest nasłuchiwanie zdarzenia message i wysyłanie pinga analitycznego. Pamiętaj, aby buforować żądania analityczne, które występują offline, w skrypcie service worker. Jak opisano wcześniej, zainicjuj wtyczkę workbox-google-analytics, aby korzystać z wbudowanej obsługi Google Analytics.

W poniższym przykładzie używamy Google Analytics, ale możesz postępować tak samo 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 nieudane wczytywanie zasobów będzie śledzone w Google Analytics, gdzie można je analizować za pomocą raportów. Uzyskane informacje można wykorzystać do ulepszenia buforowania skryptu service worker i ogólnej obsługi błędów, aby zwiększyć stabilność i niezawodność strony w niestabilnych warunkach sieciowych.

Dalsze kroki

Poznaliśmy różne sposoby śledzenia wykorzystania offline oraz ich zalety i wady. Chociaż może to pomóc w określeniu, ilu użytkowników przechodzi w tryb offline i ma z tego powodu problemy, to dopiero początek. Jeśli Twoja witryna nie oferuje dobrze zbudowanego trybu offline, oczywiście nie zobaczysz w statystykach zbyt wielu przypadków korzystania z niej offline.

Zalecamy skonfigurowanie pełnego śledzenia, a następnie stopniowe rozszerzanie możliwości offline, ze szczególnym uwzględnieniem śledzenia. Zacznij od strony błędu offline. Można ją łatwo utworzyć za pomocą Workbox. Jest to sprawdzona metoda zwiększająca wygodę użytkowników, podobna do niestandardowych stron 404. Następnie przejdź do bardziej zaawansowanych rozwiązań zastępczych offline, a na koniec do prawdziwych treści offline. Zadbaj o to, aby dobrze to zareklamować i wyjaśnić użytkownikom, a zobaczysz, że będą coraz częściej korzystać z tej funkcji. W końcu każdy od czasu do czasu jest offline.

Wskazówki, jak przekonać interesariuszy z różnych działów do zainwestowania w Twoją witrynę, znajdziesz w artykułach How to report metrics and build a performance culture (Jak raportować dane i budować kulturę skuteczności) i Fixing website speed cross-functionally (Zwiększanie szybkości witryny w różnych działach). Chociaż te posty skupiają się na skuteczności, powinny pomóc Ci uzyskać ogólne wyobrażenie o tym, jak zaangażować zainteresowane osoby.