ads.txt 四個欄位在防什麼：加上 sellers.json 才構成買方能驗證的賣方鏈｜廣告錢流

ads.txt 與 sellers.json 防的是冒名：有人拿低品質網站的流量，在競價請求裡宣稱那是你的網域，買方以為買到你的版位，拿到的是別人的垃圾庫存。

ads.txt 是你這一端的授權名單，sellers.json 是中間商那一端的身分名冊，兩份合起來，買方才能一段一段驗證這批庫存是誰有權賣的。

它們回答誰有權賣，不回答每一手抽走多少——那是另一個問題，後面拆開講。

對內容站主來說，這兩個檔案不是技術細節，是收入的開關。設定錯誤不會讓網站壞掉、不會跳錯誤訊息，只會讓一部分需求方看完清單後安靜地不出價。

ads.txt 是什麼：放在網域根目錄的一份公開授權白名單

ads.txt 是一個純文字檔，位置固定在網域根目錄，也就是 https://你的網域/ads.txt，任何人打開都看得到，買方的爬蟲也是這樣讀它。它不是設定檔、不改變網站行為，唯一作用是對外宣告一句話：哪些對象有權賣我的廣告版位。

典型的一筆記錄長這樣：

google.com, pub-0000000000000000, DIRECT, f08c47fec0942fa0

一行一筆記錄，欄位用逗號分隔，# 開頭的行是註解。四個欄位分別是：

四個欄位合起來是一句完整的授權句：我授權第一欄那個廣告系統，以第二欄那個帳號的身分，用第三欄指定的關係，銷售我的廣告版位。第一欄最容易誤解——很多人以為那裡填自己的網站，實際上填的是買方要去哪裡競價才會撞到你的庫存。

DIRECT 與 RESELLER 的差別，是你在替誰背書

第三欄只有兩個值，但它們的責任完全不同：

• DIRECT 代表第二欄那個帳號由你自己直接控制，你跟那個廣告系統之間有直接的商業關係。
• RESELLER 代表你授權了另一個對象，讓它拿那個帳號去轉售你的版位。

差別不在寫法，在你背書的對象。寫 DIRECT，宣告的是「這是我自己的帳號」；寫 RESELLER，宣告的是「我同意另一家公司拿這個帳號來賣我的東西」。買方看的就是這個宣告，你怎麼寫，它就怎麼信。實務判準很簡單：沒在那個系統開過帳號、ID 是別人給你的，就不是 DIRECT。把 RESELLER 寫成 DIRECT 不是筆誤，是把授權範圍講錯了。

它防的是 domain spoofing：買方不會一個一個看你的站

domain spoofing 的機制很簡單：競價請求裡有一個欄位標示這次曝光發生在哪個網域，而那個欄位是賣方那一側填的。靠機器流量灌出來的網站，可以在請求裡把自己寫成知名媒體的網域，用那個身分去要價。買方看到的只是一串宣稱，在 ads.txt 出現之前，沒有獨立來源可以對照它是真是假。

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

一次買一整包，意思是沒有人會為了你這個站台停下來人工查證。「這個網域授權了誰」因此必須變成機器讀得懂、買方自己查得到的東西。放在你網域根目錄的純文字檔正好滿足兩個條件：它一定在你的網域上，只有控制那個網域的人寫得了；它是公開的，任何買方都能去抓。

驗證邏輯因此很單純。買方收到一筆聲稱來自你網域的請求，去抓你的 ads.txt，比對「送出請求的廣告系統網域 ＋ 請求裡帶的賣方帳號 ID」這個配對有沒有在清單裡。沒有，就是未授權，丟掉。

要說清楚的是，ads.txt 證明授權，證明不了品質——內容很爛的網站照樣寫得出格式正確的 ads.txt。它擋的是冒用別人身分，不是廣告詐騙的全部。

sellers.json 是另一端：中間商公布自己代表哪些賣方

ads.txt 只解決了鏈的第一段。那個廣告系統轉手給下一個中間商之後呢？請求上掛著的賣方 ID 背後是哪家公司、是內容方還是中間商，ads.txt 不回答。

sellers.json 回答這一段。它是一個 JSON 檔，位置在 https://廣告系統的網域/sellers.json，由廣告系統自己發布。先講明白：這份檔案不是你要做的，除非你自己也在轉售別人的庫存，否則內容站主不需要有 sellers.json。它的核心是一個賣方陣列，每一筆對應一個賣方帳號：

• seller_id 對應的就是你 ads.txt 第二欄那個發布商 ID，這是兩份檔案能接起來的接點。
• name 與 domain 是這個賣方帳號背後的公司名稱與業務網域。
• seller_type 標示這個賣方是 PUBLISHER（賣自己的庫存）、INTERMEDIARY（轉售別人的）或 BOTH。
• is_confidential 設為 1 時，這一筆可以不公布名稱與網域。
• is_passthrough 標示這個帳號不是實際收款的對象。

is_confidential 是這套機制自己承認的一個洞：它允許一筆賣方紀錄只留 ID、不留身分，所以「每一跳都查得到是誰」在實務上不是百分之百成立。知道這個洞存在，比相信這條鏈密不透風要有用。

完整的鏈其實是三件東西拼起來的

兩個檔案是靜態的參照資料，真正描述「這一次曝光走了哪條路」的是第三樣東西：

1. ads.txt 由你發布，說明你授權了哪些對象賣你的版位。
2. sellers.json 由每一個廣告系統發布，說明它系統裡的每個賣方 ID 對應到哪個實體。
3. 競價請求裡的 SupplyChain 物件記錄這次的實際路徑，每一跳記下廣告系統識別碼與賣方 ID，並標示這條鏈是否完整。

買方照著 SupplyChain 一跳一跳走：每一跳的廣告系統對應一份 sellers.json，用該跳的賣方 ID 查出它是誰；走到最源頭那一跳，再回頭比對你的 ads.txt 有沒有授權這個配對。三樣都對得上，這筆庫存才算來源可追溯。ads.txt 是起點的簽名，sellers.json 是沿途關卡的身分證，SupplyChain 是這趟的行程記錄。想看供應鏈上每個角色在做什麼，可以參考這條鏈上誰是誰。

對站主的實務含意

檔案存在卻漏掉一行，比完全沒有檔案更傷

這是最反直覺的一點：一份 ads.txt 一旦存在，就會被當成完整清單讀。買方的判定不是「有沒有提到這個賣方」，而是「有沒有在清單裡」——沒列到就等於明確地沒有授權。

所以「沒有檔案」和「有檔案但漏掉你正在用的那個聯播網」在買方眼中是兩件事。前者是你沒宣告過任何事，後者是你宣告了，而且宣告的內容是「這個賣方我沒授權」。第二種情況會讓部分需求方直接不出價，等於你自己砍掉一部分收入。

這種漏法最麻煩的是無聲無息：版位照樣出現、請求照樣送出、後台照樣有數字，只是競價的人少了一群。AdSense 後台對此有專門的提示，大意是收益有風險、ads.txt 裡找不到你的發布商 ID。看到那個提示就是真的在漏錢，不是建議事項。

聯播網要你加一行時，你該問的三件事

聯播網給你一行字要你貼進 ads.txt，那不是註冊碼，是一份授權書。加之前值得確認：

• 那個帳號 ID 是不是你自己在該系統申請的。是，才寫得了 DIRECT；不是，就只能是 RESELLER。
• 對方要你加的如果是一整段十幾行，那多半是它的上游轉售鏈。等於你一次授權一整排沒查過的對象，而且每一行都是獨立有效的授權。
• 這一行的壽命比合作關係長。它沒有到期日，不會因為你停止合作而自動失效。

判準可以簡化成一句話：你授權的是那個帳號，不是那一次測試。

測試完的那一行，要不要移除

要移除，理由不是整潔。留著的後果是：那個賣方帳號仍然被你授權，任何能操作它的人都可以合法銷售你的庫存，買方驗證還會通過——因為你確實授權了。中間商被入侵、帳號轉手、公司被併購，這份授權都跟著走。累積一兩年之後你自己也講不出每一行是誰，那份清單就不再能拿來做判斷。

移除時要知道兩件事。改動不是即時生效，買方照自己的排程重新爬取，通常是每天量級的頻率，刪掉後還有一段餘量期；而移除只影響之後的競價，不影響已產生的收益結算。

多個子網域的情況

子網域的規則實際上只有三條：

• 買方爬的是根網域那一份，子網域預設沿用根網域的授權，不需要每個子網域各放一份。
• 要讓某個子網域有獨立的一套授權，做法是在根網域的檔案裡用 SUBDOMAIN= 指出它，爬蟲才會再去抓那份。
• 內容放在別人的子網域上（平台型服務）時，根目錄不歸你管，適用的是平台那份檔案，上面列的通常是平台自己的賣方帳號。

手機 App 有對應的 app-ads.txt，放在商店頁面所登記的開發者網站上，判準一樣、檔名不同。規格後續版本另外新增了幾個變數處理所有權與代管，例如宣告版位擁有者業務網域的 OWNERDOMAIN、宣告代管變現方的 MANAGERDOMAIN。個人站台多半用不到，但站交給代操團隊在賣時，這幾個變數就是講清楚「誰擁有、誰在賣」的地方。

這條鏈只存在於程式化那一側

直售不走這條鏈。跟品牌直接談、直接上版位，中間沒有競價、沒有 SupplyChain 物件，ads.txt 也不參與判定——沒有第三方需要驗證你是不是你。我以前在買方那邊的經驗是：「advertiser 的話通常也不怕被 share，他們看的肯定是 premium buy，也就是直接買版位的方式。一般來說，他們在意的只是在哪個版位、哪個時間點能拿到什麼樣的品牌 output。」

直售買的是指定的版位與時間，賣方是誰從一開始就談好了，不需要機器可讀的白名單去證明。兩種賣法的價差有多大，我另外整理在直售與程式化的價差。

透明度檔案解決的是「錢流向誰」，不是「錢被抽多少」

這是最容易被混為一談的一段：

• ISBA 與 PwC 2020 年的程式化供應鏈透明度研究顯示，廣告主每付出 1 元，平均只有 51% 到 publisher 手上，其中 15% 是連歸屬都查不到的 unknown delta。
• 同一組研究 2022 年的第二次調查，到 publisher 的比例改善約 8 個百分點，unknown delta 降到 3%。
• 美國 ANA 的研究數字相近：51% 到 publisher、34% 是揭露的費用、15% 不明。業界通稱這整段落差為 adtech tax。

兩個數字要分開讀。51% 講的是被抽掉多少，15% 降到 3% 講的是查不查得到是誰抽的。透明度檔案改善的是後者。一條每一跳都查得到的鏈，仍然可以是一條很貴的鏈；把來源查清楚，不會讓中間層少拿一毛錢。

單跳的情況對照會更清楚。AdSense 的 publisher 分潤約 68%，這段抽成是揭露的，跳數少、比例公開，不存在 unknown delta 的問題；開放競價那條長鏈的 51% 跟它不是同一個東西，差別不只在數字大小，也在有幾隻手經過。

老喬自己站台的實測可以接上這個推論：publisher 實收 eCPM 是 US$0.226（約 NT$7.2），以 68% 分潤反推，廣告主端支付的 CPM 大約是 NT$10.6。從 NT$10.6 到 NT$7.2 這一段是揭露的；真正查不清楚的損耗，發生在跳數更多的鏈上。想理解 publisher 這一端還有哪些可動的地方，可以看站主手上的八個槓桿。

一件我沒辦法從自己站台驗證的事

我的站台實測廣告請求媒合率是 68.0%，代表約三成的請求沒有廣告回來。原因很多，底價、受眾、地區、版位尺寸、當下有沒有需求都算，ads.txt 設定是其中容易被忽略的一個。

但我沒辦法把 68.0% 歸因到任何單一原因，也沒做過把 ads.txt 改壞再改回來的對照實驗——那會真的損失收益。所以這篇給的是判斷依據，不是「照做就會漲」的承諾。能確定的只有機制層面：清單是完整白名單，漏掉就是未授權，未授權的請求會被一部分買方丟掉。這件事在你站上值多少錢，得看你原本漏了多少。整個系列的錢流結構整理在廣告的錢流總論。

本文關鍵字：ads.txt、sellers.json、domain spoofing、程式化廣告供應鏈、廣告收益