サイトのオフラインでの使用状況をトラッキングして、サイトのオフライン エクスペリエンスを改善する必要がある理由を説明する方法について説明します。
サイトのオフラインでの使用状況をトラッキングして、サイトに優れたオフライン モードが必要な理由を説明する方法について説明します。オフラインでの使用状況に関する分析を実装する際に避けるべき落とし穴と問題について説明します。
オンライン ブラウザ イベントとオフライン ブラウザ イベントの落とし穴
オフラインでの使用状況をトラッキングする簡単な方法は、
online イベントと
offline
イベント（多くのブラウザでサポートされています）のイベント リスナーを作成し、それらのリスナーに分析トラッキング ロジックを配置することです。ただし、このアプローチにはいくつかの問題と制限があります。
- 一般に、すべてのネットワーク接続ステータス イベントをトラッキングすることは過剰であり、可能な限り少ないデータを収集すべきプライバシー重視の世界では逆効果です。また、
onlineイベントとofflineイベントは、ネットワークが切断されたほんの一瞬でも発生する可能性があり、ユーザーはそれを見たり気づいたりすることはないでしょう。 - オフライン アクティビティの分析トラッキングは、分析サーバーに到達しません。
- ユーザーがオフラインになったときにタイムスタンプをローカルでトラッキングし、ユーザーがオンラインに戻ったときにオフライン アクティビティを分析サーバーに送信するには、ユーザーがサイトに再アクセスする必要があります。オフライン モードがないためにユーザーがサイトから離脱し、再アクセスしない場合、それをトラッキングする方法はありません。オフラインでの離脱をトラッキングする機能は、サイトに優れたオフライン モードが必要な理由を説明するための重要なデータです。
- `
online` イベントは、インターネット アクセスではなくネットワーク アクセスのみを認識するため、あまり信頼できません。そのため、ユーザーがオフラインのままで、トラッキング ping の送信が失敗する可能性があります。 - ユーザーがオフラインの間に現在のページに留まっている場合でも、他の分析イベント（スクロール イベント、クリックなど）はトラッキングされません。これらのイベントは、より関連性が高く有用な情報である可能性があります。
- オフラインであることはあまり意味がありません。読み込みに失敗したリソースを把握することが最も重要です。これは、ネットワーク接続が切断されても、ユーザーが理解できるブラウザのオフライン エラーページが表示されない可能性があるシングルページ アプリケーション（SPA）に特に当てはまります。代わりに、ページのランダムな動的部分がサイレントに失敗する可能性があります。
このソリューションを使用してオフラインでの使用状況の基本的な理解を得ることはできますが、多くの欠点と制限を慎重に検討する必要があります。
より良いアプローチ: Service Worker
オフライン モードを有効にするソリューションは、オフラインでの使用状況をトラッキングする優れたソリューションでもあります。ユーザーがオフラインの間は、分析 ping を IndexedDB に保存し、ユーザーがオンラインに戻ったときに再送信できます。Google アナリティクスの場合、 これは Workbox モジュールですでに利用可能ですが、 4 時間以上遅延して送信されたヒットは 処理されない 可能性があることに注意してください。
最もシンプルな形式では、Workbox ベースの Service Worker 内で次の 2 行で有効にできます。
import * as googleAnalytics from 'workbox-google-analytics';
googleAnalytics.initialize();
import * as googleAnalytics from 'workbox-google-analytics';
googleAnalytics.initialize({
parameterOverrides: {
customDimension1: 'offline',
},
});
インターネット接続が復旧する前に、ユーザーがオフラインのためにページから離脱した場合はどうなりますか？通常、接続が復旧したときにデータを送信できないため、Service Worker はスリープ状態になりますが、Workbox Google アナリティクス モジュールは Background Sync API を使用します。Background Sync は、ユーザーがタブまたはブラウザを閉じても、接続が復旧したときに分析データを送信します。
欠点はまだあります。これにより、既存のトラッキングをオフライン対応にできますが、基本的なオフライン モードを実装するまで、関連性の高いデータはほとんど表示されません。接続が切断されると、ユーザーはすぐにサイトから離脱します。ただし、オフライン ディメンションが適用されたユーザーと通常のユーザーの平均セッション時間とユーザー エンゲージメントを比較することで、これを測定して定量化できます。
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/* へのルートで発生したエラーのみを報告する場合は、setCatchHandler にチェックを追加して、正規表現で URI をフィルタできます。
よりクリーンな解決策は、カスタム ハンドラで 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 の効果的な手法です。次に、 より高度なオフライン フォールバック 、そして最終的には実際のオフライン コンテンツを目指します。これをユーザーに適切に宣伝して説明すると、使用量が増加します。結局のところ、誰もが時々オフラインになります。
クロスファンクショナルなステークホルダーにウェブサイトへの投資を増やすよう説得するためのヒントについては、指標を報告してパフォーマンス文化を構築する方法 とウェブサイトの速度をクロスファンクショナルに修正するをご覧ください。 これらの投稿はパフォーマンスに重点を置いていますが、ステークホルダーとの連携方法に関する一般的なアイデアを得るのに役立ちます。