オフライン使用量の測定

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

Stephan Giesau
Stephan Giesau
Martin Schierle
Martin Schierle
X GitHub

この記事では、サイトのオフライン利用状況をトラッキングして、 オフライン モードの改善が必要です。また、実装時に回避すべき問題点と問題についても説明します。 オフライン使用状況の分析

オンラインとオフラインのブラウザ イベントの注意点

オフラインの使用状況をトラッキングするには、まずアプリのイベント リスナーを作成し、 online、 offline イベント（ 多くのブラウザに対応している）とともに、トラッキング用のデータを ロジックを組み込んでください。残念ながら、この方法にはいくつかの問題と制限事項があります。 アプローチ:

  • 一般に、すべてのネットワーク接続ステータス イベントを追跡すると、過剰な負荷がかかることがあり、 データをできる限り少なくする必要があるプライバシー重視の世界では、逆効果 収集します。さらに、online イベントと offline イベントは、わずか数秒間 ユーザーが気付くことさえないでしょう
  • オフライン アクティビティの分析トラッキングが分析サーバーに到達することはありません。これは次のためです。 ユーザーがオフラインの場合です
  • ユーザーがオフラインになったときのタイムスタンプをローカルで追跡して、そのオフライン アクティビティを ユーザーがオンラインに戻ったときのアナリティクス サーバーの復旧時間は、ユーザーが再度サイトにアクセスするかどうかによって異なります。 オフライン モードがないためにユーザーがサイトを離脱し、再度アクセスしない場合は、 追跡できませんオフラインでの離脱を追跡する機能は、 オフライン モードの改善が必要な理由についてご説明します。
  • online イベントは、信頼性に欠けているため、 ネットワーク アクセスについてのみ、 インターネットアクセスではありません。そのため、ユーザーがオフラインのままで、トラッキング ping が送信されると、 失敗します
  • ユーザーがオフライン中に現在のページにとどまっていても、 アナリティクス イベント（スクロール イベント、クリックなど）もトラッキングされるため、 関連性の高い有用な情報を提示します。
  • また、オフラインであること自体も、一般的にあまり意味がありません。ウェブサイト開発者は どの種類のリソースの読み込みに失敗したのかを知ることが重要です。これは特に重要です ネットワーク接続が切断されてもブラウザがオフラインにならない可能性がある SPA の場合 エラーページ（ユーザーが理解できるもの）はあるものの、ページの動的な部分がランダムに失敗する可能性が高くなります。 確認できます。

このソリューションを使用してオフラインの使用方法の基本を理解することもできますが、 デメリットと制限を慎重に検討する必要があります

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

オフライン モードを有効にするソリューションの方が、オフラインのトラッキングに適したソリューションであることがわかりました。 できます。基本的な考え方は、ユーザーがオフラインである間、分析 ping を IndexedDB に保存することです。 ユーザーが再びオンラインになったときに 再送信することもできますGoogle アナリティクスでは、すでに利用可能になっています。 Workbox モジュールを通じて ただし、1 回以上のヒットは 4 時間遅れ 処理されない場合があります最も単純な形式では、ワークボックスベースのサービス内でアクティブ化できる 次の 2 行で実行します。

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 はスリープ状態になりますが（データを送信できないため） ワークボックスの Google アナリティクス モジュールは、バックグラウンド同期 API を使用します。これにより、分析データを ユーザーがタブやブラウザを閉じた後も、接続が回復したときに再びデータが暗号化されます。

まだデメリットもあります。この方法では、既存のトラッキングはオフラインでも利用できるようになりますが、 基本的なオフライン モードを実装するまでは、関連性のあるデータがあまり届きません。ユーザーはやはり 接続が切れたときに サイトがすぐに切断されますしかし今では少なくとも ユーザーの平均セッション継続時間とユーザー エンゲージメントをオフラインと 通常のユーザーと比較したレポートが表示されます。

SPA と遅延読み込み

複数ページのウェブサイトとして作成されたページにアクセスしたユーザーがオフラインで移動しようとしても、ブラウザの デフォルトのオフライン ページが表示され、ユーザーは何が起こっているかを理解しやすくなります。ただし、外部 IP アドレスとして構築されたページは、 シングルページ アプリケーションの動作は異なります。ユーザーは同じページに留まり、新しいコンテンツも ユーザーがブラウザを操作せずに AJAX で動的に読み込まれるようにします。ユーザーにブラウザのエラーが表示されない 表示されます。代わりに、ページの動的な部分がエラーとともにレンダリングされて、 未定義の状態にしたり、動的ではなくなります。

遅延読み込みによって、複数ページのウェブサイトでも同様の影響が生じることがあります。たとえば、 初期読み込みはオンラインで行われたが、ユーザーはスクロールする前にオフラインになった。遅延読み込みのすべてのコンテンツ スクロールしなければ見えない範囲にあると 通知なく失敗して見当たらなくなります

このようなケースはユーザーを非常に不快にさせるものであるため、トラッキングするのは理にかなっています。Service Worker は、 ネットワーク エラーを検出し、最終的に分析を使用してエラーを追跡できます。ワークボックスを使用すると、 グローバル キャッチ ハンドラ メッセージ イベントを送信することで、失敗したリクエストについてページに通知するように設定できます。

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 を実装することです。これは Pod の ビジネス ロジックを別のルートにまとめ、複雑な 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 のキャッシュとエラー処理全般を改善し、ページの堅牢性を高めるために使用 不安定なネットワーク条件下でも高い信頼性を維持できます。

次のステップ

この記事では、オフラインの使用状況をトラッキングするさまざまな方法を紹介し、その長所と短所を挙げました。 オフラインになって問題に遭遇するユーザーの数を定量化できますが、 まだ始まったばかりです。ウェブサイトで十分に構築されたオフラインモードが 提供されていない限り オフラインのアナリティクスでは あまり使われません

完全なトラッキングを導入してから、 追跡番号に目を向けて反復処理を行いますまず簡単なオフラインエラーページから 簡単な操作で 推奨事項 いずれにせよ、カスタム 404 ページと同様の UX のベスト プラクティスと考えてください。自分のやり方で進めていきます より高度なオフライン代替機能を 最終的にオフラインコンテンツに誘導します必ず宣伝し、ユーザーに説明する 使用量が増加するでしょう結局のところ、誰でもオフラインになることはたまにあります。

指標を報告してパフォーマンス文化を構築する方法をご覧ください ヒント: ウェブサイトの速度を部門横断的に修正する にまとめました。それらの投稿は パフォーマンスを重視しているため、アプローチ方法に関する全般的なヒントを得ることができる できます。

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