オフライン使用量の測定

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

Stephan Giesau
Stephan Giesau
Martin Schierle
Martin Schierle

この記事では、サイトのオフライン使用状況をトラッキングして、サイトに優れたオフライン モードが必要である理由を説明する方法について説明します。また、オフライン使用状況アナリティクスを実装する際に回避すべき落とし穴や問題についても説明します。

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

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

このソリューションを使用すれば、オフラインでの使用状況を把握できますが、多くのデメリットと制限事項を慎重に検討する必要があります。

より優れた方法: サービス ワーカー

オフライン モードを有効にするソリューションは、オフライン使用状況をトラッキングするのに適したソリューションであることがわかりました。基本的な考え方は、ユーザーがオフラインである限りアナリティクス ピングを IndexedDB に保存し、ユーザーが再びオンラインになったときに再送信することです。Google アナリティクスでは、Workbox モジュールを介してすぐに利用できる機能としてすでに提供されていますが、4 時間以上遅延して送信されたヒットは処理されない可能性があります。最もシンプルな形式では、Workbox ベースのサービス ワーカー内で次の 2 行を使用して有効にできます。

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

googleAnalytics.initialize();

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

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

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

インターネット接続が復元される前に、ユーザーがオフラインになったためにページから離脱した場合はどうなりますか?通常、接続が復元されたときにデータを送信できないため、サービス ワーカーはスリープ状態になりますが、Workbox Google アナリティクス モジュールは Background Sync API を使用します。この 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/* へのルートで発生したエラーのみを報告する場合は、正規表現で 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 イベントをリッスンし、アナリティクス ピングを送信する必要があります。オフラインで発生するアナリティクス リクエストは、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 アナリティクスでリソースの読み込みエラーがトラッキングされ、レポートで分析できるようになります。導き出された分析情報は、Service Worker のキャッシュとエラー処理全般を改善し、不安定なネットワーク状況下でもページの堅牢性と信頼性を高めるために使用できます。

次のステップ

この記事では、オフライン ユーザー数のトラッキング方法とそのメリットとデメリットについて説明しました。これにより、オフラインになり問題が発生したユーザーの数を定量化できますが、これはあくまでもスタートに過ぎません。ウェブサイトに適切に構築されたオフライン モードが提供されていない限り、アナリティクスでオフラインでの使用状況を確認することはできません。

トラッキングを完全に設定してから、トラッキング数を重視してオフライン機能を段階的に拡張することをおすすめします。まず、シンプルなオフライン エラーページから始めましょう。Workbox では簡単に作成できます。カスタム 404 ページと同様に、UX のベスト プラクティスと見なされます。次に、より高度なオフライン フォールバックに進み、最終的には実際のオフライン コンテンツに進みます。これをユーザーに十分に宣伝して説明すれば、使用率は向上します。誰でもたまにオフラインになるものです。

ウェブサイトにさらに投資するよう部門横断的な関係者に説得するヒントについては、指標を報告してパフォーマンス文化を構築する方法ウェブサイトの速度を部門横断的に改善するをご覧ください。これらの投稿はパフォーマンスに焦点を当てていますが、ステークホルダーを関与させる方法に関する一般的なアイデアを得るのに役立ちます。

ヒーロー写真: JC GellidonUnsplash