Ads.txt - Authorized Digital Sellers

Note: The detailed Ads.txt specification can be found at https://iabtechlab.com/ads-txt/.

What Is Ads.txt?

Ads.txt stands for Authorized Digital Sellers and provides a simple and secure way for content owners to publicly declare which companies (advertising systems and resellers) are authorized to sell their digital inventory programmatically, and under which terms. The main purpose of this IAB initiative, first released in June 2017, is to restrict fraudulent activity and increase transparency in the programmatic ecosystem.

In accordance with the OpenRTB protocol, every impression already includes publisher information, including the page URL and Publisher ID. However, there was previously no way for programmatic buyers to validate the data coming in the bid requests and confirm if the impression is coming from a legitimate source, or screen for fake and misrepresented ad inventory that is offered during the real-time bidding process.

Benefits:

  • Greater transparency in the inventory supply chain.
  • Publishers have control over their inventory in the market.
  • Buyers can be sure they are buying genuine inventory and dealing with a legitimate programmatic reseller.
  • Publishers’ inventory is no longer devalued by fraudulent activity.
  • Publishers receive revenue for ads purchased from their inventory, and buyers do not waste spend on fraudulent inventory.
  • “Bad actors” have a harder time to profit from selling counterfeit ad inventory across the ecosystem.

Keep in mind:

  • Authorized does not imply completely free of invalid traffic.
    • If a publisher is receiving or buying invalid traffic, ads.txt does not address this.
    • Normal invalid traffic detection is still required.
  • Non-authorized does not necessarily mean that the traffic is invalid.
    • Inventory might be resold without publisher knowledge.
    • Publisher could have missed the relationship and forgot to list it.
    • Recommendation: if you see seemingly valid non-authorized inventory, engage with the publisher to resolve it.

How Does It Work?

Ads.txt workflow
  • Publishers (content owners) create a text file, named ads.txt, which contains a one line record for every ad tech platform that offers their inventory to buyers programmatically. Each record details the platform’s domain name, the publisher’s account ID, and the terms of the inventory representation. This data is already available in the OpenRTB protocol, making it simple to gather and target.
  • Publishers host the ads.txt file on their root domain and any subdomain containing ad inventory to be sold programmatically, this way proving that the website authored the file.
  • Buying platforms, typically DSPs, crawl publisher domains on a regular basis to collect and store the data from the ads.txt files, creating a list of sellers authorized to represent the associated inventory.
  • When the inventory reaches the supply chain, the buying platforms can validate it by comparing the data from the OpenRTB bid request with the data in the ads.txt file, and then decide whether to buy it or not.
    • For example, a bid request comes in from ”Example Exchange”, with the domain example.com, and the Publisher ID is 12345. The buyer can go to example.com/ads.txt to check if “Example Exchange” is on this list and if the Publisher ID matches. If the data matches, it means the “Example Exchange” is authorized to sell that inventory.

File Format

The ads.txt file should contain one line per authorized seller with the following fields:

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

and

<VARIABLE>=<VALUE>

The following table defines the content within each 4 fields:

Field Name Description
Field #1 Domain name of the advertising system Required. The canonical domain name of the SSP, Exchange, or other system that bidders connect to. If you are using Pulse, the domain name is ooyala.com.
Field #2 Publisher’s Account ID Required. The identifier associated with the seller or reseller account within the advertising system in field #1. It corresponds to the Publisher ID sent in OpenRTB bid requests to DSPs. If you are using Pulse, this corresponds to the Pulse Account ID.
Field #3 Type of Account/ Relationship Required.
  • DIRECT: indicates that the Publisher directly controls the account indicated in field #2 on the system in field #1. This tends to mean a direct business contract between the Publisher and the advertising system.
  • RESELLER: indicates that the Publisher has authorized another entity to control the account indicated in field #2 and resell their ad space through the system in field #1.
Field #4 Certification Authority ID Optional. An ID that uniquely identifies the advertising system within a certification authority (this ID maps to the entity listed in field #1). A current certification authority is the Trustworthy Accountability Group (aka TAG), and the TAGID would be included here.

The following table defines the supported variables:

Variable Value Description
Contact Contact information Optional. Human readable contact information for the owner of the file. This may be an email address, phone number, link to a contact form, or other suitable means of communication.
Subdomain Pointer to a subdomain file Optional. A machine readable subdomain pointer to a subdomain within the root domain, on which an ads.txt can be found. The crawler should fetch and consume the data associated to the subdomain, not the current domain. Only root domains should refer crawlers to subdomains. Subdomains should not refer to other subdomains.

Example Ads.txt File

Example.com publishes ads.txt on their web server listing three exchanges as authorized to sell their inventory, including Example.com’s seller account IDs within each of those exchanges, and multiple contact records.

http://example.com/ads.txt

# Ads.txt file for example.com:

greenadexchange.com, 12345, DIRECT, d75815a79

blueadexchange.com, XF436, DIRECT

silverssp.com, 9675, RESELLER

contact=adops@example.com

contact=http://example.com/contact-us

What Do I Need to Do if I Use Pulse?

  • If you use Pulse only for direct ad serving, you do not need to add an Ooyala entry into your ads.txt file(s) since this is only for programmatic trading.
  • If you connect other platforms for programmatic trading through tags in Pulse, you should follow their guidelines to add them correctly to your ads.txt file.
  • If you use Pulse for programmatic trading (RTB), you should add a line into your domain, or the domains your represent, according to the examples below.
  1. Example: You have a direct business contract with Ooyala Pulse and use Pulse to control and trade your own inventory programmatically.

    ooyala.com, [pulse account ID], DIRECT

  2. Example: The Publisher has authorized you to represent their inventory and you are using Pulse to trade it programmatically.

    ooyala.com, [pulse account ID], RESELLER

Note: To get the Pulse Account ID, go to Pulse, open the Settings menu, and check the Integration Information section of your Account Settings.
Integration information
https://help.ooyala.com/sites/all/libraries/dita/en/video-advertising/oadtech/knowledge_base/ads.txt.html

Was this article helpful?