Header bidding 是什麼？publisher 典型多賺一到三成，月 35 萬 PV 以下不值得做｜廣告的錢流

Header bidding 是在頁面載入時同時向多個需求源要價、由出價最高者得標的競價機制，用來取代早期的瀑布式（waterfall）依序問價。產業普遍引用的收益增幅落在一到三成（行情具時效性）。它多賺的錢不是來自多接了幾家買方，而是來自把「排序」換成「競價」——瀑布式依歷史平均排順序、先問的先得，所以對這一次曝光願意出最高價的買方，可能根本沒被問到。

代價同樣真實，而且是三種不同性質的成本：

• 腳本變重會拖慢載入，而速度本身是排名因子。
• 接多個需求源是持續的維運成本，不是一次性設定。
• 量體不夠的站，需求源不會為你的流量認真出價。

用我站上實測的頁面 RPM 回算流量階梯，月 35 萬頁面瀏覽以下的站，優化這一項的邊際效益很低。

先說本文的資料邊界

我自己沒有在自有站台上跑過 header bidding。我有的是三年逐日的站台收益資料，以及投手時期在買方那一側的經驗——足以判斷它值不值得做，不足以讓我假裝裝過。所以這篇是機制說明與判斷準則，不是安裝教學，也不會出現「我裝了之後漲多少」。看到有人用第一人稱講漲幅，值得先問他的分母是什麼、資料期間多長。

瀑布式：先問的先得，所以出價高的可能沒被問到

瀑布式是 header bidding 之前的主流做法：ad server 手上一張需求源清單，依各家歷史平均 eCPM 由高到低排序，一層一層往下問「願不願意用這個底價買」，不要就問下一家，問到有人接受為止。

問題出在排序的依據。歷史平均 eCPM 把所有曝光混在一起算，但每一次曝光的價值差很多——同一個版位，一般讀者和被 retargeting 鎖定的購物車放棄者，值的錢可以差好幾倍。某家需求源平均起來不高，卻可能對這一次的這個讀者願意出遠高於平均的價格。瀑布式看不到，因為它問的是「你要不要接受這個底價」，不是「你願意出多少」。

結果就是結構性的浪費：

• 排在後面的需求源可能整天輪不到被問，即使它對特定曝光的出價比前面幾家高。
• 成交價只證明得標者願意付到底價，不證明他不願意付更多。
• 每一層都要等自己的 timeout，讀者的等待是一層層相加的。

這不是有人在偷錢，是機制本身把錢留在桌上。至於錢流裡誰是誰、各拿走多少，見 /p/9760。

header bidding：同時問價，價高者得

header bidding 把問價搬到頁面載入的早期（通常放在 HTML 的 header，名字由此而來），同時對名單上所有需求源發出競價請求，設一個統一 timeout，時間到就比價，最高的那個才送進 ad server，跟直售訂單與 Google 自家的需求一起競爭。

實作分瀏覽器端與伺服器端：瀏覽器端（開源的 Prebid.js 最常見）跨網域身分比對完整、出價較高，代價是腳本壓在讀者的瀏覽器上；伺服器端快很多，但身分比對掉一截、出價較低。另一個常被略過的前提是競價結果需要 ad server 來接——只掛 AdSense 的站得先換成 Google Ad Manager 這類架構才談得上導入。

這張表的重點在第二列與第三列：瀑布式用「過去的平均」決定誰先被問，header bidding 用「這次的出價」決定誰得標，前者是排序問題，後者是價格發現問題；其餘幾列都是這個差別的後果——得標者換了人，代價是複雜度與腳本重量同時上升。

為什麼典型增幅是一到三成：多了一場競價，不是多了一層排序

一到三成是產業引用值，行情具時效性，來源多半是需求方平台或代管商的自述案例，缺少獨立佐證。當量級參考可以，當承諾不行。

增幅從哪裡來才是重點。導入之後，成交價不再等於「第一個願意接受底價的人所接受的那個底價」，而是被第二高的出價往上推——價格發現做過一次，就會把被歷史平均壓住的高價值曝光釋放出來。

增幅來自換一種定價方式、不是多接幾家買方，邊際效益因此這樣遞減：

• 從瀑布式換成競價的那一次是唯一一次性質上的改變，貢獻最大。
• 接進來的第二到第四個需求源會繼續把清算價往上推，幅度一次比一次小。
• 接到第八個需求源多半只是增加請求數與延遲，因為同一批買方常透過不同 SSP 重複出現，名義上的「多一家」不是新的競爭者。

還有一個容易被誇大的地方：這一到三成是在程式化這條路徑之內的移動。

這四層是台灣市場 2026 年 9 月的查證值，行情具時效性。要看的是第四層與第一層的距離：header bidding 讓你在第四層約 NT$7 到 27 的區間裡往上移動一到三成，那是真的收益，但不會把你移到第一層——兩邊的價差主因不是平台抽成，而是賣的是不同的產品，這題在 /p/9763 有拆解。中間層的損耗也動不到：ISBA 與 PwC 2020 年的研究算出廣告主每付出 1 元平均只有 51% 到達 publisher，其中 15% 連歸屬都查不到。

代價一：腳本變重，而速度本身是排名因子

每個需求源都要載入自己的 adapter，競價本身還要佔用等待時間，而這些成本全落在讀者的瀏覽器上、落在載入的最早期——header bidding 之所以有效，正是因為它跑得早。三個被影響的地方性質各異：

• LCP（最大內容繪製）因為主執行緒被競價腳本佔用而延後，讀者看到主要內容的時間變晚。
• INP（互動到下次繪製）因為腳本卡住主執行緒而變差，體感就是點下去沒反應。
• CLS（累計版面位移）跟競價不直接相關，但版位在競價結束後才撐開是位移來源，導入時要處理保留高度。

速度是排名因子這件事 Google 講得很清楚，只是權重不大。更直接的風險在後面一層：頁面慢了，讀者跳掉，頁面瀏覽數下降。收益等於流量乘以 RPM，RPM 漲兩成而流量掉兩成就是白忙，評估時要把兩邊乘起來看，不能只盯 RPM 那一格。

代價二：接越多需求源，維運成本越高

這是經常性成本，不是一次性設定。接一家需求源不是打個勾就好，而是多了一份合約、一套計價口徑、一個付款週期，和一個會壞掉的東西。具體會長出來的工作包括：

• 各家需求源的報表口徑與付款週期都不一致，有的報 gross 有的報 net、NET 60 與 NET 90 混著走，對帳與現金流都要另外花時間對齊。
• timeout 要持續調整，設短了高價需求源來不及回，設長了讀者等太久。
• adapter 壞掉不會有人通知你，症狀是 RPM 慢慢往下掉，通常對帳那天才發現。

這些事在大站有人專職處理，在個人站就是你自己的時間。該問的不是「多接一家會不會多賺」，而是「多接一家每月花我幾小時，這幾小時放在別處會不會賺更多」。

代價三：需求源不會為了少量流量認真出價

這一條是我在買方那一側看得最清楚的。小站導入後常見的失望不是裝壞了，而是名單上的需求源根本沒認真出價。

我以前在買方那邊的經驗是，程式化的買法本身就不是逐站挑的：「他們買的策略大多是 retargeting，其他一般不太會去做 prospecting 或是受眾探索、lookalike，因為 performance 太差。……通常是一次買一整包，因為垃圾網站真的太多了。」

一次買一整包的意思是，你的站在買方的清單裡是被打包的一格，不是被個別評估與出價的對象。買方也沒有動機為單一小站細緻估價：「以投放的角度來說，其實不太會介意它有沒有變貴，因為你看的是 performance-driven 或 return on ad spend（ROAS）這種成效結構，根本沒那麼在意 CPM。」

所以「多接需求源就會產生競價壓力」這個推論，在量體不足的站上不成立——競價要有壓力，前提是至少有兩家對這一次曝光真的想要。量不夠的時候，你架了競價場，場上只有一個人舉牌。

什麼量級的站值得做

用我站上實測的頁面 RPM US$0.890、匯率 32 回算，可得一張流量與收入的對照階梯。它是等比例線性外推，換個 RPM 假設整排就跟著變（RPM 到 US$1.5 時所需流量約 0.59 倍，到 US$3.0 時約 0.30 倍）。

這張表是廣告毛收入，主機、內容生產與人力都還沒扣，所以是下限不是預期值。把一到三成套在每一級上自己乘一次就知道值不值得——同樣的比例放在 NT$1 萬和 NT$10 萬那兩級，金額差一個數量級，維運成本卻幾乎一樣。門檻就來自這個不對稱：收益隨流量線性放大，複雜度是固定的。

判斷門檻可以這樣切：

• 月頁面瀏覽在 35 萬以下的站，優化 header bidding 的邊際效益很低，該動的是流量本身與版位配置，還有哪些槓桿、哪個先做，見 /p/9765。
• 月頁面瀏覽在 35 萬到 350 萬之間的站可以評估，但導入前要先確認收益的四個因子裡卡住的是哪一格，別一上來就假設問題出在需求源不夠。
• 月頁面瀏覽在 350 萬以上（每日約 11.7 萬）的站值得做，這個量級通常已有直售業務可跟程式化互相墊價；再往上的每日 23 萬已是台灣大型媒體量級。

媒合率 68% 的教訓：填充率不足時，先檢查的不一定是需求源數量

我站上實測的廣告請求媒合率是 68.0%。直覺的讀法是：三成多的請求沒賣掉代表買方不夠，該多接需求源，而 header bidding 正好是「多接需求源」的標準答案。但把同期的其他因子攤開，這個推論站不住。

媒合率從 81.8% 掉到 68.0%，同期 eCPM 反而上升 15%、頁面 RPM 也微幅上升。媒合率掉了而收益沒掉，代表掉的那些請求本來就賣不出好價錢，或者請求的發送結構變了——每次瀏覽的廣告數從 4.47 降到 3.94，分子與分母同時換過一輪。

媒合率的分母是廣告請求數，不是收益。同一份收益除以請求數是請求 RPM US$0.121，除以實際曝光數是曝光 RPM US$0.226——同樣的錢，換個分母就差快一倍。分母怎麼選會如何改變結論，/p/9759 有拆解。

所以填充率不足時，檢查的順序是這樣：

• 先確認底價（floor price）是不是設得太高，把願意出中間價位的買方擋在門外。
• 再確認版位配置有沒有製造出賣不掉的請求，例如首屏外的版位發了請求，讀者卻沒捲到。
• 接著看四因子恆等式哪一格在動——頁面 RPM 等於每次瀏覽廣告數乘以點閱率乘以每次點擊價格再乘以一千。
• 最後才問需求源數量夠不夠。它排最後不是因為不重要，而是它成本最高、最難退回去。

結論：它是真的有效，但門檻比宣傳裡高

header bidding 解決的是真實而且結構性的問題：瀑布式用歷史平均決定問價順序，必然漏掉對特定曝光願意出高價的買方，這個浪費只能靠換成真正的競價解決。一到三成有它的道理，不是行銷話術。

但它同時是一筆持續的技術與維運支出，收益卻跟流量量體成正比——收益線性、複雜度固定，所以同一個工具在大站是必備品、在小站是負擔。月 35 萬頁面瀏覽以下的站，把力氣放在內容與流量上回報明確得多；等流量撐得起這個複雜度再回頭處理競價，那時候的一到三成才算得上一筆錢。

本文關鍵字：header bidding、瀑布式廣告、廣告填充率、程式化廣告、頁面 RPM