本頁面由 Cloud Translation API 翻譯而成。

評估離線用量

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

Stephan Giesau

Martin Schierle

本文將說明如何追蹤網站的離線使用情況，協助您判斷更棒的離線模式以及實作時應避免的錯誤和問題。以及離線使用分析

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

追蹤離線使用情形的最簡單解決方法，就是為 online 和 offline 事件 ( 支援多種瀏覽器)，並且進行分析追蹤傳回對應的邏輯然而，這個問題有幾個問題和限制方法：

在一般情況下，追蹤每個網路連線狀態事件可能會過多，在以隱私權為重的世界中，能抵銷不利的產品，因此應盡量減少資料。收集。此外，online 和 offline 事件只需要在網路遺失率，因此使用者可能根本沒發現或註意到。
針對離線活動的分析追蹤資料絕對不會傳送至分析伺服器，因為其實使用者...離線時
追蹤使用者離線並傳送離線活動時的本機時間戳記取決於使用者再次造訪您的網站。如果使用者因缺乏離線模式而離開網站，且從未再次造訪的情況下離開網站，也很難追蹤到追蹤離線訪客人數是建立良好關係的關鍵資料你的網站為何需要更優異的離線模式。
online 事件並不可靠「知道網路存取權」，無法存取網際網路。因此，使用者可能仍處於離線狀態，因此傳送追蹤連線偵測 (ping) 可能會仍會失敗
即使使用者處於離線狀態時仍停留在目前頁面，也不會有其他人系統會追蹤數據分析事件 (例如捲動事件、點擊等)，但這可能涉及較多最切合需求且實用的資訊
一般而言，離線產品本身並無任何意義。網站開發人員重要的是瞭解無法載入的資源類型這就特別符合需求在 SPA 環境中，如果網路連線中斷，瀏覽器可能無法離線錯誤網頁 (使用者能理解)，但網頁隨機動態部分失敗的可能性也比較高不要說話。

您仍然可以使用這個解決方案，取得離線使用情形的基本知識。請留意缺點和限制

更好的方法：Service Worker

事實證明，啟用離線模式的解決方案是更理想的離線追蹤解決方案。基本概念是將數據分析連線偵測 (ping) 儲存至 IndexedDB 中，只要使用者處於離線狀態，等到使用者恢復連線時再重新傳送要求即可Google Analytics 目前已經支援這些格式透過 Workbox 模組直接存取但請注意，命中傳送的資料超過延後四小時可能不會處理。這個架構最簡單，可在 Workbox 式服務中啟用，

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

googleAnalytics.initialize();

這樣在離線時追蹤所有現有的事件和網頁瀏覽連線偵測 (ping)，但您並不清楚隨即離線 (依原樣重新播放)。為此您可以使用 Workbox 操控追蹤要求方法是使用自訂維度 (程式碼中的 cd1)，將 offline 旗標加進 Analytics 連線偵測 (ping) 範例)：

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

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

如果使用者在網際網路連線之前因離線而離開頁面，會有什麼影響？回來？儘管這通常會使 Service Worker 進入休眠狀態 (因為系統無法傳送資料連線恢復時，Workbox Google Analytics 模組會使用背景同步處理 API，可用於傳送數據分析資料資料。

但還有一個缺點：雖然這樣使得現有的追蹤可以離線運作，您只有在導入基本離線模式後，才能得到太多相關資料。使用者在連線中斷時迅速流失您的網站。但現在至少可以測量量化這個數據會比較離線使用者的平均工作階段長度和使用者參與度維度與一般使用者做比較

SPA 和延遲載入

如果使用者造訪了基於多網頁網站而建立的網頁，進行離線並嘗試瀏覽時，則瀏覽器的預設離線網頁顯示，協助使用者瞭解實際情況。不過，如果網頁採用單頁應用程式的運作方式不同使用者會停留在同一個頁面，但新增的內容不需透過任何瀏覽器瀏覽，即可透過 AJAX 動態載入。使用者看不到瀏覽器錯誤瀏覽其中內容。相反地，定義狀態，或不再使用動態選項

多頁網站可能會因為延遲載入，也會發生類似效果。舉例來說初次載入是在線上進行，但使用者在捲動畫面前已離線。所有延遲載入內容不需捲動位置就會失敗，因而消失。

由於這類情況真的會讓使用者感到困擾，追蹤這些情況是合理的做法。Service Worker 是找出網路錯誤，最終透過數據分析追蹤這些錯誤。有了 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 中離線發生的分析要求。阿斯初始化內建的 Google Analytics 專用 workbox-google-analytics 外掛程式聯絡。

以下範例使用 Google Analytics，但可如何套用至其他 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 顯然不到離線用量。

建議您先設定完整追蹤功能，再根據並請留意追蹤號碼先從簡單的離線錯誤頁面著手，工作箱行動– 應該視為使用者體驗最佳做法，類似於自訂 404 網頁。隨心所欲工作取得更多進階離線備用資料最後再推出真正離線內容確定您已向使用者放送廣告，並向使用者說明用量也會增加畢竟，每個人都可能偶爾會離線。

請參閱「如何記錄指標和營造成效文化」一文。以及「修正網站載入速度」一文，瞭解相關訣竅。雖然這些貼文應該幫助您獲得與觀眾互動的利害關係人

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