オフライン使用量の測定

サイトのオフライン利用状況をトラッキングして、オフラインでの利用状況を改善する必要性を訴える方法。

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 時間遅れて送信されたヒットは処理されない可能性があるので注意してください。最も単純な形式では、次の 2 行を使用して、ワークボックス ベースの Service Worker 内で有効にできます。

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

googleAnalytics.initialize();

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

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

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

インターネット接続が回復する前に、ユーザーがオフラインのためページから離れた場合はどうなりますか？これにより、通常は接続が回復したときにデータを送信できないため、Service Worker はスリープ状態になりますが、Workbox Google Analytics モジュールは 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 イベントをリッスンし、アナリティクスの 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 アナリティクスで追跡され、レポートで分析できます。得られた分析情報を使用して、Service Worker のキャッシュとエラー処理全般を改善し、不安定なネットワーク条件下でページの堅牢性と信頼性を高めることができます。

次のステップ

この記事では、オフラインの使用状況をトラッキングするさまざまな方法を紹介し、その長所と短所を紹介しました。 オフラインになって問題に遭遇するユーザーの数を定量化できますが、これはまだ始まりにすぎません。ウェブサイトで十分に構築されたオフライン モードを備えていない限り、分析におけるオフライン利用はあまり見られません。

完全なトラッキングを実装し、追跡番号に目を向けながらオフライン機能を段階的に拡張することをおすすめします。最初は簡単なオフライン エラーページから始めて（Workbox は簡単です）、カスタム 404 ページと同様の UX のベスト プラクティスとみなすことができます。次に、より高度なオフライン フォールバックへと進み、最終的に実際のオフライン コンテンツへと進みます。宣伝と説明が十分に行われていれば、利用が増加するでしょう。結局のところ、誰でもオフラインになることはたまにあります。

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

ヒーロー写真撮影: JC Gellidon、Unsplash より