Google 新推出嘅實驗性 Chrome UX Report(CrUX)廣告指標,令網站嘅廣告負載有一個以真實用戶為基礎嘅觀察角度:畫面同時有幾多個廣告、廣告霸住幾多螢幕位置,以及廣告消耗咗幾多網絡流量同 CPU 資源。
對出版商、廣告買家同網站效能團隊而言,呢套數據可以做比較基準;但佢唔係廣告質素評分,亦未有資料顯示係 Google 自然搜尋嘅直接排名訊號。
13
4 項 CrUX 廣告指標講緊乜?
Google 用以下 4 個維度描述網站嘅廣告體驗:
- Ad Count(廣告數量):視窗範圍(viewport)內平均可見嘅廣告數目。
- Ad Density(廣告密度):廣告佔視窗面積嘅平均比例。
- Ad Weight(Network Usage,網絡用量):廣告消耗嘅資源,以 bytes 計。
- Ad Weight(CPU Usage,CPU 用量):廣告消耗嘅處理資源,以毫秒計。
13
單睇版位數量,往往睇唔到問題核心。舉例:一個網站可見廣告未必多,但如果有個大型黏性廣告(sticky ad)長期霸住畫面,Ad Density 一樣可以好高。相反,版面望落未必好逼,但背後程式化廣告技術堆疊好重,都可能令網絡或 CPU 負載偏高。
亦即係話,多個細小而輕量嘅廣告單位,可能推高 Ad Count,但未必帶來同等程度嘅網絡或運算成本。
CrUX 實際量度嘅係乜?
CrUX 係 Google 公開嘅彙總真實用戶體驗數據集,反映真實 Chrome 用戶喺不同裝置、網絡環境、頁面版本同廣告投放情況之下嘅瀏覽體驗,而唔係一次實驗室效能測試結果。
6
所以,呢啲係網站來源(origin)或網頁 URL 層面嘅整體現場數據,唔係某一次廣告曝光、某個廣告活動、某條創意素材或者某個廣告位嘅獨立成績。佢嘅目的係描述用戶整體遇到嘅廣告負載。
13
4 項指標現時全部都屬於實驗性。Google 表明實驗性 CrUX 指標會隨演進而改動,因此唔應該將今日嘅數值、定義或者可用條件,當成永遠不變嘅規格。
12
去邊度睇數據?
CrUX API:睇目前彙總數據
CrUX API 提供低延遲嘅真實用戶彙總數據,可按 origin 或 page URL 查詢。查 origin 時,會彙總該來源之下合資格網頁嘅體驗;如果某個 URL 有足夠數據,URL 查詢會更具體。
5
如果團隊要為網站建立目前基準,或者將數據接入內部監察、報表系統,CrUX API 會較合適。
CrUX History API:追蹤每星期變化
CrUX History API 提供每星期更新嘅時間序列,約有 6 個月、即 40 個星期數據點;同樣支援 origin 同 URL 層級查詢。
1
11
呢個特別適合用嚟評估改動係咪真係帶來持續效果。例如出版商可以比較:減少同時展示嘅廣告位、移除一個第三方需求夥伴、改變延遲載入策略,或者限制資源消耗高嘅廣告創意前後,指標有冇轉變。
CrUX Vis:毋須寫程式嘅趨勢圖
CrUX Vis 將 CrUX History API 嘅每周數據視覺化,並設有 Ad Metrics 頁面。只要網站喺數據集內,就可以快速查看歷史走勢,毋須自己整 API 整合。
3
Chrome DevTools:適合本機排查,唔可以取代現場數據
Chrome DevTools 可以協助團隊檢查同重現本機頁面嘅效能行為。Google 更新說明亦提到,DevTools Performance 面板已整合 CrUX 現場數據,方便開發者將真實用戶問題放返入本機除錯脈絡去理解。
4
不過,現有文件未有完整而穩定咁界定一個獨立 DevTools 廣告面板嘅歸因細節。更重要係,本機 trace 無法複製真實用戶裝置、網絡、同意狀態、廣告競價結果同創意素材變化嘅分布。較穩陣嘅做法係:先用 CrUX 現場數據確認問題持續存在,再用本機工具追查可能原因。
邊啲網站先會有報告?
唔係每個網站或者每條 URL 都會出現喺 CrUX。要納入數據集,用戶體驗必須符合 Google 嘅資格要求,包括合資格用戶、可公開發現嘅網站來源或網頁,以及有足夠人氣與樣本量。Google 並無公開一條保證納入嘅統一流量門檻。
2
10
至於新廣告指標,報告亦限於已申報授權賣方嘅合資格網站;業界對功能推出嘅報道指,呢項要求涉及 ads.txt 聲明。
17
實務上有兩點要留意:
- 一個 origin 有 CrUX 數據,唔代表底下每條 URL 都有足夠合資格樣本去提供頁面級數據。
- 查唔到廣告指標,唔代表個網頁冇廣告、或者冇廣告負擔;都有可能只係樣本不足,或者未符合報告條件。
4 個數字夾埋睇,先至有診斷價值
| 想問嘅問題 |
最相關指標 |
代表乜 |
| 有幾多廣告同讀者爭注意力? |
Ad Count |
同時可見嘅廣告雜亂程度 |
| 廣告霸咗幾多畫面? |
Ad Density |
視窗內嘅視覺侵入程度 |
| 廣告用咗幾多數據? |
Ad Weight(Network) |
廣告造成嘅下載與傳輸負擔 |
| 廣告用咗幾多運算? |
Ad Weight(CPU) |
瀏覽器處理廣告嘅負擔 |
對出版商而言,呢個分法有助區分:究竟係版面設計問題,定係廣告技術效率問題。減少畫面上嘅廣告位,可能主要拉低數量同密度;精簡第三方腳本、需求路徑或者創意要求,則可能對網絡同 CPU 負載影響更大。
出版商同廣告買家可以點用?
Google 將呢批新數據定位為買方同賣方廣告團隊評估受眾廣告負載體驗嘅工具。
15
短期最清晰嘅用途係營運優化,而唔係直接交易定價:
- 出版商可將廣告負載趨勢,同收益、Core Web Vitals、互動率及其他第一方成效一齊睇。
- 廣告營運團隊可測試版位規則、需求路徑、延遲載入,以及高負載創意政策嘅效果。
- 媒體買家可將指標當成供應路徑或品質評估嘅其中一項資料,尤其係活動重視流暢、低干擾用戶體驗時。
但唔好將佢過度解讀。呢 4 項數據唔量度可視率、注意力、受眾配對、無效流量/欺詐、轉換率或品牌成效。現時亦未有強力公開證據顯示,業界已形成同呢啲欄位掛鈎嘅統一出價調整、CPM 標準或買方硬性要求。
SEO 同搜尋排名:已知同未知嘅界線
廣告體驗太重,有機會間接影響 SEO:如果佢造成載入變慢或互動反應變差,就可能拖累實際用戶體驗。CrUX 原本已可反映真實用戶效能,而新指標令團隊更容易理解廣告係咪其中一個額外負擔來源。
6
13
不過,結論要講清楚:Google 未有表示 Ad Count、Ad Density、Ad Weight(Network)或 Ad Weight(CPU)係 Google Search 嘅直接排名訊號。 唔應該假設有某個排名門檻,然後盲目為咗過線而優化。
實際操作:點樣開始?
可以將 4 項指標視為診斷用嘅現場數據:
- 喺 CrUX API 或 CrUX Vis 為 origin 建立基準線。
- 如有 URL 級數據,再檢查問題係咪集中喺特定頁面模板。
- 每次只做一項受控改動,例如減少同時出現嘅 viewport 廣告、限制大型黏性廣告,或者刪走非必要第三方路徑。
- 用每周 CrUX History 趨勢,連同收益、Web Vitals 同第一方互動數據一齊監察。
- 用 DevTools 本機驗證同除錯,但要記住本機結果係排查證據,唔係真實用戶現場數據嘅替代品。
CrUX 廣告指標最有價值之處,在於將「畫面逼唔逼」同「廣告技術有幾重」兩件以前只能靠版位數或模擬測試估嘅事,拆開咗畀市場睇。由於佢仍屬實驗性,而且只係彙總數據,最適合嘅用法係引導有根據嘅測試,而唔係將佢當成獨立品質評分、競價輸入條件或者 SEO 規則。
12
13