Released August 2022 Please email [email protected] with feedback or questions. This document is available online at https://iabtechlab.com/ads.txt/ © IAB Technology Laboratory

​

1. Background

Since its introduction in 2017, Authorized Digital Sellers (Ads.txt) has been a successful tool in helping the programmatic ecosystem reduce fraud, specifically misrepresentation (aka “domain spoofing”), and unauthorized sale of ad inventory. With the later creation of sellers.json and the SupplyChain Object, additional disclosure of sellers has furthered transparency throughout the supply chain. At near-full adoption of these specifications, the capability now exists for buyers to use ads.txt, sellers.json, and OpenRTB SupplyChain together to have a more comprehensive view of the supply chain. However, with different implementation needs and interpretations of the specifications for publishers, ad supply management companies, and SSPs/ad exchanges, challenges have emerged related to the representation of supply through ads.txt. This proposal is meant to evolve ads.txt to maintain its strength in fraud-reduction, increase transparency in seller relationships via sellers.json, and bridge the specification into the larger suite of supply chain transparency standards. Specifically, this update addresses the following challenges and opportunities for improvement:

• Representing seller relationships accurately: Addressing the needs of Supply Path Optimization (SPO) by linking ads.txt/app-ads.txt directly to sellers.json, to ensure that ads.txt files DIRECT/RESELLER values are accurately described.
• Introducing the concept of primary or exclusive sellers of inventory: Buyers have expressed an interest in minimizing the ‘number of hops’ to purchase a piece of inventory. In cases where a publisher outsources the majority of their monetization, the most direct route may be through a reseller. The updates develop a way, through MANAGERDOMAIN, for ad management firms and sale houses to be identified as primary, or exclusive representatives of a publisher’s inventory.
• Understanding ownership for domains/apps: To better connect the sellers.domain listed in sellers.json and the ads.txt file, the updates develop a method to support identifying owned and operated domains and apps back to the entities that own the underlying domain or app.

​

2. Scope

​

In Scope

Business relationships: This solution covers exclusive or primary monetization partnership relationships, where a global or regional entity becomes the most direct route to purchase inventory from a site or app. This solution also covers a way to identify owned and operated domains and apps back to the entities that own the underlying domain or app. Reducing potential abuse vectors: These solutions are meant to help more closely tie validation between ads.txt and sellers.json.

1. Connecting the seller domain for PUBLISHER entries in sellers.json with the OWNERDOMAIN in ads.txt
2. Better representation of exclusive paths to inventory that contain more than one hop in the supply path.

​

Out of Scope

Business relationships: This solution does not cover a way to represent that you are the exclusive monetization partner of a particular ad format type. This was deemed too complex to represent in the ads.txt specification.

​

3. Updates to Ads.txt & App-Ads.txt Standard

Please see the updates to the ads.txt standard here: https://iabtechlab.com/wp-content/uploads/2022/04/Ads.txt-1.1.pdf The below example use cases seek to help answer, what is the relationship between the “seller” and the underlying domain being sold?

​

4. Example Use Cases

​

Definitions:

• Manager - (see definition in spec for official definition) When the owner of the site does not manage monetization , the external, designated monetization partner is deemed the manager.. These partnerships can be global in scope, can be limited to a particular geography, or for new manager testing purposes, can be limited to a particular subdomain.
  • A note on the use of MANAGERDOMAIN vs INVENTORYPARTNERDOMAIN: MANAGERDOMAIN is used to represent a primary or exclusive programmatic seller of a publisher’s inventory and signify when a manager is the most Direct path to a publisher’s inventory. Managers are additional participants in the end-to-end transaction between a publisher and a buyer. These relationships are generally governed on a revenue sharing agreement where the manager is paid a percentage of sale of inventory they sell on behalf of the publisher. It is expected that managers are also represented in the schain object of a bid request as the terminal node. In contrast, INVENTORYPARTNERDOMAIN is used to represent a company that owns or has the rights to sell a portion of ads on the underlying app where they are listed. This is expected to be used when the company has an “inventory sharing” agreement in place with the underlying CTV/OTT app. In these transactions it is expected that the inventory partner is the final payee in a transaction and receives all proceeds from the ads sold. Additionally, inventory partner domain is expected to be used primarily for CTV/OTT inventory, where “inventory sharing” is common.
• Proprietary Placement Provider - Proprietary placements are ad units for which the publisher delegates monetization control to an intermediary. This intermediary might issue bid requests directly to DSPs, or it might issue bid requests via reselling exchanges.
• GEO - Geographical region, in the use cases below GEO is representative of a country. This is to support the MANAGERDOMAIN specification definition that allows for a manager per country declaration.

​

CASE A: Publisher inhouse monetization

Business scenario: The publisher monetizes their inventory internally. They operate the seats on the exchanges: Publisher.com is the business entity that owns site.com

​

Publisher -> Exchange -> DSP


​

CASE B: Publisher managed monetization

Business scenario: This case represents the publisher monetizing their inventory through an exclusive monetization partner. While the supply path includes multiple hops, it is still the most direct route from a Supply Path Optimization perspective to purchase the inventory.

​

Publisher -> Manager -> Exchange -> DSP

 See request/response table on the next page.

​

CASE C: Publisher managed monetization; country specific

Business scenario: This case represents the publisher monetizing their inventory through an exclusive monetization partner in a specific country. While the supply path includes multiple hops, it is still the most direct route from a Supply Path Optimization perspective to purchase the inventory.

​

Publisher -> Manager + GEO -> Exchange -> DSP

 See request/response table on the next page.

​

CASE D: Publisher inhouse monetization for proprietary placement type

Business scenario: The publisher monetizes their inventory internally. They operate the seat with the proprietary placement type directly.

​

Publisher -> Proprietary Placement -> DSP

 See request/response table on the next page.

​

CASE E: Resale of publisher inhouse monetization for proprietary placement type

Business scenario: The publisher monetizes their inventory internally. They operate the seat with the proprietary placement type directly. The proprietary placement vendor then sells the inventory on an exchange.

​

Publisher -> Proprietary Placement -> Exchange -> DSP

 See request/response table on the next page.

​

CASE F: owned inventory from Media Owner + Monetization Manager that has BOTH owned and resold inventory

Business scenario: The entity selling the inventory is both a media owner and a monetization manager for different pieces of inventory. The below illustrates what would be expected for a piece of inventory that is owned by the entity.

​

Publisher -> Exchange -> DSP

[ ads-txt-1.1-implementation-guide/Figure6](./ ads-txt-1.1-implementation-guide/Figure6.png) See request/response table on the next page.

​

CASE G: Resold inventory from Media Owner + Monetization Manager that has BOTH owned and resold inventory

Business scenario: The entity selling the inventory is both a media owner and a monetization manager for different pieces of inventory. The below illustrates what would be expected for a piece of inventory that is being sold by the entity on behalf of another publisher.

​

Publisher -> Manager -> Exchange -> DSP

 See request/response table on the next page.

​

Implementation Guidelines

​

Publisher Guidance

• It is recommended that you publish OWNERDOMAIN= even if your website domain and owner domain are the same
  • Specifically for sellers that are both owners and sellers it is highly recommended that they publish OWNERDOMAIN so that buyers can tell the difference between owned inventory and resold inventory. Another recommendation when possible is to separate their selling seats to more clearly represent each type of supply path.
• It is recommended that you only use MANAGERDOMAIN if a majority of your inventory is managed by a single entity. The exact interpretation of MANAGERDOMAIN is at the discretion of Ads.txt consumers (e.g. validators, measurement and anti-fraud solutions, buying platforms, etc), and may have SPO implications. For example, if the same inventory is available through multiple sellers, and you still use MANAGERDOMAIN, buyers will likely treat the other non-manager accounts as RESELLER entries.
• Conflicting MANAGERDOMAIN entries (e.g., multiple MANAGERDOMAIN for the same country) should not be used and will likely be ignored by the consumers of the information.
• This work is being done in part to help clean up the accuracy of ads.txt files. Please take this opportunity to validate that all DIRECT entries in your file are references to seller accounts that you have direct account control of.
• All accounts authorized in your ads.txt that are PUBLISHER in the corresponding sellers.json file should also have a sellers.domain in sellers.json that matches the OWNERDOMAIN in your ads.txt.

​

SSP/Exchange Guidance

• These validations of OWNERDOMAIN and MANAGERDOMAIN require a check against ads.txt AND sellers.json.
• Ensure that the sellers.domain in sellers.json matches the OWNERDOMAIN and MANAGERDOMAIN for selling accounts respectively.
• Consider more strictly validating ads.txt entries to ensure that they contain the correct field 3 value. SSPs/exchanges know what relationship they have with their publishers, and therefore can easily check if their publishers are correctly declaring field 3 in their ads.txt files.

​

DSP Guidance

• These validations of OWNERDOMAIN and MANAGERDOMAIN require a check against ads.txt AND sellers.json. It is recommended that DSPs consume and action against this data for risk mitigation benefits and SPO.
• The exact interpretation of MANAGERDOMAIN is at the discretion of each DSP, and may have significant SPO implications. It is recommended that if the DSP differs from the below guidelines, publish clear guidelines to publishers, SSPs, and partners before enforcement of any policies regarding MANAGERDOMAIN.
• The recommendations for DSPS are:
  • If you see a MANAGERDOMAIN declared, but still see significant inventory available through other sources, indicating that the MANAGERDOMAIN is not exclusive, you may treat the other traffic sources as RESELLERs of inventory, but be aware that there are non-abusive use cases that are not exclusive. Additional verification is recommended.
  • If the same inventory is available both from OWNERDOMAIN sellers and MANAGERDOMAIN sellers, the MANAGERDOMAIN entry is likely mis-marked (since selling inventory directly and via a manager implies the publisher is not outsourcing their yield management to an external entity like a sales house).
  • It is recommended that if there is more than one MANAGERDOMAIN for the same country that consumers treat it as if there is no MANAGERDOMAIN declared for that country (ie, that declaration is invalid).
  • It is expected that ad opportunities monetized by the manager, the domain listed in MANAGERDOMAIN is also that of the node representing the originating publisher in a complete supply chain object.