Pomiar korzystania w trybie offline

Jak śledzić korzystanie z witryny w trybie offline, aby uzasadnić, dlaczego potrzebuje ona lepszych funkcji offline.

Stephan Giesau

Martin Schierle

Dowiedz się, jak śledzić korzystanie z witryny w trybie offline, aby uzasadnić, dlaczego potrzebuje ona lepszego trybu offline. Dowiedz się, jakich pułapek i problemów należy unikać podczas wdrażania analityki korzystania offline.

Pułapki zdarzeń przeglądarki online i offline

Oczywistym rozwiązaniem do śledzenia korzystania z aplikacji w trybie offline jest utworzenie odbiorników zdarzeń online i offline (które obsługuje wiele przeglądarek) i umieszczenie w nich logiki śledzenia analitycznego. Niestety to podejście ma kilka problemów i ograniczeń:

• Ogólnie rzecz biorąc, śledzenie każdego zdarzenia stanu połączenia sieciowego może być nadmierne i przynosić efekt przeciwny do zamierzonego w świecie, w którym priorytetem jest ochrona prywatności i w którym należy zbierać jak najmniej danych. Poza tym zdarzenia online i offline mogą być wywoływane nawet w przypadku krótkotrwałej utraty połączenia z siecią, która prawdopodobnie nie zostanie zauważona przez użytkownika.
• Śledzenie aktywności offline nie dociera do serwera analitycznego.
• Śledzenie lokalnie sygnatury czasowej, gdy użytkownik przechodzi w tryb offline, i wysyłanie aktywności offline na serwer analityczny, 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 pomogą Ci uzasadnić, dlaczego Twoja witryna potrzebuje lepszego trybu offline.
• Zdarzenie online nie jest zbyt wiarygodne, ponieważ informuje tylko o dostępie do sieci, a nie o dostępie do internetu. Użytkownik może więc nadal być offline, a wysłanie pinga śledzącego może się nie powieść.
• Nawet jeśli użytkownik pozostanie na bieżącej stronie w trybie offline, żadne inne zdarzenia analityczne (np. zdarzenia przewijania, kliknięcia itp.) nie będą śledzone, co może być bardziej istotne i przydatne.
• Samo bycie offline nie ma większego znaczenia. Najważniejsze jest prawdopodobnie to, które zasoby nie zostały wczytane. Jest to szczególnie istotne w przypadku aplikacji jednostronicowych (SPA), w których utrata połączenia z siecią może nie powodować wyświetlenia strony z błędem offline w przeglądarce, co jest zrozumiałe dla użytkowników. Zamiast tego prawdopodobnie powoduje to ciche błędy w przypadkowych, dynamicznych częściach strony.

Możesz nadal korzystać z tego rozwiązania, aby uzyskać podstawowe informacje o korzystaniu z aplikacji w trybie offline, ale musisz dokładnie rozważyć wiele wad i ograniczeń.

Lepsze podejście: skrypt service worker

Rozwiązanie, które umożliwia tryb offline, jest też lepsze do śledzenia korzystania z aplikacji w trybie offline. Pingi analityczne możesz przechowywać w IndexedDB, dopóki użytkownik jest offline, i ponownie wysyłać je, gdy użytkownik wróci do trybu online. W przypadku Google Analytics jest to już dostępne w module Workbox, ale pamiętaj, że żądania wysłane z ponad 4-godzinnym opóźnieniem mogą nie zostać przetworzone.

W najprostszej postaci można ją aktywować w usłudze opartej na Workboxie za pomocą tych 2 wierszy:

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

googleAnalytics.initialize();

Śledzi wszystkie istniejące zdarzenia i pingi odsłon stron w trybie offline, ale nie będziesz wiedzieć, że miały miejsce w trybie offline, ponieważ są odtwarzane w takiej postaci, w jakiej zostały zarejestrowane. Możesz manipulować żądaniami śledzenia za pomocą Workbox, dodając do pinga Analytics flagę offline 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ę z powodu braku połączenia z internetem, zanim to połączenie zostanie przywrócone? Zwykle powoduje to przejście skryptu service worker w stan uśpienia, ponieważ nie może on wysyłać danych po przywróceniu połączenia. Moduł Workbox Google Analytics korzysta jednak z interfejsu Background Sync API. Synchronizacja w tle wysyła dane analityczne, gdy połączenie zostanie przywrócone, nawet jeśli użytkownik zamknie kartę lub przeglądarkę.

Ma to jednak wadę: chociaż dzięki temu dotychczasowe śledzenie będzie działać w trybie offline, prawdopodobnie nie zobaczysz wielu istotnych danych, dopóki nie wdrożysz podstawowego trybu offline. Gdy połączenie zostanie przerwane, użytkownicy nadal będą szybko opuszczać Twoją witrynę. Teraz możesz przynajmniej zmierzyć i określić ilościowo to zjawisko, porównując średnią długość sesji i zaangażowanie użytkowników, do których zastosowano wymiar offline, z regularnymi użytkownikami.

Aplikacje SPA 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ć, pojawi 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ą protokołu AJAX bez nawigacji 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 niezdefiniowane stany lub po prostu przestają być dynamiczne.

Podobne efekty mogą wystąpić w witrynach wielostronicowych z powodu leniwego ładowania. Na przykład pierwsze wczytanie mogło nastąpić online, ale użytkownik przeszedł w tryb offline, zanim zaczął przewijać stronę. Cała zawartość wczytywana z opóźnieniem w części strony widocznej po przewinięciu nie zostanie wczytana i będzie jej brakować.

Takie sytuacje są bardzo irytujące dla użytkowników, dlatego warto je śledzić. Service worker to idealne miejsce do wykrywania błędów sieci i śledzenia ich za pomocą analiz. W Workbox można skonfigurować globalny moduł obsługi błędów, który będzie informować stronę o nieudanych żądaniach przez wysyłanie zdarzenia 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 na trasach do /products/*, możemy dodać w setCatchHandler sprawdzenie, które filtruje identyfikator URI za pomocą wyrażenia regularnego.

Prostszym rozwiązaniem jest wdrożenie registerRoute za pomocą niestandardowego modułu obsługi. Dzięki temu logika biznesowa jest umieszczana w osobnej ścieżce, 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();
    }
  }
);

Na koniec strona musi nasłuchiwać zdarzenia message i wysyłać ping do Analytics. Pamiętaj, aby buforować żądania analityczne, które występują w trybie offline w ramach skryptu service worker. Zgodnie z opisem powyżej zainicjuj wtyczkę workbox-google-analytics, aby włączyć wbudowaną obsługę Google Analytics.

Poniższy przykład dotyczy Google Analytics, ale można go w ten sam sposób 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
      });
    }
  });
}

Będzie to śledzić nieudane wczytania zasobów w Google Analytics, gdzie można je analizować za pomocą raportów. Uzyskane w ten sposób informacje mogą być wykorzystywane do ulepszania buforowania skryptów service worker i ogólnej obsługi błędów, aby zwiększyć niezawodność strony w niestabilnych warunkach sieciowych.

Dalsze kroki

Poznaliśmy różne sposoby śledzenia użytkowania offline oraz ich zalety i wady. Może to pomóc w określeniu, ilu użytkowników przechodzi w tryb offline i ma z tego powodu problemy, ale to dopiero początek. Jeśli Twoja witryna nie oferuje dobrze działającego trybu offline, w statystykach nie zobaczysz zbyt wielu danych o korzystaniu z niej w trybie offline.

Zalecamy najpierw wdrożyć pełne śledzenie, a potem stopniowo rozszerzać możliwości offline, koncentrując się na śledzeniu. Zacznij od strony błędu offline. Można ją łatwo utworzyć za pomocą Workbox. Jest to sprawdzona metoda w zakresie UX, podobnie jak niestandardowe strony 404. Następnie przejdź do bardziej zaawansowanych wersji offline, a na końcu do prawdziwych treści offline. Pamiętaj, aby dobrze reklamować i wyjaśniać użytkownikom tę funkcję. Wtedy zobaczysz, jak rośnie jej popularność. W końcu każdy od czasu do czasu jest offline.

Przeczytaj artykuły Jak raportować dane i budować kulturę wydajności i Poprawa szybkości witryny w różnych działach, aby poznać wskazówki dotyczące przekonywania osób z różnych działów do większych inwestycji w Twoją witrynę. Chociaż te posty koncentrują się na skuteczności, powinny pomóc Ci w zdobyciu ogólnych pomysłów na zaangażowanie zainteresowanych osób.