--- title: "Header bidding 是什麼？publisher 典型多賺一到三成，月 35 萬 PV 以下不值得做｜廣告的錢流" url: https://joelin.cc/p/9761 source: https://joelin.cc/p/9761 id: 9761 slug: "header-bidding-explained" pubDate: 2026-09-14 date_modified: 2026-09-14 updatedDate: 2026-09-14 schema_type: BlogPosting description: "Header bidding 把瀑布式的依序問價換成同時競價，產業引用的增幅約一到三成，行情具時效性。本文拆解它多賺在哪裡、腳本變重與維運成本的代價，以及用月 35 萬頁面瀏覽這道門檻判斷值不值得導入。" ai_summary: "Header bidding 是在頁面載入時同時向多個需求源要價、價高者得的競價機制，用來取代依歷史平均 eCPM 排序、先問先得的瀑布式（waterfall）。產業引用的收益增幅約一到三成（行情具時效性），來源多為需求方平台或代管商自述案例；增幅來自把排序換成價格發現，不是多接買方，因此邊際效益遞減。代價有三：腳本重會拖慢 LCP 與 INP，而速度是排名因子；接多個需求源是經常性維運成本；量體不足的站買方不會認真出價（程式化多為整包採買）。以 joelin.cc 實測頁面 RPM US$0.890、匯率 32 回算，月 35 萬頁面瀏覽對應每月 NT$1 萬量級，此量級以下優化 header bidding 邊際效益很低，月 351 萬頁面瀏覽（每日約 11.7 萬）以上才值得做。該站廣告請求媒合率 68.0%，較 2025 年的 81.8% 下降 17%，同期 eCPM 卻上升 15%，顯示填充率下降不等於需求源不足。程式化 publisher 實收約每千次曝光 NT$7–27，直售內容網站牌價 NT$300–500，一到三成的增幅是在第四層之內移動。本文作者未實際導入過 header bidding，內容為機制說明與判斷準則，非操作經驗。" key_facts: ["header bidding 讓 publisher 多賺的產業引用增幅約為一到三成，行情具時效性", "瀑布式排序依歷史平均 eCPM 決定問價順序，出價最高的買方可能整天輪不到被問", "以實測頁面 RPM US$0.890、匯率 32 回算，月 35 萬頁面瀏覽對應每月約 NT$1 萬廣告毛收入", "程式化廣告的 publisher 實收約每千次曝光 NT$7–27，直售內容網站牌價為 NT$300–500", "joelin.cc 實測廣告請求媒合率為 68.0%，較 2025 年的 81.8% 下降 17%，同期 eCPM 反而上升 15%", "ISBA 與 PwC 2020 年研究顯示廣告主每付出 1 元平均只有 51% 到達 publisher，其中 15% 連歸屬都查不到"] categories: ["數位廣告"] tags: ["廣告的錢流", "廣告變現", "程式化廣告", "網站經營"] authorship: origin: written ai_role: assist entity_ids: author: https://me.joelin.cc/#joe publisher: https://me.joelin.cc/#joelincc --- # Header bidding 是什麼？publisher 典型多賺一到三成，月 35 萬 PV 以下不值得做｜廣告的錢流 ## 摘要 Header bidding 是在頁面載入時同時向多個需求源要價、價高者得的競價機制，用來取代依歷史平均 eCPM 排序、先問先得的瀑布式（waterfall）。產業引用的收益增幅約一到三成（行情具時效性），來源多為需求方平台或代管商自述案例；增幅來自把排序換成價格發現，不是多接買方，因此邊際效益遞減。代價有三：腳本重會拖慢 LCP 與 INP，而速度是排名因子；接多個需求源是經常性維運成本；量體不足的站買方不會認真出價（程式化多為整包採買）。以 joelin.cc 實測頁面 RPM US$0.890、匯率 32 回算，月 35 萬頁面瀏覽對應每月 NT$1 萬量級，此量級以下優化 header bidding 邊際效益很低，月 351 萬頁面瀏覽（每日約 11.7 萬）以上才值得做。該站廣告請求媒合率 68.0%，較 2025 年的 81.8% 下降 17%，同期 eCPM 卻上升 15%，顯示填充率下降不等於需求源不足。程式化 publisher 實收約每千次曝光 NT$7–27，直售內容網站牌價 NT$300–500，一到三成的增幅是在第四層之內移動。本文作者未實際導入過 header bidding，內容為機制說明與判斷準則，非操作經驗。 ### 重點 - header bidding 讓 publisher 多賺的產業引用增幅約為一到三成，行情具時效性 - 瀑布式排序依歷史平均 eCPM 決定問價順序，出價最高的買方可能整天輪不到被問 - 以實測頁面 RPM US$0.890、匯率 32 回算，月 35 萬頁面瀏覽對應每月約 NT$1 萬廣告毛收入 - 程式化廣告的 publisher 實收約每千次曝光 NT$7–27，直售內容網站牌價為 NT$300–500 - joelin.cc 實測廣告請求媒合率為 68.0%，較 2025 年的 81.8% 下降 17%，同期 eCPM 反而上升 15% - ISBA 與 PwC 2020 年研究顯示廣告主每付出 1 元平均只有 51% 到達 publisher，其中 15% 連歸屬都查不到 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 這類架構才談得上導入。 | 比較項 | 瀑布式（waterfall） | header bidding | | --- | --- | --- | | 需求源怎麼被問 | 依序問，一層問完再問下一層 | 同時問，名單上每家都收到請求 | | 比價的依據 | 各家的歷史平均 eCPM | 各家對這一次曝光的實際出價 | | 誰會得標 | 第一個接受底價的需求源 | 出價最高的需求源 | | 有沒有人被跳過 | 有，排後面的可能整天輪不到 | 沒有，名單內每家都會被問到 | | 延遲怎麼累積 | 每層 timeout 相加 | 單一 timeout 上限，平行等待 | | 維運複雜度 | 低，後台調順序即可 | 高，每個需求源一組 adapter | 這張表的重點在第二列與第三列：瀑布式用「過去的平均」決定誰先被問，header bidding 用「這次的出價」決定誰得標，前者是排序問題，後者是價格發現問題；其餘幾列都是這個差別的後果——得標者換了人，代價是複雜度與腳本重量同時上升。 ## 為什麼典型增幅是一到三成：多了一場競價，不是多了一層排序 一到三成是產業引用值，行情具時效性，來源多半是需求方平台或代管商的自述案例，缺少獨立佐證。當量級參考可以，當承諾不行。 增幅從哪裡來才是重點。導入之後，成交價不再等於「第一個願意接受底價的人所接受的那個底價」，而是被第二高的出價往上推——價格發現做過一次，就會把被歷史平均壓住的高價值曝光釋放出來。 增幅來自換一種定價方式、不是多接幾家買方，邊際效益因此這樣遞減： - 從瀑布式換成競價的那一次是唯一一次性質上的改變，貢獻最大。 - 接進來的第二到第四個需求源會繼續把清算價往上推，幅度一次比一次小。 - 接到第八個需求源多半只是增加請求數與延遲，因為同一批買方常透過不同 SSP 重複出現，名義上的「多一家」不是新的競爭者。 還有一個容易被誇大的地方：這一到三成是在程式化這條路徑之內的移動。 | 層 | 每千次曝光（NT$） | | --- | --- | | ① 直售牌價 | 入口網站 200–300；內容網站 300–500 | | ② 直售實際成交 | 常掉到約 60 或更低 | | ③ 程式化買方支付 | Google 展示型約 10–40；Meta 約 20–80 | | ④ 程式化 publisher 實收 | 約 7–27 | 這四層是台灣市場 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,000 | 約 3.5 萬 | 約 1,200 | | NT$10,000 | 約 35 萬 | 約 1.2 萬 | | NT$100,000 | 約 351 萬 | 約 11.7 萬 | | NT$200,000 | 約 702 萬 | 約 23 萬 | 這張表是廣告毛收入，主機、內容生產與人力都還沒扣，所以是下限不是預期值。把一到三成套在每一級上自己乘一次就知道值不值得——同樣的比例放在 NT$1 萬和 NT$10 萬那兩級，金額差一個數量級，維運成本卻幾乎一樣。門檻就來自這個不對稱：收益隨流量線性放大，複雜度是固定的。 判斷門檻可以這樣切： - 月頁面瀏覽在 35 萬以下的站，優化 header bidding 的邊際效益很低，該動的是流量本身與版位配置，還有哪些槓桿、哪個先做，見 /p/9765。 - 月頁面瀏覽在 35 萬到 350 萬之間的站可以評估，但導入前要先確認收益的四個因子裡卡住的是哪一格，別一上來就假設問題出在需求源不夠。 - 月頁面瀏覽在 350 萬以上（每日約 11.7 萬）的站值得做，這個量級通常已有直售業務可跟程式化互相墊價；再往上的每日 23 萬已是台灣大型媒體量級。 ## 媒合率 68% 的教訓：填充率不足時，先檢查的不一定是需求源數量 我站上實測的廣告請求媒合率是 68.0%。直覺的讀法是：三成多的請求沒賣掉代表買方不夠，該多接需求源，而 header bidding 正好是「多接需求源」的標準答案。但把同期的其他因子攤開，這個推論站不住。 | 因子 | 2025 舊期 | 現行 | 變化 | | --- | --- | --- | --- | | 每次瀏覽廣告數 | 4.47 | 3.94 | −12% | | 點閱率 | 0.313% | 0.467% | +49% | | 每次點擊價格 | US$0.0625 | US$0.0484 | −23% | | eCPM | US$0.196 | US$0.226 | +15% | | 頁面 RPM | US$0.876 | US$0.890 | +1.6% | | 媒合率 | 81.8% | 68.0% | −17% | 媒合率從 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 ## 常見問題 ### header bidding 是什麼？ 它是在頁面載入時同時向多個需求源發出競價請求、由出價最高者得標的機制，用來取代瀑布式（waterfall）依歷史平均 eCPM 排序、一層層依序問價的做法。差別在於瀑布式問「你要不要接受這個底價」，header bidding 問「你願意出多少」。 ### header bidding 真的能讓網站多賺一到三成嗎？ 一到三成是產業引用值，行情具時效性，來源多半是需求方平台或代管商的自述案例，缺少獨立逐日資料佐證。增幅的來源是把排序換成真正的競價，所以第一次導入貢獻最大，之後每多接一個需求源效果都遞減。 ### 小站適合用 header bidding 嗎？ 月頁面瀏覽 35 萬以下的站不建議。以頁面 RPM US$0.890 回算，這個量級對應每月約 NT$1 萬的廣告毛收入，一到三成的絕對金額有限，維運成本卻跟大站幾乎一樣；而且程式化買方多是整包採買，不會為少量流量認真出價。 ### header bidding 會讓網站變慢嗎？ 會。每個需求源要載入自己的 adapter，競價本身也佔用等待時間，且都落在頁面載入最早期，會影響 LCP 與 INP，廣告版位延後撐開也容易造成版面位移。速度是排名因子，但更直接的風險是讀者跳出讓頁面瀏覽數下降。 ### 廣告填充率低，是不是該多接幾家需求源？ 不一定。媒合率的分母是廣告請求數而非收益，請求發得多媒合率自然難看。實測上媒合率從 81.8% 掉到 68.0% 的同期，eCPM 反而上升 15%、頁面 RPM 也微幅上升。建議先檢查底價是否設太高、版位有沒有製造賣不掉的請求，最後才動需求源數量。