app-ads.txt 是一項 IAB Tech Lab 規範,可讓行動應用程式宣告哪些賣家帳號有權轉售其廣告庫存,而且每一筆記錄使用的欄位(以逗號分隔)與網站上使用的標準 ads.txt 檔案完全相同。這個檔案託管在開發者自有網站的固定位置,而不是託管在應用程式本身控制的伺服器上,這讓程式化買家能透過一個公開的地方,確認聲稱要銷售該應用程式廣告庫存的廣告聯播網是否確實獲得授權。包括 Google AdMob、Meta Audience Network、AppLovin、Unity LevelPlay 和 ironSource 在內的各大聯播網,都會透過各自的發布商後台介面顯示它們希望您發布的賣家記錄,但每一家呈現這些記錄的格式與選單位置都不相同。把它們整合成一份符合標準格式的檔案,正是 Ads Txt Generator 設計來處理的實際工作:您把每個平台提供的記錄貼進去,這個工具會驗證四個欄位、移除重複的資料列,並產生一個可以重新命名並部署到您開發者網址的檔案。
app-ads.txt vs ads.txt:相同格式,不同主機
IAB Tech Lab 於 2017 年為網站推出 ads.txt,並於 2019 年將相同的記錄語法延伸至行動應用程式,即 app-ads.txt。行的格式完全相同——每筆記錄一行、四個以逗號分隔的欄位、檔案結尾有換行——但爬取的目標不同。網站廣告庫存的擁有者將檔案發布在其自有網域的根目錄;行動應用程式開發者則將檔案發布在其自有開發者網站的根目錄,然後在應用程式商店上架資訊中註冊該網址,讓買家能將應用程式內的套件識別碼對應到正確的公開檔案。
| 面向 | ads.txt (網站) | app-ads.txt (行動應用程式) |
|---|---|---|
| 記錄格式 | 每行四個以逗號分隔的欄位 | 相同的四欄位記錄 |
| 規範系列 | IAB Tech Lab ads.txt 1.1 | IAB Tech Lab app-ads.txt 1.0 |
| 公開網址模式 | https://example.com/ads.txt | https://example.com/app-ads.txt |
| 主機擁有者 | 網站擁有者 | 應用程式開發者 |
| 買家如何找到檔案 | 爬取廣告庫存所在的網域 | 爬取在商店中註冊的開發者網址 |
由於記錄語法是共用的,能產生符合標準格式 ads.txt 檔案的工具,也能產生同樣有效的 app-ads.txt 檔案內容;唯一會改變的只有檔名與公開路徑。
每個廣告聯播網在哪裡揭露其 app-ads.txt 記錄
沒有任何單一廣告聯播網能從一個畫面就給您一份完整的 app-ads.txt 檔案。每一家聯播網都透過不同的後台路徑顯示它希望您發布的記錄,而這些記錄本身包含平台特定的發布商識別碼,有時還包含一個認證機構 ID。以正確的順序收集它們,可以避免漏掉一列或重複加入已經有的列,而官方記錄語法記載於 IAB Tech Lab ads.txt 1.1 規範,app-ads.txt 即延伸自該規範以適用於行動廣告庫存。
| 聯播網 | 在哪裡找到記錄 | 識別碼模式 |
|---|---|---|
| Google AdMob | Apps 選單 → App settings → app-ads.txt 區塊 | pub- 後接帳號數字 |
| Meta Audience Network | Monetization Manager → Property → Authorized Sellers | 數字屬性 ID,搭配 DIRECT 或 RESELLER 標記 |
| AppLovin MAX | Account → MAX → Manage apps → Authorized Sellers | 英數混合的帳號 ID |
| Unity LevelPlay | Monetize → Setup → app-ads.txt snippet | Unity 發出的代碼 |
| ironSource / Tapjoy | Account dashboard → app-ads.txt 區塊 | 聯播網發出的賣家 ID |
後台標籤與路徑會隨著聯播網重新設計其介面而變動,因此安全的做法是閱讀平台本身的設定頁面以掌握選單的最新狀態,逐字複製建議的記錄,並把該頁面視為唯一的事實來源,而不是參考任何快取版本。
在本機建立符合標準格式的檔案
一旦您為每個授權聯播網都取得一筆經過驗證的記錄,接下來的工作就是把它們組合成一份爬蟲能夠接受且不會發出警告的檔案。Ads Txt Generator 會根據您貼上的輸入產生該檔案內容,在每一步都進行欄位驗證並防止重複。帳號資料會保留在您的裝置上,因為這個產生器不會將它們送到伺服器。
- 在瀏覽器中開啟 Ads Txt Generator。
- 針對每個授權聯播網,從平台本身的設定說明中複製廣告系統網域、發布商帳號 ID、關係類型(DIRECT 或 RESELLER),以及選填的認證機構 ID。
- 把第一筆記錄貼到產生器中,並加入可見的清單。為每個已驗證的賣家重複此步驟,包括在新增合作夥伴之前您已經上線的任何賣家。
- 檢視組合後的文字。移除任何無法對應到目前後台項目的資料列,並確認每個識別碼都與平台提供的完全一致。
- 下載檔案(或複製產生的文字),然後在本地將其儲存為 app-ads.txt,使部署步驟符合 IAB 規範所規定的檔名。
這個產生器會修剪空白字元、把網域轉為小寫、拒絕欄位內含逗號或空格、阻擋重複的資料列、將輸出上限設為 200 筆記錄以免一次過大的貼上產生難以處理的結果,並在檔案結尾加上換行。它只驗證語法;不會登入任何廣告帳號、不會確認發布商 ID 是否屬於您,也不會證明某個轉售商是否獲得授權,因此驗證工作仍然必須在每個聯播網的後台進行。
在正確的開發者網址發布檔案
IAB 規範要求 app-ads.txt 必須可在開發者自有網域上的固定位置取得。預期的模式為 https://example.com/app-ads.txt,其中 example.com 是您所控制的網站,也是您在 Google Play 的開發者網站欄位或 Apple App Store Connect 的行銷網址欄位中所註冊的同一個網址。規範中有三項部署規則可避免最常見的拒絕情況:
- 將檔案託管在普通 HTTP 或 HTTPS 網址的根路徑 /app-ads.txt。像 /files/app-ads.txt 這類子路徑,或將內容包在 HTML 頁面內,都不符合規範。
- 不要把檔案設在登入驗證、來源檢查或地理位置封鎖之後,因為程式化買家在擷取時不會提供憑證。
- 在每個應用程式商店上架資訊中註冊開發者網址,讓買家能將應用程式內的套件識別碼對應到正確的公開檔案。
部署完成後,在隱私瀏覽器中擷取該網址,以純文字檢視回應內容,並確認每一列都與產生器輸出中的記錄一致。
驗證公開檔案並保持記錄時效
一個上線的 app-ads.txt 檔案並不是一次性產物。聯播網會更名、變更賣家帳號、輪換認證機構 ID,並淘汰轉售合作夥伴,這些變動中的任何一項都可能讓公開檔案上留下過時的資料列,在不知不覺中傷害營收。正確的做法是建立定期核對的循環,而不是發布一次就了事;而當填補率下降時,與先前備份進行純文字差異比對,是最快找出問題的方法。
- 每季以純文字方式開啟公開網址,並把每一列與每個廣告聯播網後台中的現行說明進行比對。
- 在發布替換檔案之前,保留前一份檔案的備份,這樣當合作夥伴變更其賣家 ID 時,新舊差異只需一個點擊就能取得。
- 在引入替代合作夥伴時,先新增一列再移除過時的一列,讓檔案在整個切換過程中持續有效。
- 每當記錄有變動時,把同一組輸入重新跑過 Ads Txt Generator,而不是手動編輯已部署的檔案,以免不小心留下多餘的逗號或空格。
如需更深入地了解每個廣告聯播網的後台路徑,請參閱 建立 app-ads.txt 檔案的實用指南,其中會更詳細地說明各平台的個別步驟。
如果您正在比較各種選項,檢查 AI 機器人 robots.txt 時避免這些錯誤對此有詳細說明。