The most effective way to cut down on fraud is for the whole industry to get on board and work towards solutions that can truly scale — ads.txt and app-ads.txt are two of these solutions.
Developed by the Interactive Advertising Bureau (IAB), ads.txt already helps prevent web-based counterfeit inventory across the programmatic supply chain.
App-ads.txt is an extension of the original ads.txt standard, enabling mobile apps to increase their pool of authorized digital advertising inventory while also reducing fraud. By adopting this specification, publishers enable brands and agencies to be confident that their investments are winding up in the hands of reputable vendors.
The IAB recently announced that app-ads.txt has officially launched. This is a great opportunity to build more trust and transparency within the in-app advertising ecosystem, so we wanted to answer some questions about what exactly app-ads.txt means for publishers.
What Is App-ads.txt?
It’s a text file that publishers create and post to their website domain. This file lists all of a publisher’s authorized sellers, so that buyers can crawl this file and immediately check if the inventory they’re buying is legitimate.
Why Is App-ads.txt Important?
Ads.txt, the original web-based specification, had a huge impact on cutting down counterfeit inventory on websites, so the hope is that the same impact can be made on apps. In one experiment, The Guardian lifted its ads.txt filters and found that 72% of all video ad spending went to unauthorized programmatic sellers. A similar impact within the in-app advertising industry would be a huge benefit. In addition, publishers who utilize ads.txt (and now the app-based solution) typically see an increase in revenue, as bad actors can’t spoof their inventory as easily. It’s not a perfectly flawless solution, as there have been some exploits of ads.txt, but it’s still proven to be very effective in fighting fraud.
How Does App-ads.txt Work?
- The publisher creates an app-ads.txt file listing all approved monetization partners. For example, a line could look like this: smaato.com, 1100000000, DIRECT, 07bcf65f187117b4 (advertising system domain, publisher’s account ID, type of account/relationship, certification authority ID)
- The publisher provides their website URL (e.g. publisher.com) within an app store’s listing metadata
- The app-ads.txt file is uploaded to the publisher’s website (e.g. publisher.com/app-ads.txt)
- Ad buyers can check whether the inventory which has been offered to them is legitimate by crawling a publisher’s app-ads.txt file
What Happens if I Have Multiple Apps?
There is a special provision to handle publishers with multiple apps, and this involves using subdomains for individual apps that have different authorized seller information. If App1 and App2 from PublisherX have different authorized sellers, there will need to be two different publisher URLs and text files. As an example, it would look like this:
- app1.publisherx.com/app-ads.txt
- app2.publisherx.com/app-ads.txt
Publishers who have the same authorized sellers for all their apps can publish just one file on their root domain (e.g. publisherx.com/app-ads.txt).
What’s Next?
This is the perfect time for app publishers to fight back against app spoofing and rightfully earn the revenue that’s been taken from them by fraudsters in the past. It’s crucial that app publishers adopt this specification swiftly by adding authorized seller information in one or more app-ads.txt files, based on their setup.
To see more detailed information on this tool, you can read the full specification here.
