The IAB’s ads.txt initiative has gained rapid adoption from the biggest ad-supported websites, protecting buyers and sellers from a major source of fraud. But those same publishers appear to be leaving the door open to fraudsters by not implementing the newly-released app-ads.txt spec for their mobile apps.
Domain Spoofing and Ads.txt Adoption
The IAB-led Ads.txt solution was released in September 2017 with the goal of reducing a form of ad fraud known as domain spoofing. Domain spoofing is the practice of falsifying URLs declared in a bid request, tricking buyers into bidding on unsafe inventory or non-human traffic.
Within 6 months of its launch, the ads.txt program gained 51% adoption by the 5,000 largest global websites. Part of this success can be attributed to the ease of implementation by publishers and ease of access to buyers. Simply post a file at domain/ads.txt, and your authorized sellers are publicly disclosed.
App Laundering and App-ads.txt Adoption
Spoofing is also possible for mobile apps. Instead of a URL, mobile apps are identified by something called a bundle ID or an app ID, and this ID can be falsified in RTB bid requests. This form of spoofing is commonly called app laundering.
The solution to protect against app laundering is once again ads.txt. The IAB published initial guidance for a mobile app ads.txt solution in July 2018 and released a beta version of the spec in November 2018. Depending on when you start the clock, we’re 4-7 months into the app-ads.txt program, and adoption appears to be non-existent.
Jounce’s ads.txt crawler monitors the 3,000 largest ad-supported mobile apps, and we find exactly two apps with an app-ads.txt file: Weather: The Weather Channel and Storm Rader, both owned by The Weather Channel.
Why Is Adoption So Low?
From our conversations with publishers, marketers, and tech platforms, we see three potential drivers of the slow adoption of app-ads.txt:
Access is complicated: It’s easy to find a domain’s ads.txt file. Simply append “/ads.txt” to the website’s domain. But apps are more complicated. The publisher’s yield team needs to identify the official domain and app ID listed in each mobile app store. These values are then combined in the form: domain.com/appid/app-ads.txt (iOS apps) AND domain.com/bundleid/app-ads.txt (Android apps). The multi-step process and varied structure between browser-based and app-based ads.txt introduces implementation friction.
Prioritization is low: The publishers who were quick to adopt ads.txt make the bulk of their revenue from their websites. In the US, the CNN website is ranked 20 by Alexa’s top sites while the CNN app barely breaks the top 1,000 in the Apple App store. These web-centric publishers simply don’t prioritize app monetization. Similarly, app-centric developers don’t prioritize RTB demand. They make the bulk of their revenue from closed ad networks (Facebook Audience Network, AdMob, etc.) and are only beginning to mature their RTB strategies.
Advertisers are on low alert: Detecting spoofing requires knowledge of both the bid request and the environment in which the ad served. That second information ingredient is tricky to obtain for apps. For web inventory, third party ad servers and verification providers load code directly on page and communicate with the browser to determine the page URL. For app inventory, third party tech is at the mercy of app developers and their willingness to embed back-end code (or SDKs) to support measurement. If the right code is not embedded in an app (which of course it isn’t for app laundering), it becomes very difficult for third parties to verify the app’s name or ID.
At Jounce, we will continue to monitor ads.txt adoption in the app space and expand and publish our list as it evolves. You can stay up to date on the latest app ads.txt adoption rates by signing up for our Jounce newsletter at the top of our blog page. And you can request free access to our ads.txt database here.