Ads.txt

From Bitnami MediaWiki
Jump to navigation Jump to search

Ads.txt ("ADS" is an acronym for Authorized Digital Sellers) is method for publishers to designate the vendors they rely on to increase the demand for their inventory.[1] Sellers place a file containing a list of sell-side partners in a well-known location hosted on their domain.

The goal of Ads.txt was to help buyers understand if a seller was spoofing a publisher domain by seeing if that publisher had listed this seller in Ads.txt file.

The Ads.txt file contains a minimum of three pieces of information:

  • Domain name of the sell-side partner (e.g., appnexus.com)
  • Account ID (e.g., 4052)
  • Relationship type (e.g., reseller)

The Ads.txt file can optionally include an organizational identifier issue by Tag:

  • TAGID (e.g., f08c47fec0942fa0)

The relationship type can be either "direct" or "reseller." The designation of "direct" means SSP or exchange will itself sell the publisher's inventory. The designation of "reseller" means the SSP or exchange will sell the publisher inventory itself as well as request demand from other SSPs and exchanges.

Publishers may choose to designate in their Ads.txt file "placeholder" information to signal that they alone sell their own inventory.[2] This signal replaces the deprecated empty Ads.txt file some publishers had previously used.

History

Google created Ads.txt in spring 2017 and relied on the Interactive Advertising Bureau (IAB) Tech Lab to propagate its use by publishers.

Within a year, fraudsters exploited the weaknesses in the design by copying valid Ads.txt files onto their own domains, which may use stolen content from real publishers.[3] Some fraudsters copied valid Ads.txt files but did not even both to place content on their own domains.[4]

Impact

Despite its laudable goal, Ads.txt is often criticized for the friction it introduces for publishers to improve their yield. Moreover, the inability for a reseller to signal that its partners are authorized to sell the inventory to marketers defeats the original purpose of having a signal from publisher to prospective buyers as to whether a given seller is spoofing its domain. [5] This limitation is addressed by Sellers.json.

Another limitation of this design is the centralized licensing scheme, publishers use to signal the buyers which organizations are authorized sellers and resellers. The organizational identifiers are managed by a central authority, which requires a fee to issue the identifier. An alternate decentralized approach would be to rely on the public/privacy key each organization already relies on to validate HTTPs, which would eliminate the unnecessary overhead and cost incurred by relying on a central authority to license organizational identifiers.

Given these issues the ecosystem is looking into better forms of signaling throughout the distributed advertising supply chain that supports publishers' businesses.

See Also

References