サイトのオフライン利用状況をトラッキングして、オフラインでの利用状況を改善する必要性を訴える方法。
この記事では、サイトのオフライン使用状況をトラッキングして、サイトに優れたオフライン モードが必要である理由を説明する方法について説明します。また、オフライン使用状況アナリティクスを実装する際に避けるべき落とし穴や問題についても説明します。
オンライン ブラウザ イベントとオフライン ブラウザ イベントの落とし穴
オフライン使用状況をトラッキングするための明白なソリューションは、online イベントと offline イベント（多くのブラウザがサポートしている）のイベント リスナーを作成し、それらのリスナーにアナリティクス トラッキング ロジックを配置することです。残念ながら、このアプローチにはいくつかの問題と制限があります。
- 一般に、すべてのネットワーク接続ステータス イベントをトラッキングすることは過剰であり、可能な限り少ないデータを収集する必要があるプライバシー重視の世界では逆効果です。また、
onlineイベントとofflineイベントは、ネットワークが失われたほんの一瞬で発生する可能性があります。この場合、ユーザーはネットワークの切断に気付かない可能性もあります。 - ユーザーがオフラインであるため、オフライン アクティビティの分析トラッキングは分析サーバーに到達しません。
- ユーザーがオフラインになったときのタイムスタンプをローカルでトラッキングし、ユーザーがオンラインに戻ったときにオフライン アクティビティをアナリティクス サーバーに送信するかどうかは、ユーザーがサイトに再びアクセスするかどうかによって異なります。オフライン モードがないためにユーザーがサイトを離脱し、再度アクセスしなかった場合、それをトラッキングする方法はありません。オフラインでの離脱をトラッキングできる機能は、サイトに優れたオフライン モードが必要である理由を示すための重要なデータです。
onlineイベントは、インターネット アクセスではなくネットワーク アクセスのみを認識するため、信頼性が低くなります。そのため、ユーザーがオフラインのままで、トラッキング ping の送信が失敗する可能性があります。- ユーザーがオフライン中に現在のページにとどまっている場合でも、他のアナリティクス イベント（スクロール イベント、クリックなど）もトラッキングされません。これは、より関連性が高く有用な情報である可能性があります。
- また、オフラインであること自体も、一般的にあまり意味がありません。ウェブサイト デベロッパーにとって、読み込みに失敗したリソースの種類を知ることが重要になる場合があります。これは、ネットワーク接続が切断された場合に、ブラウザのオフライン エラー ページ（ユーザーが理解できる）が表示されるのではなく、ページのランダムな動的部分がサイレントで失敗する可能性が高い SPA のコンテキストで特に重要です。
このソリューションを使用すれば、オフラインでの使用状況を把握できますが、多くのデメリットと制限事項を慎重に検討する必要があります。
より優れた方法: サービス ワーカー
オフライン モードを有効にするソリューションは、オフライン使用状況をトラッキングするのに適したソリューションであることがわかりました。基本的な考え方は、ユーザーがオフラインである限りアナリティクス ピングを 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',
},
});
インターネット接続が復元される前に、ユーザーがオフラインになったためにページから離脱した場合はどうなりますか？通常、接続が復元されたときにデータを送信できないため、サービス ワーカーはスリープ状態になりますが、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）