Ads.txt - Revision history

Jkoran at 15:57, 13 February 2021

2021-02-13T15:57:10Z

Jkoran: /* Impact */

2021-02-13T15:51:03Z

Impact

Jkoran: Created page with "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. Sellers..."

2021-02-13T15:23:47Z

Created page with "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. Sellers..."

New page

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. 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 (ex. 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.

== 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.<ref>https://www.thedrum.com/news/2019/02/07/fraudsters-target-adstxt-industry-calls-uncluttered-supply-chain</ref> Some fraudsters copied valid Ads.txt files but did not even both to place content on their own domains.<ref>https://digiday.com/marketing/ads-txt-404bot</ref>

== 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. <ref>https://www.adexchanger.com/the-sell-sider/why-ads-txt-has-failed-and-what-to-do-about-it/#more-149089</ref> 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 unneccesary 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 ==
* [[Sellers.json]]

== References ==

<references />
[[Category:Glossary|Ads.txt]]

@@ Line 1: / Line 1: @@
-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. Sellers place a file containing a list of sell-side partners in a well-known location hosted on their domain.
+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.<ref>https://iabtechlab.com/ads-txt</ref> 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.
@@ Line 11: / Line 11: @@
 The Ads.txt file can optionally include an organizational identifier issue by Tag:
-* TAGID (ex. f08c47fec0942fa0)
+* 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.
 == History ==
@@ Line 30: / Line 32: @@
 == See Also ==
 * [[Sellers.json]]
 == References ==

@@ Line 24: / Line 24: @@
 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. <ref>https://www.adexchanger.com/the-sell-sider/why-ads-txt-has-failed-and-what-to-do-about-it/#more-149089</ref> 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 unneccesary overhead and cost incurred by relying on a central authority to license organizational identifiers.
+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.