One of the hottest topics in the world of online advertising today is app-ads.txt, IAB’s “Authorized Sellers for Apps” initiative–the next step in the war on inventory fraud (spoofing). Following the industry-wide success of ads.txt, app-ads.txt aims to significantly reduce app spoofing in your media. Similar to ads.txt, app-ads.txt ensures that those selling inventory on mobile apps are approved to do so.
Spoofing and misrepresenting is fairly widespread in mobile apps because users can download apps from multiple sources, and some of those apps are “mutated” by fraudsters for monetization via unscrupulous sellers.
Although mutated apps are found more often on Android, iOS apps are not immune. And incentives for spoofing iOS apps are greater, due to the higher CPMs available in Apple’s store; there is higher demand for iOS users. As such, app-ads.txt provides additional protection, ensuring advertisers are getting what they paid for.
Unlike with desktop inventory, app verification tends to be a difficult problem for advertisers and app developers alike to address: app spoofing is prolific and can be very hard to detect. app-ads.txt is a tool to combat misrepresentation and add more transparency for all.
A primary distinction between ads.txt and app-ads.txt is the location of the file. An ads.txt file resides under the top level of the domain that is being monetized; app-ads.txt resides under the top-level domain of the app developer's website. In each case, the txt file is associated with the creative entity.
For domains, the association between say https://www.nytimes.com/section/opinion and https://www.nytimes.com/ads.txt is obvious, but it is not so simple when you’re considering apps and their publishers. The closest thing to a canonical reference for an app is its product page on the app store from which it was downloaded (a reference to the app store should also be included as part of OpenRTB). Since major app stores provide links to the app developer’s website, it was convenient to specify the root of this website as a location for app-ads.txt.
Unfortunately, many smaller app developers do not have a website, or if they do, it isn't likely it's maintained as diligently as ads.txt is for domains.
That said, it is important that DSPs and SSPs strictly enforce app-ads.txt in order to prevent misrepresentation. Without it, buyers have no way to verify that they are in fact buying authentic, authorized inventory.
Developers of popular apps have, perhaps unsurprisingly, shown stronger inclination towards adopting app-ads.txt, which is encouraging, since there are high levels of misrepresentation for these apps. Consider: spoofing a popular app is much more likely to result in some unintended downloads and the fallout that follows than spoofing a niche app would be. The infancy of the app-ads initiative is probably a big part of why there’s so much false representation–it’s not very well-enforced by suppliers and buyers yet.
When looking at violators of app-ads.txt, there are interesting trends at app category levels. The Health category of apps is most afflicted, with 49% of the volume being unauthorized.
It is important to remember that keeping ads.txt and app-ads.txt files up-to-date with new partnerships is just as important as hosting the file; not doing so jeopardizes the integrity and efficacy of the app-ads.txt initiative.
Work only with providers that have adopted app-ads.txt as well as ads.txt, and with platforms that enforce adoption.
Plain and simple, adopt app-ads.txt. Though it hasn’t yet been made mandatory, ensuring that app-ads.txt is in place will help app developers protect advertisers from fake inventory, and in turn, ensure more transparency for the online advertising ecosystem. As onerous as this may seem, the alternative is bad guys faking/cloning your app and selling dodgy ads, hurting both your income and image.
Companies that sell in-app inventory should make the following prerequisites: