ads.txt/app-ads.txt 常見問題


ads.txt/app-ads.txt 檔案中應包含哪些資訊?

文字檔案會將每個有權銷售您廣告空間的廣告交易平台或賣方平台逐行列出。其中的每一行均應包含三種資訊 (加上第四個選填的欄位),格式如下:

<Field #1>, <Field #2>, <Field #3>, <Field #4>

  • <Field #1>:出價工具連結的系統標準網域名稱。這可能是用來進行 WHOIS 及反向 IP 查詢的系統運作網域 (如果與上層公司網域不同的話),以便指明擁有權。賣方平台或廣告交易平台可以發布要使用的網域名稱。

    對 Google 賣方帳戶來說,此網域名稱一律為 google.com

  • <Field #2>:與系統中 field #1 的賣方或經銷商帳戶相關聯的發布商 ID。其中包含的值必須與賣方平台或廣告交易平台交易中指定的值相同 (例如 OpenRTB 出價要求)。在 OpenRTB 中,這通常是 publisher.id 欄位中的值,在 OpenDirect 中則通常是發布商的機構 ID。 

    請賣方在這一欄中,填入各個 Google 賣方帳戶內顯示的發布商 ID (例如:pub-0000000000000000)。找出這個 ID 的方法如下:

    宣告中只能包含 pub- 前置字元和 16 碼數值代碼,請刪除用來指稱產品的前置字元 (例如 ca-ca-video-)。如果您透過多個 Ad Manager 和/或 AdSense 帳戶營利,則必須為各個帳戶分別保留一列,每列包含相對應的 pub- 代碼。
    如果賣方的發布商 ID 並未列在 ads.txt/app-ads.txt 檔案中,代管該檔案的網域/應用程式就無法透過 Ad Manager 營利,Google 也不會再向這類網站/應用程式購買廣告。建議您更新 ads.txt/app-ads.txt 檔案,針對您要用來營利的每個網站加入發布商 ID (瞭解如何在 Ad Manager 中更新 ads.txt/app-ads.txt)。如果您使用了「可調式夥伴管理」服務,建議您與子夥伴合作,在對方的 ads.txt/app-ads.txt 檔案中加入您的發布商 ID。
  • <Field #3>:帳戶或關係的類型。您在解讀資料時,這個欄位中的值應區分大小寫。
    • 如果這個值為「DIRECT」,表示發布商 (內容擁有者) 對第 2 個欄位中指定的帳戶有直接控制權,並表示發布商和廣告系統簽署了直接商業合約。

      如果 Google 發布商能夠直接管理第 2 個欄位列出的帳戶,請在這個欄位中指明「DIRECT」。

    • 如果這個值為「RESELLER」,表示發布商已授權其他實體控管第 2 個欄位所指涉的帳戶,並透過第 1 個欄位中的系統經銷其廣告空間。

      如果 Google 發布商並未直接管理第 2 個欄位列出的帳戶,請在這個欄位中指明「RESELLER」。舉例來說,要是 Ad Manager 帳戶採用「可調式夥伴管理」服務,就應該將該帳戶未直接管理的廣告空間指定為「RESELLER」。

  • <Field #4> (選用):用來特別指明認證機構中廣告系統的 ID (這個 ID 可對應到第 1 個欄位中所列的實體)。因為憑證授權單位是 Trustworthy Accountability Group (TAG),因此請在這個欄位中填入 TAG ID。

    Google 賣方帳戶的 TAG ID 是 f08c47fec0942fa0

Google 會如何強制執行 ads.txt/app-ads.txt 檔案?

Google 會根據託管於根網域/應用程式中任何 ads.txt/app-ads.txt 檔案的內容,判斷哪些賣方帳戶能夠在該網域/應用程式放送廣告。

如果網域中有 ads.txt/app-ads.txt 檔案,且其中已正確列出發布商 ID,Google 會針對擁有該檔案的網站發出的請求進行競價,並傳回勝出的廣告。如果檔案中的 ID 不正確,Google 就不會針對該請求舉行競價。

系統會自動偵測全新和更新的 ads.txt/app-ads.txt 檔案,但異動項目最久可能要 24 小時才會生效。

如果 ads.txt/app-ads.txt 檔案託管於子網域,會怎麼處理?

假如有子網域並以根網域中的 ads.txt 檔案做為參照,則 Google 會檢索並強制執行放置在子網域中的 ads.txt 檔案。在 Ad Manager 中,ads.txt 管理工具目前還不會顯示已檢索的子網域清單。

app-ads.txt 檔案中不會用到子網域;即使遇到子網域,該檔案也會將其忽略。請確認 app-ads.txt 檔案不在子網域中。

Google 是否支援重新導向?

Google 支援單一 HTTP 重新導向至原始根網域以外的目的地 (例如將 example1.com/ads.txt 重新導向至 example2.com/ads.txt)。請參閱 IAB 更新

只要每個重新導向位置維持在原始根網域內,Google 也支援多個重新導向。範例如下:

  • example.com/ads.txt 重新導向到 www.example.com/ads.txt
  • example.com/ads.txt 重新導向到 subdomain.example.com/ads.txt
  • example.com/ads.txt 重新導向到 example.com/page/ads.txt

無法透過 CMS 在根網域中放置檔案,該怎麼辦?

請聯絡您的 CMS 供應商,他們將提供可替您代管 ads.txt/app-ads.txt 檔案的功能。

如果 Ad Manager 未偵測到我網域上發布的 ads.txt/app-ads.txt 檔案,該怎麼辦?

網域可能已發布 ads.txt/app-ads.txt 檔案,但 Ad Manager Ads.txt 管理工具中仍會顯示為「未找到 ads.txt」狀態。這可能是由於未正確導入 ads.txt/app-ads.txt 或其他與檢索相關的原因所造成。進一步瞭解如何確認 ads.txt/app-ads.txt 檔案可供檢索

如果買方在出價要求中看到空白網址,該怎麼辦?

如果出價要求中的網址空白,可能的原因如下:

  • 您的某個根網域可能缺少 ads.txt/app-ads.txt 檔案。Google 會使用網域上的 ads.txt/app-ads.txt 檔案,來驗證發布商是否有權透過出價要求傳送給買方的網域營利。如果缺少網域的 ads.txt/app-ads.txt 檔案,出價要求就可能包含空白網址。 

    您應該將 ads.txt/app-ads.txt 檔案個別上傳到每個網域。依序按一下 [管理] 然後 [Ads.txt 管理],並確認 ads.txt/app-ads.txt 檔案已上傳到您的每個網域。
  • 如果 ads.txt/app-ads.txt 檔案已發布到網域但 Ad Manager 未偵測到,就可能會發生導入錯誤。進一步瞭解如何在 Ad Manager 中管理 ads.txt/app-ads.txt,以及如何確認 ads.txt/app-ads.txt 檔案可供檢索
  • Google 發布商廣告代碼或回傳式曝光的「page_url」覆寫屬性的導入方式可能發生問題。這可能會導致傳遞給 Ad Manager 的廣告請求中包含無效的覆蓋網址值,而且買方收到的出價要求會包含空白網址。
如果看到不認得的網域,該怎麼辦?

如果「授權數位賣方」頁面列出您不認得的網域名稱,可能的原因如下:

  • 您的廣告程式碼巢狀配置於多個 iframe 中,或者您目前使用廣告伺服器、收益管理工具或其他供應端平台 (SSP) 將廣告程式碼嵌入 iframe 中。如果您的廣告程式碼位於巢狀 iframe 中,系統將無法判別正確的廣告請求網站資訊。若您的網頁包含 iframe,該 iframe 指向網站上另一個網址,而且其中帶有欲顯示的標記,就可能出現這種情形。
  • 有其他網站透過所屬網域提供您的網站內容。例如,Google 快取搜尋結果、Google Accelerated Mobile Pages (AMP) 快取和 Google 翻譯可能會擷取您的內容,然後從 Google 網域放送不含 iFrame 的內容。

  • 在電子郵件用戶端中轉寄的網頁。

  • 在不同發布商之間傳抄 (亦即複製及貼上) 的內容。
     

建議您在出現不認得的網域時採取下列做法:

  • 如果廣告程式碼巢狀配置於多個 iframe 中,您可能需要傳遞使用者所瀏覽的網頁網址
  • 如果您目前使用廣告伺服器、收益管理工具或其他供應端平台 (SSP),而且看到不認得的網域,請詢問供應端平台的帳戶管理小組,瞭解將正確的網站資訊傳送給您廣告請求的最佳方法。

如何為 WordPress 設定 ads.txt/app-ads.txt 檔案?

建議您利用外掛程式在 WordPress 中建立 ads.txt/app-ads.txt 檔案。如果您已經採用外掛程式來刊登廣告,其程式中可能含建立 ads.txt 檔案的功能。這項搜尋可以助您踏出第一步。

如何為 Blogger 設定 ads.txt/app-ads.txt 檔案?

相關操作說明請參閱 Blogger 說明中心

這對您有幫助嗎?
我們應如何改進呢?