--- title: "ads.txt 四個欄位在防什麼：加上 sellers.json 才構成買方能驗證的賣方鏈｜廣告錢流" url: https://joelin.cc/p/9762 source: https://joelin.cc/p/9762 id: 9762 lang: zh-Hant slug: "ads-txt-sellers-json-explained" pubDate: 2026-09-14 date_modified: 2026-09-15 updatedDate: 2026-09-15 schema_type: BlogPosting description: "ads.txt 的四個欄位宣告誰有權賣你的版位，sellers.json 由中間商公布它代表哪些賣方。本文拆解欄位定義、DIRECT 與 RESELLER 的差別，以及為什麼檔案存在卻漏掉一行，比完全沒有檔案更傷收入。" ai_summary: "ads.txt 是放在網域根目錄的純文字檔，每一筆記錄以逗號分隔四個欄位：廣告系統網域（不是你自己的網站網域）、你在該系統的發布商帳號 ID、DIRECT 或 RESELLER、選填的認證機構 ID（實務上填 TAG ID）。它防的是 domain spoofing——低品質網站在競價請求裡冒用他人網域去要價；程式化買方一次買一整包、不會逐站人工查證，所以驗證必須是機器可讀的。sellers.json 由廣告系統發布在自己網域，公布每個 seller_id 對應的公司名稱、網域與 seller_type（PUBLISHER／INTERMEDIARY／BOTH），與競價請求裡的 SupplyChain 物件合起來，買方才能逐跳回溯到源頭並比對 ads.txt。對站主的實務含意：ads.txt 一旦存在就是完整白名單，沒列到就是未授權，漏掉一行比完全沒有檔案更傷收入；聯播網要求新增的每一行都是無到期日的授權，合作結束就該移除；子網域預設沿用根網域那一份，除非根網域用 SUBDOMAIN 指出。透明度檔案處理的是可追溯性：ISBA 與 PwC 2020 年研究顯示廣告主每付出 1 元只有 51% 到 publisher、15% 查不到歸屬，2022 年第二次研究 unknown delta 降到 3%，但被抽走的比例並未因此改變。" key_facts: ["ads.txt 每一筆記錄有四個欄位：廣告系統網域、發布商帳號 ID、DIRECT 或 RESELLER、選填的認證機構 ID", "ads.txt 檔案一旦存在就被當成完整白名單，沒列到的賣方等同未授權，所以漏掉一行比完全沒有檔案更傷收入", "sellers.json 由廣告系統發布在自己網域的 /sellers.json，其中的 seller_id 對應 ads.txt 第二欄的發布商帳號 ID", "ISBA 與 PwC 2020 年研究顯示廣告主每付出 1 元只有 51% 到 publisher，其中 15% 查不到歸屬；2022 年第二次研究 unknown delta 降到 3%", "AdSense 的 publisher 分潤約 68%，joelin.cc 實收 eCPM 為 US$0.226（約 NT$7.2），反推廣告主端支付的 CPM 約 NT$10.6", "joelin.cc 實測廣告請求媒合率為 68.0%，代表約三成的廣告請求沒有廣告回來"] categories: ["數位廣告"] tags: ["廣告錢流", "廣告變現", "程式化廣告", "網站經營"] authorship: origin: written ai_role: assist about: - name: "ads.txt" sameAs: ["https://www.wikidata.org/wiki/Q55603253"] - name: "sellers.json" sameAs: ["https://www.wikidata.org/wiki/Q79457899"] mentions: - name: "app-ads.txt" sameAs: ["https://www.wikidata.org/wiki/Q79458024"] - name: "AdSense" sameAs: ["https://www.wikidata.org/wiki/Q183480"] - name: "PwC" sameAs: ["https://www.wikidata.org/wiki/Q488048"] faq: [{"q":"ads.txt 要放在哪裡？","a":"放在網域根目錄，網址是 https://你的網域/ads.txt，是一個任何人都能打開的純文字檔。買方的爬蟲只會去根網域抓那一份，放在其他路徑等於沒有放。"},{"q":"沒有 ads.txt 會怎樣？","a":"沒有檔案代表你沒有宣告過任何授權，部分需求方會把來源不明的庫存排除。更傷的情況是有檔案卻漏掉你正在用的聯播網——檔案一旦存在就被當成完整清單讀，沒列到就等於你明確表示沒有授權，那一部分需求方會直接不出價。"},{"q":"ads.txt 的 DIRECT 和 RESELLER 差在哪？","a":"DIRECT 代表那一行的帳號由你自己直接控制，你跟該廣告系統之間有直接的商業關係；RESELLER 代表你授權另一個對象拿那個帳號轉售你的版位。判準是帳號是不是你自己在該系統申請的，不是的話就不能寫 DIRECT。"},{"q":"測試完的聯播網，ads.txt 那一行要刪掉嗎？","a":"要刪。那一行沒有到期日，不會因為你停止合作而失效，留著等於該賣方帳號仍被你授權，任何能操作它的人都可以合法銷售你的庫存而且買方驗證會通過。刪除只影響之後的競價，不影響已產生的收益結算，但買方照自己的排程重爬，改動不是即時生效。"},{"q":"有很多子網域，要每個都放一份 ads.txt 嗎？","a":"不用。買方爬的是根網域那一份，子網域預設沿用根網域的授權。只有在你要讓某個子網域有獨立授權時，才在根網域的檔案裡用 SUBDOMAIN 指出它，爬蟲才會再去抓那一份。內容放在別人的平台子網域上時，適用的是平台那份檔案。"}] changelog: [{"date":"2026.09.14","note":"文章發佈，系列內鏈改為可點連結，依 voice 規則修人稱與期間宣稱","by":"joe+ai"},{"date":"2026.09.15","note":"老喬親自改寫全文；系列標題統一為「廣告錢流」","by":"joe"}] entity_ids: author: https://me.joelin.cc/#joe publisher: https://me.joelin.cc/#joelincc --- # ads.txt 四個欄位在防什麼：加上 sellers.json 才構成買方能驗證的賣方鏈｜廣告錢流 ## 摘要 ads.txt 是放在網域根目錄的純文字檔，每一筆記錄以逗號分隔四個欄位：廣告系統網域（不是你自己的網站網域）、你在該系統的發布商帳號 ID、DIRECT 或 RESELLER、選填的認證機構 ID（實務上填 TAG ID）。它防的是 domain spoofing——低品質網站在競價請求裡冒用他人網域去要價；程式化買方一次買一整包、不會逐站人工查證，所以驗證必須是機器可讀的。sellers.json 由廣告系統發布在自己網域，公布每個 seller_id 對應的公司名稱、網域與 seller_type（PUBLISHER／INTERMEDIARY／BOTH），與競價請求裡的 SupplyChain 物件合起來，買方才能逐跳回溯到源頭並比對 ads.txt。對站主的實務含意：ads.txt 一旦存在就是完整白名單，沒列到就是未授權，漏掉一行比完全沒有檔案更傷收入；聯播網要求新增的每一行都是無到期日的授權，合作結束就該移除；子網域預設沿用根網域那一份，除非根網域用 SUBDOMAIN 指出。透明度檔案處理的是可追溯性：ISBA 與 PwC 2020 年研究顯示廣告主每付出 1 元只有 51% 到 publisher、15% 查不到歸屬，2022 年第二次研究 unknown delta 降到 3%，但被抽走的比例並未因此改變。 ### 重點 - ads.txt 每一筆記錄有四個欄位：廣告系統網域、發布商帳號 ID、DIRECT 或 RESELLER、選填的認證機構 ID - ads.txt 檔案一旦存在就被當成完整白名單，沒列到的賣方等同未授權，所以漏掉一行比完全沒有檔案更傷收入 - sellers.json 由廣告系統發布在自己網域的 /sellers.json，其中的 seller_id 對應 ads.txt 第二欄的發布商帳號 ID - ISBA 與 PwC 2020 年研究顯示廣告主每付出 1 元只有 51% 到 publisher，其中 15% 查不到歸屬；2022 年第二次研究 unknown delta 降到 3% - AdSense 的 publisher 分潤約 68%，joelin.cc 實收 eCPM 為 US$0.226（約 NT$7.2），反推廣告主端支付的 CPM 約 NT$10.6 - joelin.cc 實測廣告請求媒合率為 68.0%，代表約三成的廣告請求沒有廣告回來 ads.txt 與 sellers.json 防的是冒名：有人拿低品質網站的流量，在競價請求裡宣稱那是你的網域，買方以為買到你的版位，拿到的是別人的垃圾庫存。 ads.txt 是你這一端的授權名單，sellers.json 是中間商那一端的身分名冊，兩份合起來，買方才能一段一段驗證這批庫存是誰有權賣的。 它們回答誰有權賣，不回答每一手抽走多少——那是另一個問題，後面拆開講。 對內容站主來說，這兩個檔案不是技術細節，是收入的開關。設定錯誤不會讓網站壞掉、不會跳錯誤訊息，只會讓一部分需求方看完清單後安靜地不出價。 ## ads.txt 是什麼：放在網域根目錄的一份公開授權白名單 ads.txt 是一個純文字檔，位置固定在網域根目錄，也就是 `https://你的網域/ads.txt`，任何人打開都看得到，買方的爬蟲也是這樣讀它。它不是設定檔、不改變網站行為，唯一作用是對外宣告一句話：哪些對象有權賣我的廣告版位。 典型的一筆記錄長這樣： ``` google.com, pub-0000000000000000, DIRECT, f08c47fec0942fa0 ``` 一行一筆記錄，欄位用逗號分隔，`#` 開頭的行是註解。四個欄位分別是： | 欄位 | 內容 | 必填 | 最常被誤解的地方 | | --- | --- | --- | --- | | 第一欄 | 廣告系統的網域 | 是 | 這不是你的網站網域，是買方連進去競價的那個系統的網域 | | 第二欄 | 你在該系統的發布商帳號 ID | 是 | 它本來就設計成要被買方讀到，不是祕密 | | 第三欄 | DIRECT 或 RESELLER | 是 | 這一欄決定授權範圍，不是分類標籤 | | 第四欄 | 認證機構 ID | 否 | 實務上填的是 TAG ID；留空不影響這筆記錄成立 | 四個欄位合起來是一句完整的授權句：我授權第一欄那個廣告系統，以第二欄那個帳號的身分，用第三欄指定的關係，銷售我的廣告版位。第一欄最容易誤解——很多人以為那裡填自己的網站，實際上填的是買方要去哪裡競價才會撞到你的庫存。 ## 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 是這趟的行程記錄。想看供應鏈上每個角色在做什麼，可以參考[這條鏈上誰是誰](/p/9760)。 ## 對站主的實務含意 ### 檔案存在卻漏掉一行，比完全沒有檔案更傷 這是最反直覺的一點：一份 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。」 直售買的是指定的版位與時間，賣方是誰從一開始就談好了，不需要機器可讀的白名單去證明。兩種賣法的價差有多大，我另外整理在[直售與程式化的價差](/p/9763)。 ## 透明度檔案解決的是「錢流向誰」，不是「錢被抽多少」 這是最容易被混為一談的一段： - 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 這一端還有哪些可動的地方，可以看[站主手上的八個槓桿](/p/9765)。 ## 一件我沒辦法從自己站台驗證的事 我的站台實測廣告請求媒合率是 68.0%，代表約三成的請求沒有廣告回來。原因很多，底價、受眾、地區、版位尺寸、當下有沒有需求都算，ads.txt 設定是其中容易被忽略的一個。 但我沒辦法把 68.0% 歸因到任何單一原因，也沒做過把 ads.txt 改壞再改回來的對照實驗——那會真的損失收益。所以這篇給的是判斷依據，不是「照做就會漲」的承諾。能確定的只有機制層面：清單是完整白名單，漏掉就是未授權，未授權的請求會被一部分買方丟掉。這件事在你站上值多少錢，得看你原本漏了多少。整個系列的錢流結構整理在[廣告的錢流總論](/p/9766)。 本文關鍵字：ads.txt、sellers.json、domain spoofing、程式化廣告供應鏈、廣告收益