評估離線用量

如何追蹤網站的離線使用情況，以便根據原因提出網站需要改善離線體驗的原因。

Stephan Giesau

Martin Schierle

本文將說明如何追蹤網站的離線使用情況，協助您提出網站需要改善離線模式的原因。以及實作離線使用分析時應避免的錯誤和問題。

線上和離線瀏覽器事件的陷阱

追蹤離線使用情形的簡易解決方案，是為 online 和 offline 事件 (支援多種瀏覽器) 建立事件監聽器，並在這些事件監聽器中加入數據分析追蹤邏輯。遺憾的是，這種做法有一些問題和限制：

• 在一般情況下，追蹤每個網路連線狀態事件可能會過多，在註重隱私權的世界中會盡量減少資料。此外，只要進行不到一秒的網路遺失情形，就可能只會觸發 online 和 offline 事件，使用者可能也看不到或註意到。
• 針對離線活動的分析追蹤絕對不會觸及分析伺服器，因為使用者...在離線的狀態下。
• 取決於使用者再次造訪您的網站，在本機追蹤使用者離線時的時間戳記，並將離線活動傳送至分析伺服器。如果使用者因缺乏離線模式而離開網站，且從未再次造訪，您就無法進行追蹤。「追蹤離線流失情況」是建立案件的重要資料，方便您瞭解網站為何需要更優異的離線模式。
• online 事件只知道網路存取權，而不是網際網路存取權，因此並不穩定。因此，使用者可能仍處於離線狀態，且傳送追蹤連線偵測 (ping) 仍可能失敗。
• 即使使用者處於離線狀態時仍停留在目前的網頁，系統也不會追蹤其他任何數據分析事件 (例如捲動事件、點擊等)，但這可能還是提供更相關且實用的資訊。
• 一般而言，離線產品本身並無任何意義。網站開發人員可能更需要瞭解哪些資源無法載入。這在 SPA 中尤其重要，因為網路連線中斷可能不會導致瀏覽器離線錯誤頁面 (使用者知道)，也較可能出現頁面隨機動態失敗的情況。

您仍然可以使用此解決方案，對於離線使用有基本的瞭解，但您必須謹慎考量許多缺點和限制。

更好的方法：Service Worker

事實證明，啟用離線模式的解決方案是更適合追蹤離線用量的解決方案。基本概念是，只要在使用者離線的情況下，將分析連線偵測 (ping) 儲存至 IndexedDB，待使用者恢復連線後再重新傳送即可。至於 Google Analytics (分析) 就可以透過 Workbox 模組直接存取，但請注意，系統可能不會處理傳送超過 4 小時的命中資料。這個架構最簡單，可透過以下兩行，在 Workbox 型服務工作站中啟用：

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

googleAnalytics.initialize();

這會追蹤離線時的所有現有事件和網頁瀏覽連線偵測 (ping)，但您不會知道這些事件是在離線狀態下發生 (只是會照原樣重新播放)。為此，您可以使用 Workbox 操控追蹤要求，方法是使用自訂維度 (在下方的程式碼範例中為 cd1) 將 offline 標記加進數據分析連線偵測 (ping)：

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

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

如果使用者在網際網路連線恢復前就離開頁面，會發生什麼情況？儘管這通常會使 Service Worker 進入休眠狀態 (因為系統無法在連線恢復後傳送資料)，Workbox Google Analytics (分析) 模組仍會使用 Background Sync API，並在連線恢復後傳送數據分析資料，即便使用者關閉分頁或瀏覽器也是如此。

但缺點是即使連線中斷，使用者仍會迅速離開您的網站。不過，現在您至少可以評估和量化這項數據，方法是比較套用離線維度和一般使用者的使用者平均工作階段長度和使用者參與度。

SPA 和延遲載入

如果使用者造訪建立為多網頁網站的網頁，在離線時嘗試瀏覽，則瀏覽器的預設離線頁面會協助使用者瞭解操作內容。不過，以單頁應用程式建構的頁面運作方式有所不同。使用者會停留在同一個頁面，且會在不瀏覽任何瀏覽器的情況下，透過 AJAX 動態載入新內容。使用者離線時不會看見瀏覽器錯誤頁面。相反地，網頁的動態部分出現錯誤時，會進入未定義狀態，或只是不再顯示為動態內容。

多頁網站可能會因為延遲載入，也會發生類似效果。舉例來說，初始載入可能在線上發生，但使用者在捲動畫面前已離線。位於需捲動位置的所有延遲載入內容都會在不顯示通知的情況下失敗，且不會顯示任何內容。

由於這類情況真的會讓使用者感到困擾，追蹤這些情況是合理的做法。服務工作處理程序是找出網路錯誤的最佳位置，最終會透過數據分析進行追蹤。透過 Workbox，您可以傳送全域擷取處理常式，藉由傳送訊息事件，將要求失敗的資訊通知頁面：

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();

  }());
});

與其監聽所有失敗的要求，另一種方法是僅擷取特定路徑上的錯誤。舉例來說，如果只想回報路徑發生在 /products/* 上的錯誤，我們可以在 setCatchHandler 中新增一個檢查項目，透過規則運算式篩選 URI。更簡潔的解決方案，是使用自訂處理常式實作 setupRoute。這會將商業邏輯封裝為不同的路徑，在較複雜的服務工作站中更易於維護：

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();
    }
  }
);

最後，頁面需要監聽 message 事件並送出分析連線偵測 (ping)。 同樣地，請務必緩衝在 Service Worker 中離線發生的分析要求。如先前所述，初始化 workbox-google-analytics 外掛程式即可提供內建的 Google Analytics (分析) 支援。

以下範例使用 Google Analytics (分析)，但也適用於其他分析服務供應商。

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
      });
    }
  });
}

這樣會追蹤 Google Analytics (分析) 中失敗的資源載入情況，以便使用報表進行分析。衍生的深入分析可用於整體改善 Service Worker 快取和錯誤處理流程，使其在網路不穩定的情況下更穩定可靠。

後續步驟

本文將說明各種追蹤離線使用的方法，以及這些功能的優勢和缺點。雖然這有助於量化有多少使用者處於離線狀態，且因發生問題而遇到問題，不過這仍只是第一步。只要您的網站並未提供完善的離線模式，Analytics (分析) 就會明顯無法列出離線用量。

建議您先設定完整追蹤功能，再留意追蹤號碼，持續擴充離線功能。請先從簡單的離線錯誤頁面著手 (使用 Workbox 較容易處理)，但仍應視為與自訂 404 頁面類似的使用者體驗最佳做法。接著，請努力取得更多進階離線備用選項，最後再找到真正的離線內容。請務必向使用者明確說明這項資訊，提高使用率。畢竟，每個人都可能偶爾會離線。

請參閱「如何回報指標及建立效能文化」和「修正跨部門網站速度」這兩篇文章，瞭解如何說服跨部門的利害關係人，讓網站能投入更多資源。雖然這些貼文的重點在於效能，但內容應可協助您大致瞭解如何與利益相關者互動。

JC Gellidon 於 Unsplash 提供的主頁橫幅。