オフラインでの使用状況を測定する

サイトのオフラインでの使用状況を追跡して、サイトのオフライン エクスペリエンスを改善する必要がある理由を説明する方法。

Stephan Giesau
Stephan Giesau
Martin Schierle
Martin Schierle
X GitHub

サイトのオフラインでの使用状況を追跡する方法を学び、サイトに優れたオフライン モードが必要な理由を説明できるようにします。オフライン使用状況分析を実装する際に避けるべき落とし穴と問題を理解する。

オンラインとオフラインのブラウザ イベントの落とし穴

オフラインでの使用状況をトラッキングする明白な解決策は、online イベントと offline イベント（多くのブラウザがサポート）のイベント リスナーを作成し、それらのリスナーにアナリティクスのトラッキング ロジックを配置することです。残念ながら、このアプローチにはいくつかの問題と制限があります。

  • 一般に、すべてのネットワーク接続ステータス イベントをトラッキングすることは過剰であり、収集するデータをできるだけ少なくする必要があるプライバシー重視の世界では逆効果です。また、online イベントと offline イベントは、ネットワークがほんの一瞬失われただけでも発生する可能性があり、ユーザーはそれに気付かないこともあります。
  • オフライン アクティビティの分析トラッキングが分析サーバーに到達しない。
  • ユーザーがオフラインになったときにローカルでタイムスタンプをトラッキングし、ユーザーがオンラインに戻ったときにオフライン アクティビティをアナリティクス サーバーに送信するには、ユーザーがサイトに再度アクセスする必要があります。オフライン モードがないためにユーザーがサイトから離脱し、二度とアクセスしなかった場合、それを追跡する方法はありません。オフラインでの離脱を追跡する機能は、サイトに優れたオフライン モードが必要な理由を説明するケースを構築するための重要なデータです。
  • online イベントは、インターネット アクセスではなくネットワーク アクセスのみを認識するため、あまり信頼性が高くありません。そのため、ユーザーがオフラインのままで、トラッキング ping の送信が失敗する可能性があります。
  • ユーザーがオフラインの状態で現在のページに留まっている場合でも、他のアナリティクス イベント（スクロール イベント、クリックなど）はトラッキングされません。これらのイベントは、より関連性が高く有用な情報である可能性があります。
  • 単にオフラインにするだけではあまり意味がありません。最も重要なのは、読み込みに失敗したリソースを把握することです。これは、シングルページ アプリケーション（SPA）に特に関連しています。SPA では、ネットワーク接続が切断されても、ユーザーが理解できるブラウザのオフライン エラーページが表示されないことがあります。代わりに、ページのランダムな動的部分がサイレントに失敗する可能性があります。

このソリューションを使用しても、オフラインでの使用状況を基本的に把握することはできますが、多くの欠点と制限事項を慎重に検討する必要があります。

より良いアプローチ: Service Worker

オフライン モードを有効にするソリューションは、オフラインでの使用状況を追跡するのにも適しています。ユーザーがオフラインの間は、アナリティクス ping を IndexedDB に保存し、ユーザーがオンラインに戻ったときに再送信できます。Google アナリティクスの場合、これはすでに Workbox モジュールで利用できますが、4 時間以上遅延して送信されたヒットは処理されない可能性があることに注意してください。

最もシンプルな形式では、Workbox ベースの Service Worker 内で次の 2 行で有効にできます。

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

googleAnalytics.initialize();

これにより、オフライン中に発生した既存のイベントとページビューの ping がすべてトラッキングされますが、それらはそのまま再生されるため、オフラインで発生したことはわかりません。カスタム ディメンションを使用して、アナリティクスの ping に offline フラグを追加することで、Workbox でトラッキング リクエストを操作できます。

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

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

インターネット接続が回復する前に、ユーザーがオフラインになったためにページから離脱した場合はどうなるでしょうか。通常、この場合、接続が回復したときにデータを送信できないため、サービス ワーカーはスリープ状態になりますが、Workbox Google アナリティクス モジュールは 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/* へのルートで発生したエラーのみを報告する場合は、正規表現で URI をフィルタするチェックを setCatchHandler に追加します。

より簡潔な解決策は、カスタム ハンドラを使用して registerRoute を実装することです。これにより、ビジネス ロジックが別のルートにカプセル化され、より複雑な 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();
    }
  }
);

最後のステップとして、ページで message イベントをリッスンし、アナリティクス ping を送信する必要があります。ここでも、オフラインで発生するアナリティクス リクエストを Service Worker 内でバッファリングするようにしてください。前述のように、組み込みの Google アナリティクス サポート用に workbox-google-analytics プラグインを初期化します。

次の例では Google アナリティクスを使用していますが、他のアナリティクス ベンダーでも同様に適用できます。

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 アナリティクスで追跡され、レポートで分析できるようになります。得られた分析情報は、サービス ワーカーのキャッシュ保存とエラー処理全般を改善し、不安定なネットワーク環境下でもページの堅牢性と信頼性を高めるために使用できます。

次のステップ

オフラインでの使用状況を追跡するさまざまな方法と、それぞれのメリットとデメリットについて学習しました。これにより、オフラインになって問題が発生したユーザーの数を定量化できますが、これはほんの始まりにすぎません。ウェブサイトに適切に構築されたオフライン モードが用意されていない限り、アナリティクスでオフラインでの使用がそれほど多く表示されることはありません。

完全なトラッキングを導入してから、トラッキングに重点を置いてオフライン機能を反復的に拡張することをおすすめします。まずはオフライン エラーページから始めます。これは Workbox で簡単に作成でき、カスタム 404 ページと同様に UX のベスト プラクティスです。次に、より高度なオフライン フォールバック、最後に実際のオフライン コンテンツへと進みます。この点をユーザーに十分に宣伝して説明すれば、利用が増えるはずです。誰でもたまにはオフラインになるものです。

レポート指標を報告してパフォーマンス文化を構築する方法と部門横断的にウェブサイトの速度を修正するで、部門横断的な関係者を説得してウェブサイトへの投資を増やすためのヒントをご覧ください。これらの投稿はパフォーマンスに焦点を当てていますが、関係者と関わる方法について一般的なアイデアを得るのに役立ちます。