サポート

RUMのサンプリングをクローズアップ

リアルユーザーモニタリング(RUM)ツールでサンプルレートを設定できるため、支出(使用量)を管理しながらページをモニタリングすることができます。予算内に収める必要がある場合、これは素晴らしいオプションです。リアルユーザーデータをサンプリングできるようになると、こんな疑問が湧いてきます。

「RUMのサンプルレートはどれくらいにすべきですか?」

このよくある質問には、簡単には答えられません。サンプルレートの精緻化は、注意深くなければ当たり外れがあります。以前の記事で、情報に基づいた意思決定を行うために本当に必要なRUMデータの量を決定する際に考慮すべき点をいくつか説明しました。サンプリング量が多すぎると、決して使うことのないデータを大量に集めてしまう可能性があります。一方、サンプリングが少なすぎると、データのばらつきが大きくなり、信頼性が落ちるリスクがあります。

この記事では、少し調査を行い、データに語ってもらうことにします。RUMデータのサンプリングを検討している方に何らかの指針を提供できればと思い、Tシャツサイズの企業3社(小、中、大)を対象に、様々なレベルでのサンプリングの影響を調べました。

この記事では、以下の内容を取り上げます。

  • 方法論
  • 主な調査結果
  • 考察
  • 推奨事項

方法論

トラフィックサイズ

この調査は、できる限りシンプルに行うように心がけました。SpeedCurveでは、国、業種、トラフィックレベルなど、さまざまな種類のサイトが見られます。この調査では、3つのコホートのサイトを例として取り上げます。

  1. 大規模:1日のページビューが100万を超える
  2. 中規模:1日のページビューが25~50万
  3. 小規模:1日のページビューが1~10万

ここで重要なのは、私が調べたサイトは、RUMデータを100%収集しているということです。

期間

24時間です。トラフィックは、時間帯、曜日、そして季節によって変動します。それぞれのサイトについて、同じ週の半ばの日付を調べてみたところ、毎日のトラフィックに一貫したパターンが見られました。

指標

これはちょっと大変でした。すべての指標が同じではないため、お気に入りの指標を選択しないようにしています。この記事の執筆時点では、LCP(Largest Contentful Paint ) はすべてのブラウザーでサポートされているわけではないので、若干の偏りがあります。これは、SpeedCurveで収集する多くの指標に当てはまります。この点やその他の考慮点については、後ほど少し説明します。最終的には、ブラウザのプラットフォーム間で広くサポートされているという理由から、loadEventEndに落ち着きました。

サンプリング方法

SpeedCurveでは、セッションに基づくサンプリングと、ページビューをランダムにサンプリングする機能を備えています。ページビューの数を正確に指定するよりも、セッションの整合性を維持することの方が重要だと考えています。ユーザーセッションを追跡・識別しているため、事後にデータをサンプリングすることが非常に容易になりました。

データの解釈

データを比較する方法はたくさんあります。私はデータサイエンティストではないので、少なくともパフォーマンスデータを見たことがある人には馴染みのあるデータの見方を使って、サンプリングの影響を実証したいと考えていました。

集計:50パーセンタイル、75パーセンタイル、95パーセンタイルの変化率をを見ます。5%以下は許容範囲とした。

ヒストグラム:データを見るだけで、多くのことを学ぶことができます。ヒストグラムは、母集団全体のパフォーマンス特性を示すのに適しています。(ヒストグラムの理解と解釈について、詳しくはこちらをご覧ください。)この実験では、サンプリングされた集団とサンプリングされていない集団の全体的な形状と分布を比較します。場合によっては、集計が5%未満であった可能性がありますが、ヒストグラムは非常にまばらで、元の分布に似ていませんでした。例えば、この2つのヒストグラムの中央値は妥当な範囲に収まっているにもかかわらず、その差は歴然としています。95パーセンタイルを見ると、サンプリングされたデータからロングテールが本質的に 「欠落」 していることがわかります。やや非科学的ではありますが、私は集計と一緒に目視テストも使って、レートが適切かどうかを判断しています。

Time series(時系列):RUMデータを運用目的で使用する場合、日中の変動が重要です。簡単な時系列を用いて、サンプリングが「ノイズ」要素にどのように影響するかを説明します。

主な調査結果

長すぎるという方のための要約

ほとんどの場合、サンプリングされたユーザー数が3,000人を超えると、集計された統計はアップサンプリングされたユーザー数にかなり近いことがわかりました (中央値の差は1~2%) 。ただし、RUMのユースケースに依存するいくつかのトレードオフを理解するために、この先をお読みください。また、必要に応じて、結果にジャンプしてください。

ほとんどの場合、サンプリングされたユーザーの母集団が3,000人以上であれば、集計された統計値はアップサンプル母集団にかなり近いことがわかりました(中央値で1~2%の違い)。しかし、RUMを使用するケースによって、トレードオフがあることを理解するために、この先をお読みください。また、もしよろしければ、結果にジャンプしてください。

レポートのためのRUM

日々のパフォーマンスを表すことのできるレポーティングツールとしてRUMを利用しているのであれば、幸運なことです。規模にもよりますが、母集団全体の中で比較的小さなサンプルで済ませることができます。

各グループの最小サンプル率を決定するために、集計数とヒストグラムの比較の組み合わせを調べました。これらの比較表に示されてた95パーセンタイルにおける一貫性に注意してください。

<小規模(1日のページビュー1~10万を50%でサンプリング)>

<中規模(1日のページビュー25〜50万人を10%でサンプリング)>

<大規模(1日のページビューが100万以上を1%でサンプリング)>

日中のパフォーマンス監視

一日に何度もコードをデプロイしているようなサイトがあるかもしれません。もしかしたら、サードパーティやさまざまなトラフィックパターン、その他の未知の要因による変動の影響を受けやすいかもしれません。この場合、RUMの運用上のニーズが高まる可能性があります。サンプリングレートは、データにノイズがあるかどうか、または予測不可能かどうかに多少影響することがあります。

前の使用例で推奨されたレートを見ると、次の例では、1時間ごとのパフォーマンスの信頼できる画像を取得するために、サンプリングレートをどれだけ上げる必要があるか、またリアルタイム監視 (分単位) を使用している場合はさらに上げる必要があることがわかります。

1時間ごとのモニタリング:

小規模 – 50%から75%に増加>

レートを大きくすることで、大きな偏差の一部を取り除くことができましたが、トラフィックの少ないサイトでは、データのばらつきが大きくなります。

<中規模 – 10%から25%に増加>

ピーク時は10%でもある程度安定していたが、25%にするとオフピーク時の偏差が大きくなった

<大規模 – 1%から10%に増加>

10%増やすことで、トラフィックの多いサイトでの一貫性が大きく改善されました

リアルタイムモニタリング

<小規模 – 75%から95%に増加>

データの大きなスパイクついては、サンプルを95%に増やすことが有効であった。しかし、データのばらつきを考えると、このような小規模サイトのリアルタイム監視が本当に効果的かどうかはわかりません。

<中規模 – 25%から75%に増加>

中程度のトラフィックのサイトでは、75%に上げると効果がありました

<大規模 – 10%から40%に増加>

このようにトラフィックの多いサイトでは、母集団と一致するリアルタイムデータを取得するには、予想以上にサンプルレートを上げる必要がありました

考慮事項

データセグメンテーション

ここからが重要なポイントです。RUMの優れた点の1つは、データをスライスして使用できることです。ユーザー集団の分布は、あらゆる種類のユーザー体験で構成されています。データをフィルタリング、セグメント化、スライス、ダイス化すると、事実上、母集団のサイズが小さくなるため、これはサンプル率にかなり大きな影響を及ぼします。

関心のあるセグメントによってサンプリングがどのように影響されるかを判断する場合、セグメントによって表されるトラフィックの割合を把握し、その割合を全体の割合に反映させます。一般的なセグメントには、国、ページタイプ、デバイスタイプ、ブラウザーなどがあります。上記の実験に多くのセグメントを適用した結果、サンプルレートを50%上げる(小規模なサイトでは100%収集する)ことをお勧めします。

指標

前述のように、ブラウザーでサポートされていないメトリック(はい、多くの測定基準)があります。セグメントのサンプルレートを増やす場合と同様に、FCP、LCP、Total Blocking Timeなどのメトリックのサンプルレートを増やすことを検討する必要があります。これらのメトリックは、広範なブラウザーサポートを備えていません。これは、すべてのページ読み込みでは発生しない一部のネットワーク関連のメトリックにも当てはまります(DNS、接続、SSL、リダイレクト)。

前述したように、ブラウザーでサポートされていない指標がいくつかあります。セグメントのサンプル レートを上げるのと同様に、FCP、LCP、Total Blocking Time など、幅広いブラウザでサポートされていない指標についても、サンプル レートを上げることを検討する必要があります。これは、すべてのページ読み込みで発生しない一部のネットワーク関連の測定基準(DNS、接続、SSL、リダイレクト)にも当てはまります。

時間枠を増やす

異なる実験のRUMデータを比較する場合や、パフォーマンスのビジネスインパクトを理解するためにコンバージョンデータを取得する場合、データの100%を取得する必要があると推奨されることがあります。しかし、これは必ずしもそうではありません。別の方法として、より多くのサンプリングデータを使って、より大きな時間枠を確認できます。これは、トラフィック数が少ないサイトにも当てはまります。正常な配布ができるまで、時間枠を拡大するだけです。

推奨事項

この記事の目的は、RUMデータのサンプリングに関する方向性を提供することでした。推奨レベルは、物事に影響を与える要因が多すぎるため、正確性を期すためのものではありません。ユーザーに関する知識に加えて、次の表を参考にしてください。

RUMサンプリングの詳細

ご推察の通り、SpeedCurveはRUMのデータサンプリングをサポートしています。この記事では、RUMサンプリングの仕組みと、RUMサンプリングを実装するさまざまな方法について詳しく説明しています。


※この記事はSpeedCurve社の英文情報を元に、内容を分かりやすく編集、翻訳した記事です。
Copyright © 2022 SpeedCurve Limited.

関連記事

コメント

  1. この記事へのコメントはありません。

  1. この記事へのトラックバックはありません。