[null,null,[],[[["\u003cp\u003eWhile not mandatory, implementing an ads.txt file is recommended as many advertisers prioritize ads.txt verified ad requests.\u003c/p\u003e\n"],["\u003cp\u003ePlatforms with numerous child accounts can manage ads.txt by registering their domains on the Public Suffix List or getting whitelisted by AdSense for \u003ccode\u003edata-ad-host\u003c/code\u003e verification.\u003c/p\u003e\n"],["\u003cp\u003eRegistering on the Public Suffix List requires placing ads.txt files on each subdomain, typically containing the child publisher ID unless AdSense whitelisting is also utilized.\u003c/p\u003e\n"],["\u003cp\u003eAdSense whitelisting enables ad request verification based on either \u003ccode\u003edata-ad-client\u003c/code\u003e or \u003ccode\u003edata-ad-host\u003c/code\u003e, allowing platforms to use a single ads.txt entry with the host publisher ID.\u003c/p\u003e\n"],["\u003cp\u003eThis scalable solution using \u003ccode\u003edata-ad-host\u003c/code\u003e applies only to platform domains, while custom domains still require the child publisher ID in their ads.txt files.\u003c/p\u003e\n"]]],["Ads.txt files list publisher IDs authorized to request ads on a domain. Platforms can manage this with two options: registering on the Public Suffix List or using special ads.txt treatment. Public Suffix List registration requires ads.txt files on each subdomain with child publisher IDs. Special treatment allows whitelisted domains to verify requests using `data-ad-host` or `data-ad-client`, needing only one entry with the host ID. This solution works only for platform domains. Google manually maintains the platform domain list.\n"],null,["Ads.txt\n-------\n\nImplementing an ads.txt file isn't a strict requirement, and ads will continue to serve without an ads.txt file. However, it's worth noting that many advertisers are choosing to only bid on ad requests that are ads.txt verified - [learn more about ads.txt](https://iabtechlab.com/ads-txt/).\n\nThe ads.txt file is a collection of all the publisher IDs that are allowed to request for ads on your domain, and lives at the root of the domain (for instance, on example.com/ads.txt). A typical ads.txt file entry looks like this: \n\n```\ngoogle.com, pub-0000000000000000, DIRECT, f08c47fec0942fa0\n```\n\n\u003cbr /\u003e\n\nUsually the publisher ID used in an ads.txt file is based on the value of `data-ad-client` from the ad tags. However, given that most AFP platform customers have thousands of child accounts, managing this file and even Google and other bidders' ability to process it, becomes difficult. There are two options for platform customers to solve this problem, and scale the usage of ads.txt on their platform domains. Platforms can choose to do either one of the options, or both in combination if required:\n\n- Platforms can register their domains on the [Public Suffix List](https://publicsuffix.org/)\n- AdSense can whitelist platform domains to be able to verify ad requests based on the `data-ad-host` parameter in addition to the `data-ad-client` parameter\n\n### Option 1: register on the Public Suffix List\n\nBy registering a domain on the [Public Suffix List](https://publicsuffix.org/), browsers will treat the domain as a TLD (top level domain). Our ads.txt verification system will do the same. Platforms should investigate the full impact this will have on their domain before making this change.\n\nIf a domain exists in the Public Suffix List, the location of the ads.txt file must be changed. Instead of publishing an ads.txt file on the root of the domain (example.com/ads.txt), the ads.txt files have to be posted on each subdomain (subdomain.example.com/ads.txt), and unless option 2 is also pursued, the ads.txt file has to contain the child publisher ID, or in other words, it's based on the value of the `data-ad-client` parameter.\n\nAs an example, if the child property code (`data-ad-client`) is: `ca-pub-123456789012345`, the ads.txt file will look like this: \n\n```\ngoogle.com, pub-123456789012345, DIRECT, f08c47fec0942fa0\n```\n\n\u003cbr /\u003e\n\nWhere the `ca-` portion of the string has been removed.\n\n### Option 2: special ads.txt treatment for platform domains\n\nAFP has made it possible to verify ad requests based on the value of either `data-ad-client` or `data-ad-host` for whitelisted domains. This means if either of these IDs are in the ads.txt file, the ad request is processed as verified. This treatment will work even if the domain is listed on the [Public Suffix List](https://publicsuffix.org/), where the only difference will be the location of the ads.txt file.\n\nFor most AFP platform customers, we recommend ensuring all ad tags have the `data-ad-host` parameter set (alternatively you can use the [\"platform account\" meta tag](/adsense/platforms/common/meta-tags#platform_account) to ensure this is the case). And subsequently, the ads.txt file will only ever need one entry, which will be based on the host property ID (`data-ad-host`).\n\nAs an example, if your host ID (`data-ad-host`) is: `ca-host-pub-1234567890123456`, the ads.txt file will look like this: \n\n```\ngoogle.com, pub-1234567890123456, DIRECT, f08c47fec0942fa0\n```\n\n\u003cbr /\u003e\n\nWhere the `ca-host-` portion of the string has been removed.\n| **Note:** this scalable solution will only work for your platform domains. We do not support this work around for custom domains operating on your platform - they will continue to need to have the child publisher ID (based on `data-ad-client`) in the ads.txt file.\n| **Note:** the list of your platform domains is at this stage manually maintained by Google. If you would like to add support for additional platform domains, please reach out to your account manager, or afp-support@google.com."]]
