Google AnalyticsのUser Timingsは_trackTiming()で処理時間を分けて測る

Google AnalyticsのUser Timingsは、ページ全体の読み込み時間ではなく、AJAXの応答、画像やJavaScriptの読み込み、ボタンを押してから結果が出るまでなど、自分で始点と終点を決めた処理時間を測る機能です。始点と終点の差をミリ秒で求め、_trackTiming()へ渡します。

計測コードを置くだけでは、何を待った時間なのかは決まりません。先に、利用者が待つ一つの処理を選び、開始条件、完了条件、分類名を固定します。平均時間を見る前に、同じ区間の値が集まっているかを確かめます。

Page TimingsとUser Timingsは測る区間が違う

Site SpeedのPage Timingsは、ページ読み込みに関する時間を自動で集めます。User Timingsは、制作者が指定した処理の経過時間を送ります。

User TimingsのGoogle公式発表は、AJAX処理、特定の画像やCSS、JavaScript、PDFのダウンロード、ファイルのアップロードなどを用途に挙げています。User Timingsを送っても、ページビュー数は増えません。

ページが遅いという問題を調べるなら、Page Timingsで対象ページを絞ります。そのページ内の検索、絞り込み、画像表示など、さらに区間を分けたい場合にUser Timingsを使います。二つの計測を同じものとして合算しません。

_trackTiming()には分類と経過時間を渡す

_trackTiming()のGoogle公式リファレンスは、次の五つの引数を定義しています。

_gaq.push([
  '_trackTiming',
  category,
  variable,
  time,
  opt_label,
  opt_sampleRate
]);

category、variable、timeは必須です。labelとsample rateは必要な場合だけ指定します。検索語、注文番号、時刻のように毎回変わる値を分類名へ入れると、同じ処理の比較が細かく分散します。分類名は、集計後に並べて比べられる粒度で固定します。

始点と終点は利用者が待つ範囲にそろえる

たとえば、商品検索を送信してから、結果を画面へ描画し終えるまでを測るとします。次は構造を示す仮例です。sendSearchRequest()とrenderResults()は、実際のサイトに合わせて実装する関数です。

var searchStartedAt;

function startSearch() {
  searchStartedAt = new Date().getTime();
  sendSearchRequest(showResults);
}

function showResults(response) {
  renderResults(response);

  var elapsed = new Date().getTime() - searchStartedAt;

  if (elapsed > 0 && elapsed < 60000) {
    _gaq.push([
      '_trackTiming',
      'Site Search',
      'Results Ready',
      elapsed,
      'Product Search'
    ]);
  }
}

通信だけを測るのか、結果の描画まで含めるのかで値は変わります。開始を検索ボタンの操作、終了を画面表示の完了に置けば、利用者が待つ範囲に近づきます。サーバー処理だけを知りたいなら、ブラウザーで得た経過時間から原因を断定せず、サーバー側の記録を別に調べます。

同時に複数の処理を走らせる場合、一つの開始時刻を使い回しません。公式ガイドも、処理ごとに開始時刻と終了時刻を保持するよう案内しています。別の処理が開始時刻を上書きすると、正しい差を送れなくなります。

異常な時間を送る前に範囲を確認する

開始時刻と終了時刻の差が負数になったり、想定外に大きくなったりすると、少数の値でも平均を大きく動かします。User TimingsのGoogle公式実装ガイドは、経過時間が0より大きく、決めた上限より小さいことを確かめてから送る例を示しています。

上限は、計測する処理に合わせて決めます。検索結果が一分を超えたら失敗として別に記録する運用なら、一分未満だけをUser Timingsへ送る方法があります。ただし、遅い処理を都合よく除外して平均を良く見せないよう、除外条件と失敗件数を別に残します。

平均時間とUser Timing Sampleを一緒に読む

User TimingsのExplorerでは、Avg. User TimingとUser Timing Sampleを確認できます。APIへ渡すtimeはミリ秒ですが、平均時間は秒で表示されます。User Timing Sampleは平均の基になった標本数です。

平均が短くても、標本が数件しかなければ、すべての利用者に同じ傾向があるとは判断できません。平均値だけで順位を付けず、同じ期間、同じcategoryとvariableについて、平均時間と標本数を並べます。Performanceでは時間帯ごとの分布を見て、一部の極端に遅い処理が平均へ混ざっていないかを確かめます。Map Overlayやブラウザーの分類を使う場合も、分けた後の標本数を確認します。

sample rateは検証と通常運用で分ける

User Timingsは、標準ではSite Speedと同じ割合で標本を送ります。公式実装ガイドが示す標準値は、訪問者の1％です。低トラフィックのテストでは、opt_sampleRateを100にして送信を確認できます。_setSiteSpeedSampleRate()を使うと、User Timingsを含むSite Speed全体の割合が変わります。

_gaq.push(['_setSiteSpeedSampleRate', 100]);

100％は、必ず使う設定ではありません。_trackTiming()の各送信は、一訪問あたり500 hitという共通上限へ数えられます。画面内の細かな処理をすべて送るのではなく、改善判断に使う一つか二つの区間から始めます。

最初に一つの処理について、開始、完了、異常値の上限、category、variable、labelを表にします。テスト環境で送信とレポート分類を確認してから、通常運用のsample rateを決めます。実装を外部へ頼んでも、何を待ち時間として測るか、分類名を誰が変更できるか、測定結果をどの改善判断に使うかは事業者側で残します。