Ta strona została przetłumaczona przez Cloud Translation API.

Pomiary wykorzystania offline

jak śledzić korzystanie z witryny offline, aby uzasadnić, dlaczego powinniśmy ulepszyć działanie witryny w trybie offline.

Stephan Giesau

Martin Schierle

Z tego artykułu dowiesz się, jak śledzić korzystanie z witryny w trybie offline, aby dowiedzieć się, dlaczego warto włączyć w witrynie lepszy tryb offline. Omówiono w nim również problemy i problemy, których należy unikać przy wdrażaniu analityki wykorzystania offline.

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

Oczywistym rozwiązaniem do śledzenia wykorzystania offline jest utworzenie detektorów zdarzeń online i offline (które obsługuje wiele przeglądarek) oraz umieszczenie logiki śledzenia w tych detektorach. Niestety wiąże się to z kilkoma problemami i ograniczeniami:

Ogólnie śledzenie każdego zdarzenia stanu połączenia sieciowego może być przesadne i skuteczne w przypadku skupienia się na ochronie prywatności, w którym należy gromadzić jak najmniej danych. Dodatkowo zdarzenia online i offline mogą być uruchamiane tylko na ułamek sekundy utraty połączenia z siecią, czego użytkownik prawdopodobnie nawet nie zauważy.
Statystyki śledzenia aktywności offline nigdy nie dotarłyby na serwer analiz, ponieważ użytkownik byłby... offline.
Śledzenie sygnatury czasowej lokalnie, gdy użytkownik przechodzi w tryb offline, i wysyłania aktywności offline do serwera analitycznego, gdy wróci on do trybu online, zależy od tego, czy użytkownik ponownie odwiedza Twoją witrynę. Jeśli użytkownik opuszcza witrynę z powodu braku trybu offline i nigdy nie do niej powraca, nie możesz tego śledzić. Możliwość śledzenia użytkowników, którzy porzucili ścieżkę offline, jest kluczowym elementem w opracowywaniu uzasadnienia, dla którego witryna potrzebuje lepszego trybu offline.
Zdarzenie online nie jest bardzo niezawodne, ponieważ wie tylko o dostępie do sieci, a nie do internetu. W związku z tym użytkownik może być wciąż offline, a wysłanie pingu śledzenia może się nadal zakończyć niepowodzeniem.
Nawet jeśli użytkownik pozostaje na bieżącej stronie w trybie offline, nie są też śledzone żadne inne zdarzenia analityczne (np. przewinięcie strony, kliknięcia itp.), co może być bardziej trafne i przydatne.
Sama obecność w sieci również nie jest zbyt dobra. Jako programista witryny może być ważne, by wiedzieć, jakiego typu zasoby się nie wczytały. Jest to szczególnie istotne w kontekście aplikacji SPA, gdzie utrata połączenia sieciowego może nie spowodować wyświetlenia strony błędu przeglądarki offline w przeglądarce (co jest zrozumiałe dla użytkowników), ale bardziej prawdopodobne jest, że losowe dynamiczne części strony przestaną działać bez dźwięku.

W dalszym ciągu możesz korzystać z tego rozwiązania, aby poznać podstawowe informacje o korzystaniu z trybu offline, ale musisz dokładnie wziąć pod uwagę wiele wad i ograniczeń.

Lepsze podejście: skrypt service worker

Rozwiązaniem, które włącza tryb offline, okazuje się lepszym rozwiązaniem do śledzenia wykorzystania offline. Podstawowym założeniem jest przechowywanie pingów analitycznych w IndexedDB, gdy użytkownik jest offline, i ponowne ich wysyłanie, gdy użytkownik ponownie połączy się z internetem. W przypadku Google Analytics funkcje te są już dostępne w ramach modułu Workbox. Pamiętaj jednak, że działania wysłane ponad cztery godziny odroczone mogą nie być przetwarzane. W najprostszej formie można go aktywować w module service worker oparty na Workbox za pomocą tych 2 wierszy:

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

googleAnalytics.initialize();

Śledzi wszystkie istniejące zdarzenia i pingi odsłon w trybie offline, ale nie wiadomo, czy wystąpiły offline (ponieważ są odtwarzane w takiej postaci). W tym celu możesz obsługiwać żądania śledzenia za pomocą Workbox, dodając do pingu analitycznego flagę offline przy użyciu niestandardowego wymiaru (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ę z powodu braku połączenia z internetem, zanim odzyska połączenie z internetem? Choć zwykle powoduje to uśpienie skryptu service worker (ponieważ nie może wysłać danych po przywróceniu połączenia), moduł Google Analytics w Workbox korzysta z interfejsu API synchronizacji w tle, który wysyła dane analityczne później po przywróceniu połączenia, nawet jeśli użytkownik zamknie kartę lub przeglądarkę.

Wciąż ma ona jednak tę wadę: chociaż dzięki temu istniejące funkcje śledzenia offline są już możliwe, najprawdopodobniej nie uzyskasz zbyt wielu istotnych danych, dopóki nie wdrożysz podstawowego trybu offline. Po zerwaniu połączenia użytkownicy mogą szybko opuścić Twoją witrynę. Teraz możesz jednak przynajmniej to zmierzyć i zliczać, porównując średnią długość sesji i zaangażowanie użytkowników w przypadku wymiaru offline z zastosowanym wymiarem offline ze zwykłymi użytkownikami.

SPA i leniwe ładowanie

Jeśli użytkownicy odwiedzający stronę wielostronicową przechodzą w tryb offline i próbują się z nią poruszać, pojawi się domyślna strona offline przeglądarki, co pomaga im zrozumieć, co się dzieje. Jednak strony utworzone jako aplikacje jednostronicowe działają inaczej. Użytkownik pozostaje na tej samej stronie, a nowa treść jest wczytywana dynamicznie przez technologię AJAX bez konieczności nawigacji. Po przejściu w tryb offline użytkownik nie widzi strony błędu przeglądarki. Zamiast tego dynamiczne części strony są renderowane z błędami, przechodzą w nieokreślony stan lub po prostu przestają być dynamiczne.

Podobne efekty mogą występować w witrynach wielostronicowych z powodu leniwego ładowania. Na przykład pierwsze wczytywanie miało miejsce online, ale użytkownik przeszedł w tryb offline, zanim przewinął stronę. Wszystkie leniwe ładowane treści w części strony widocznej po przewinięciu nie będą odtwarzane w trybie leniwym i będą niewidoczne.

Takie przypadki są naprawdę irytujące dla użytkowników, dlatego warto je śledzić. Skrypty service worker stanowią idealne miejsce do wykrywania błędów sieci i śledzenia ich za pomocą narzędzi analitycznych. W obiekcie Workbox można skonfigurować globalny moduł obsługi przechwytywania, aby informował stronę o nieudanych żądaniach, wysyłając zdarzenie komunikatu:

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 słuchać wszystkich nieudanych żądań, innym sposobem jest wychwytywanie błędów tylko na określonych trasach. Jeśli na przykład chcesz raportować błędy występujące tylko na trasach do /products/*, możesz dodać sprawdzanie w elemencie setCatchHandler, które filtruje identyfikator URI za pomocą wyrażenia regularnego. Czytelniejszym rozwiązaniem jest wdrożenie recordRoute z niestandardowym modułem obsługi. Logika biznesowa umieszcza na osobnej trasie, co ułatwia konserwację w bardziej złożonych mechanizmach 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 Analytics. Ponownie pamiętaj o buforowaniu żądań analizy, które odbywają się offline w ramach skryptu service worker. Jak opisano wcześniej, zainicjuj wtyczkę workbox-google-analytics, aby włączyć wbudowaną obsługę Google Analytics.

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

Pozwoli to śledzić nieudane obciążenia zasobów w Google Analytics, gdzie można je analizować za pomocą raportów. Statystyki derywowane mogą zostać wykorzystane do ulepszenia buforowania skryptu service worker i ogólnej obsługi błędów, dzięki czemu strona jest bardziej niezawodna i niezawodna w niestabilnych warunkach sieciowych.

Dalsze kroki

W tym artykule przedstawiliśmy różne sposoby śledzenia użytkowania offline oraz ich zalety i wady. Te dane pomogą Ci oszacować, ilu użytkowników przełącza się w tryb offline i ma z tego powodu problemy, ale to dopiero początek. Jeśli Twoja witryna nie oferuje dobrze utworzonego trybu offline, oczywiście nie zauważysz dużego wykorzystania offline w statystykach.

Zalecamy wdrożenie pełnego śledzenia, a następnie rozszerzenie możliwości offline w ramach iteracji z uwzględnieniem numerów śledzenia. Zacznij od prostej strony z błędami offline, np. pola roboczego, które jest proste, i powinny być uznawane za sprawdzoną metodę UX, podobną do niestandardowych stron 404. Następnie przejdź do bardziej zaawansowanych kreacji zastępczych offline, a na koniec – prawdziwych treści offline. Pamiętaj, aby to zareklamować i wyjaśnić to swoim użytkownikom, a zauważysz wzrost wykorzystania. Przecież wszyscy co jakiś czas przestają działać w trybie offline.

Zapoznaj się z artykułami na temat raportowania danych i tworzenia kultury efektywności i rozwiązywania problemów z szybkością witryny w różnych dziedzinach. Znajdziesz w nich wskazówki na temat tego, jak przekonać osoby z różnych działów do zwiększenia inwestycji w witrynę. Choć posty te skupiają się na skuteczności, powinny pomóc Ci w ogólnym podejściu do angażowania zainteresowanych osób.

Baner powitalny od JC Gellidona na kanale Unsplash.