• Google Analytics APIのsamplingLevelは速度と精度の優先順位で選ぶ

Google Analytics APIのsamplingLevelは速度と精度の優先順位で選ぶ

公開日: 執筆:佐藤

Google AnalyticsのCore Reporting APIでサンプリングが行われる場合は、samplingLevelで応答速度とsample sizeの優先順位を指定できます。選択肢はDEFAULT、FASTER、HIGHER_PRECISIONの三つです。

HIGHER_PRECISIONを指定しても、必ず全データを使うとは限りません。APIから返るcontainsSampledData、sampleSize、sampleSpaceを、レポートの数値と一緒に記録します。

samplingLevelの三つの値を目的で選ぶ

Core Reporting APIの公式リファレンスは、samplingLevelを任意のquery parameterとして定義しています。

値 APIが優先するもの 適する処理
DEFAULT 応答速度とsample sizeの均衡 通常の定期レポート
FASTER 小さいsample sizeによる速い応答 画面操作中の概況確認や試験query
HIGHER_PRECISION 大きいsample sizeによる精度 月次集計や判断に使う最終query

表の用途は選択を説明するための目安です。必ず同じ速さやsample sizeになるという保証ではありません。期間、metrics、dimensions、filters、segmentsが変われば、処理するデータも変わります。

最初はDEFAULTでqueryを作り、必要なmetricsとdimensionsが返るかを確認します。試作中に何度も条件を変えるならFASTERも使えます。集計条件が固まり、結果を保存するときにHIGHER_PRECISIONへ切り替えます。

速さを求める処理と、判断用の数値を保存する処理を同じqueryにしない方が、待ち時間と精度のどちらを優先したかが明確になります。

sampleSizeとsampleSpaceを割合で確認する

API responseのcontainsSampledDataがtrueなら、結果はサンプリングされています。sampleSizeは計算に使われたsample数、sampleSpaceは選択元となった全体のsample spaceです。

使用割合は次の式で求められます。

sampleSize ÷ sampleSpace × 100

説明用に、sampleSizeが180,000、sampleSpaceが200,000なら、使用割合は90%です。

180,000 ÷ 200,000 × 100 = 90

90%という値だけでレポートを採用するかは決めません。問い合わせ数の大まかな傾向を見るのか、広告費の配分を決めるのかで、必要な精度は違います。前月比を比べる場合も、二つのqueryでsamplingの条件が異なれば、その差を数値の変化だけとして扱えません。

containsSampledDataがfalseの場合に、sampleSizeとsampleSpaceを使って架空の割合を補いません。responseにある情報と、ない情報をそのまま記録します。

数値とquery条件を同じ記録へ残す

APIから取得した数値だけを表計算へ保存すると、後からsamplingの影響を確認できません。次の項目を一件の実行記録として残します。

  • 実行日時
  • ids
  • start-dateとend-date
  • metricsとdimensions
  • filtersとsegment
  • samplingLevel
  • containsSampledData
  • sampleSizeとsampleSpace

保存したqueryを再実行しても、集計対象のデータが追加または修正されれば、結果が同じになるとは限りません。実行日時とresponseのsampling情報まで残して初めて、二つの結果を比較できます。

定期レポートを外部へ依頼する場合も、完成した表だけでなく、query parameterとsampling情報の保存方法を受け取ります。APIの認証を委託することと、どの条件の数値を経営判断に使うかを任せることは別です。

HIGHER_PRECISIONの結果も条件をそろえて比べる

HIGHER_PRECISIONは、DEFAULTより大きいsample sizeを使い、精度を優先する指定です。「samplingを無効にする」という意味ではありません。responseを見ず、指定名だけで全件集計と判断しないようにします。

二つの結果を比べるときは、次の順に条件をそろえます。

  1. 同じidsを使う
  2. 同じ期間を使う
  3. 同じmetrics、dimensions、filters、segmentを使う
  4. 同じsamplingLevelを使う
  5. sampleSizeとsampleSpaceを確認する

条件が一つ違うqueryを「精度確認」のために並べると、sampling以外の差が混ざります。まず同じqueryのsampling情報を保存し、必要なら期間を分ける、dimensionsを減らすなど、変更点を一つずつ試します。

速度と精度の責任を処理ごとに決める

管理画面へその場で表示する処理では、応答を待たせないことが重要です。月末に保存する広告や売上の照合では、処理時間よりsample sizeを優先する場合があります。一つの設定をすべての処理へ共用せず、用途ごとに決めます。

APIを使う目的は、速いrequestを作ることでも、HIGHER_PRECISIONという値を指定することでもありません。判断に使う数値について、どの条件で、どれだけのsampleから計算されたかを説明できることです。

最初の一手は、既存のAPI responseへcontainsSampledData、sampleSize、sampleSpaceがあるかを確認することです。数値だけを保存しているなら、query条件とsampling情報を同じ行または同じ実行記録へ追加します。

戻る