サイトのオフライン利用状況をトラッキングする方法。オフライン エクスペリエンスの改善が必要な理由をわかりやすく説明するのに役立ちます。
この記事では、オフライン モードの改善が必要な理由を的確に判断できるよう、サイトでのオフライン利用状況をトラッキングする方法について説明します。また、オフライン使用状況分析を実装する際の注意点や問題についても説明します。
オンラインとオフラインのブラウザ イベントの注意点
オフラインの使用状況を追跡するには、online イベントと offline イベントのイベント リスナー（多くのブラウザがサポート）を作成し、それらのリスナーに分析トラッキング ロジックを配置するのが確実な解決策です。残念ながら、このアプローチにはいくつかの問題と制限があります。
- 一般的に、ネットワーク接続ステータス イベントのトラッキングは過度であり、収集するデータをできるだけ少なくする必要があるプライバシー重視の世界では逆効果になります。さらに、
onlineイベントとofflineイベントは、ユーザーが確認または気づくことさえない、わずか 1 秒間のネットワーク損失で発生する可能性があります。 - ユーザーがオフラインのため、オフラインのアクティビティの分析トラッキングが分析サーバーに到達することはありません。
- ユーザーがオフラインになったときにタイムスタンプをローカルでトラッキングし、オンラインに戻ったときにオフライン アクティビティを分析サーバーに送信するかどうかは、ユーザーがサイトに再度アクセスしているかどうかによって異なります。オフライン モードがないためにサイトを離脱し、一度もアクセスしなかった場合、それをトラッキングする方法はありません。オフラインでの離脱をトラッキングできることは、サイトに優れたオフライン モードが必要な理由を説明するうえで重要なデータです。
onlineイベントは、インターネット アクセスではなくネットワーク アクセスのみを知っているため、あまり信頼できません。そのため、ユーザーがまだオフラインになっている可能性があり、トラッキング ping の送信が失敗する可能性があります。- ユーザーがオフライン中に現在のページに留まっていても、他のアナリティクス イベント（スクロール イベント、クリックなど）はいずれもトラッキングされません。これらのイベントは、より関連性が高く有用な情報になる可能性があります。
- 一般的に、オフラインであること自体もあまり意味がありません。ウェブサイトのデベロッパーにとって、読み込みに失敗したリソースの種類を把握することがより重要な場合があります。これは特に SPA のコンテキストで関係します。ネットワーク接続のドロップでは、ブラウザのオフライン エラーページ（ユーザーが理解しているもの）にはつながらないものの、ページのランダムな動的部分が通知なく失敗する可能性が高くなります。
このソリューションを使用してオフラインの使用状況の基本を理解することもできますが、多くの欠点や制限を慎重に考慮する必要があります。
より良いアプローチ: Service Worker
その結果、オフライン モードを有効にするソリューションが、オフラインの使用状況を追跡するのに適したソリューションであることが判明しました。基本的な考え方は、ユーザーがオフラインである限り分析 ping を IndexedDB に保存し、ユーザーが再びオンラインになったときに再送信するというものです。Google アナリティクスでは、すでに Workbox モジュールを通じてすぐに利用できますが、送信されたヒットが 4 時間遅延を超えて送信された場合は処理されない場合があります。最もシンプルな形式では、次の 2 行を使用して Workbox ベースの Service Worker 内で有効にできます。
import * as googleAnalytics from 'workbox-google-analytics';
googleAnalytics.initialize();
これにより、オフライン時の既存のイベントとページビュー ping がすべてトラッキングされますが、それらがオフラインで発生したことは（そのままリプレイされるだけなので）認識できません。そのためには、カスタム ディメンション（以下のコードサンプルでは cd1）を使用して、offline フラグを分析 ping に追加することで、Workbox でトラッキング リクエストを操作できます。
import * as googleAnalytics from 'workbox-google-analytics';
googleAnalytics.initialize({
parameterOverrides: {
cd1: 'offline',
},
});
インターネット接続が回復する前にユーザーがオフラインのためにページを閉じてしまった場合はどうなりますか？接続が回復したときにデータを送信できないため、通常は Service Worker はスリープ状態になりますが、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 イベントをリッスンし、アナリティクス 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）