Do you know... The Ad Industry would take ~$44 billion hit due to ad fraud in 2022!
Estimated by Juniper Research
The IAB Tech Lab developed Ads.txt (Authorized Digital Sellers) to prevent illegitimate inventory arbitrage by providing transparency to fight against ad fraud like domain spoofing, etc.
This is made for Publishers to publicly disclose the details of companies they work with or authorize to sell their digital inventory, in a text file under their root domain. This text file is publicly available to Buyers, Exchanges, SSP, and other third-party vendors. They can use a Python script to crawl the web and see which publishers have an ads.txt file under their domain.
For example, for The Weather Channel website, you can see the names and types of sellers listed here - https://weather.com/ads.txt
The implementation is simple, flexible, and secure enough for brands to have confidence they are buying authentic publisher inventory. The use of ads.txt is not mandatory but is highly recommended.
Using it, Advertisers can easily identify the exact Sellers for a participating publisher as well as, they can download the information contained within the text file and use it to target in their campaigns.
That was about Websites, now coming to In-Apps...
The functionality of Apps are different because there is no distinct identifier (Domain/URL) associated. When buyers receive an ad request from a mobile app, they precisely won't know from where it is coming from. The only relevant actionable item for them is a "unique identifier" for an app on the platform like iOS, Android, or OTT devices.
Now, to fight inventory fraud for in-apps, the IAB Tech Lab released another specification that is app-ads.txt (Authorized Sellers for Apps).
As an extension to the ads.txt, it expands compatibility to support ads shown in mobile apps (on any Operating System), OTT applications and also enforces brand safety.
The DSP bidding on app traffic scans the app-ads.txt file to determine which sources have the authority to sell the App’s inventory. It will only accept bid requests from the sources located in the file if they have been authorized by the app owner/developer or company.
This is possible via the app listings that the app stores make available online. Hence, IAB relies on app stores (Apple, Google, etc.) to add some HTML code for every app listing that gives the App’s website domain. The website will show the domains where buyers will be able to find a publisher’s app-ads.txt file online, while the bundle and store IDs can be used to match against the ones that were included in the bid requests.
Taking the same example, let’s say that advertisers want to place ads on mobile apps of The Weather Channel, from Google Playstore: https://play.google.com/store/apps/details?id=com.weather.Weather
Its root domain will have information like shown here: https://weather.com/app-ads.txt
There will be a slight difference in the list of sellers because this is the App version. By looking at this, Advertiser will know that they are buying legitimate traffic.
That was about Websites and In-Apps, now coming to Demand Side...
We learned that ads.txt and app-ads.txt are Publisher specific and don’t help demand-side players. To point out specific Publisher behind the ad request going to DSPs - this is where another initiative of IAB comes in picture.
For the buyers to verify whether the Bid Request is from direct sellers or intermediaries - "Sellers.json" can be understood as the SSP’s version of the ads.txt file but in JSON format. It identifies the seller ID, the Publisher’s name, domain, and directness of the relationship.
At present, the final Seller or Publisher are identified in an OpenRTB Request by name and/or domain attributes. Since these attributes can be removed or contaminated easily, therefore the JSON file helps buyers to track back the request to the final Publisher.
This helps buyers in eliminating those forged inventories.
In addition to seller.json, there is another specification, called SupplyChain Object. It is primarily composed of a set of nodes, where each node represents a specific entity that participates in the selling of a bid request. Therefore that complete chain is responsible for describing all the sellers that were paid for an individual bid request.
Sellers.json and SupplyChain are combined to present the buyer with a clean, legitimate, and transparent inventory.
How the JSON file looks like? Have a look here: https://appnexus.com/sellers.json
You might have noticed terms like "Direct", "Intermediary" or "Reseller" in ads.txt, app-ads.txt and sellers.json. Here, Direct means the Publisher controls the account themselves; Intermediary or Reseller means another company have an authorization to sell.
To summarize features of these three specifications...
- Control: Gives the publishers greater control over their inventory in the market because they can specify what kind of relationship they have with a particular partner (direct or reseller).
- Transparency for Buyers: Buyers will know that if they are bidding on request, that is coming from an authorized source that the Publisher trusts.
- Security for Buyers: Since Publisher’s are declaring authorized sellers, that’ll protect the Advertiser’s brand from fake inventory that is intentionally mislabeled.
- Trust: Advertisers can be more confident that their budget is going to accountable media (originating from a legitimate domain, App, or video) and not to some fraudulent inventory seller.
- Revenue: Potentially receive more Advertiser spend that might have otherwise gone toward forged inventory.
Read more about: ads.txt | app-ads.txt | sellers.json | SupplyChain Object
