Googleは、Chrome UX Report(CrUX)に広告負荷を示す4つの実験的指標を追加しました。ユーザーの画面内に広告が何件表示されるか、広告が画面をどの程度占有するか、さらに広告に起因する通信量とCPU処理時間を、実際のChromeユーザーの集計データから把握するものです。
13
これは、広告の「良し悪し」を採点するスコアでも、検索順位への直接的なシグナルとして発表されたものでもありません。パブリッシャー、広告運用担当者、メディアバイヤーが、広告量とユーザー体験の関係を検証するためのベンチマークと考えるのが適切です。
13
4つの広告指標
Googleが示した広告体験の測定軸は、次の4つです。
- Ad Count(広告数):ビューポート、つまりユーザーがその時点で画面に見ている範囲にある広告の平均件数
- Ad Density(広告占有率):ビューポート面積のうち、広告が占める平均割合
- Ad Weight(Network Usage、通信負荷):広告が消費したリソース量をバイト単位で示したもの
- Ad Weight(CPU Usage、CPU負荷):広告が消費した処理リソースをミリ秒単位で示したもの
13
4指標を一緒に見ることで、単に「広告枠が多いか」だけでは分からない違いを切り分けられます。
たとえば、広告数が少なくても、大型の追従広告が画面の大部分を占めればAd Densityは高くなり得ます。逆に見た目が比較的すっきりしていても、複数の広告配信スクリプトや重いクリエイティブを読み込んでいれば、通信負荷やCPU負荷は高くなる可能性があります。小さく軽い広告が多数ある場合は、広告数だけが上がることもあります。
CrUXは何を測っているのか
CrUXは、実際のChromeユーザーがウェブをどのように体験したかを集計したGoogleの公開データセットです。単一端末でのラボテストではなく、端末性能、通信環境、ページのバリエーション、広告配信の差などを含む、実利用環境のデータを反映します。
6
そのため、これらは個別の広告表示、キャンペーン、クリエイティブ、広告枠ごとの診断結果ではありません。サイトまたはページにおいて、ユーザーが全体として遭遇する広告負荷を示す集計シグナルです。
13
なお、4指標はいずれも実験的機能です。Googleは実験的なCrUX指標について、進化に伴って変更される可能性があると説明しています。現時点の数値や利用条件を固定仕様として扱うべきではありません。
12
どこで確認できる?
CrUX API:現在の実ユーザー・データを確認
CrUX APIでは、オリジン単位とページURL単位で、低遅延の集計済み実ユーザー・データを取得できます。オリジンで照会した場合は、そのオリジン配下で対象となるページの体験データが集計されます。十分なデータがある場合、ページURL単位の照会はより具体的です。
5
自社サイトの現状を定点観測したい場合や、社内ダッシュボード・監視基盤にデータを取り込みたい場合に向いています。
CrUX History API:週次トレンドで変化を追う
CrUX History APIは、約6か月分、40個の週次データポイントによる時系列を提供します。オリジン単位・ページ単位の両方をサポートします。
1
11
広告表示数を減らした、第三者の需要パートナーを外した、遅延読み込みの挙動を変えた、重いクリエイティブに制限をかけた――といった変更の前後で、傾向が持続的に動いたかを確認するのに有用です。
CrUX Vis:コードなしで推移をグラフ確認
CrUX Visは、CrUX History APIの週次データを可視化するGoogleのツールです。データセットに含まれるサイトであれば、Ad Metricsページから履歴の変化を手軽に確認できます。
3
Chrome DevTools:原因調査には使えるが、CrUXの代替ではない
Chrome DevToolsは、ローカル環境でページの挙動やパフォーマンス問題を調べ、再現する用途に役立ちます。Googleのリリースノートでは、DevToolsのPerformanceパネルにCrUXのフィールドデータを統合し、ローカルデバッグ時に実ユーザーの問題を文脈化しやすくする取り組みも説明されています。
4
ただし、提供された公式資料だけでは、独立したDevToolsの広告パネルにおける広告帰属の仕様が完全かつ安定的に定義されているとはいえません。さらに、ローカルの1回の計測はCrUXの代わりにはなりません。実ユーザーの端末、回線、同意状態、広告オークション、配信クリエイティブの幅を再現できないためです。まずフィールドデータで継続的な問題を見つけ、次にDevToolsで原因候補を調査する、という使い分けが適しています。
どのサイトがレポート対象になるのか
CrUXは、すべてのサイトやURLを対象にするわけではありません。データセットに含まれるには、対象ユーザー、公開発見可能性、十分な人気・サンプル数など、Googleの適格要件を満たす必要があります。Googleは、掲載を保証する一律のトラフィック閾値を公開していません。
2
10
新しい広告指標については、認定販売者を宣言している適格サイトにレポートが限定されます。業界報道では、この要件はads.txtでの宣言として説明されています。
17
実務上、次の2点に注意が必要です。
- オリジン単位のCrUXデータがあっても、個別URLにはページ単位で報告できるだけの適格な観測数がない場合があります。
- 広告指標が表示されないことは、そのページに広告がない、あるいは広告負荷がないことの証明ではありません。データ量や適格性、報告条件を満たしていない可能性があります。
4指標から読み取れること
| 確認したいこと |
主に見る指標 |
示す内容 |
| 読者の注意を奪う広告はいくつ同時にあるか |
Ad Count |
画面内に同時表示される広告の多さ |
| 画面のどれだけを広告が占めるか |
Ad Density |
ビューポートにおける視覚的な圧迫感 |
| 広告がどれだけ通信量を使うか |
Ad Weight(Network) |
広告に起因するダウンロード・転送負荷 |
| 広告がどれだけ処理資源を使うか |
Ad Weight(CPU) |
ブラウザの処理負荷 |
パブリッシャーにとっては、レイアウトの問題とアドテクノロジーの効率の問題を分けて考えやすくなります。画面内の広告配置を減らせばAd CountとAd Densityに影響しやすく、第三者スクリプトの整理やクリエイティブ要件の見直しは、通信負荷・CPU負荷への影響がより大きい可能性があります。
パブリッシャーと広告主はどう使えるか
Googleはこの指標群を、広告の買い手側・売り手側がオーディエンスの広告負荷を評価するための手段として位置づけています。
15
短期的には、取引価格を直接決めるものというより、運用改善のための利用が明確です。
- パブリッシャー:収益、Core Web Vitals、エンゲージメントなどと並べて広告負荷の推移を監視する
- 広告運用チーム:広告配置ルール、デマンドパス、遅延読み込み、重いクリエイティブの制限を検証する
- メディアバイヤー:低摩擦なユーザー体験がキャンペーン目的の一部である場合、媒体品質やサプライパス評価の一材料として使う
もっとも、指標だけで広告在庫を値付けできるわけではありません。ビューアビリティ、アテンション、オーディエンス適合性、不正、コンバージョン率、ブランド成果は測定していません。これらの数値に連動する業界共通の入札調整、CPM基準、買い手の必須要件がすでに存在するという強い公開根拠もありません。
SEOと検索順位への影響は?
広告負荷が大きく、読み込みが遅くなったり操作への反応が悪くなったりすれば、SEOに間接的な影響を及ぼす可能性はあります。CrUXはもともと実ユーザーのパフォーマンス状況を示すデータであり、新指標は広告がオーバーヘッドの一因になっているかを読み解く文脈を増やします。
6
13
ただし、結論は限定的です。Googleは、Ad Count、Ad Density、Ad Weight(Network)、Ad Weight(CPU)をGoogle検索の直接的なランキングシグナルだとは発表していません。 想定上のランキング閾値を目標に最適化するべきではありません。
実務での進め方
4指標は、診断のためのフィールド指標として扱うのが有効です。
- CrUX APIまたはCrUX Visで、まずオリジン単位のベースラインを確認する。
- データが利用できるURLでは、特定のページテンプレートに問題が集中していないかを見る。
- 画面内の同時広告数を減らす、大型追従広告を制限する、不要な第三者経路を外すなど、変更は一度に一つずつ行う。
- 週次のCrUX History推移を、収益、Web Vitals、自社のエンゲージメント指標と併せて確認する。
- DevToolsでローカル検証を行う。ただし、これはデバッグの証拠であり、実ユーザーのフィールドデータの置き換えではないことを前提にする。
CrUX広告指標の価値は、視覚的な広告の多さとリソースコストを分けて見えるようにした点にあります。これまで広告枠数や合成テストから推測するしかなかった違いを、実ユーザーの集計データで検討しやすくなります。一方で、実験段階かつ集計指標であるため、単独の品質格付け、オークション投入値、SEOルールとしてではなく、根拠に基づく改善テストの道しるべとして使うべきです。
12
13