Between ads.txt and the proliferation of effective fraud detection tools, transparency has increased and fraud on the web has become less lucrative and prevalent over the past year. Mobile app, however, has not seen the same positive trends. This is in part because app traffic is easier to fake and because there's no ads.txt equivalent.
Ads.txt for web was one of, if not the fastest adopted standard in the history of ad tech. Websites generally control their own domains and the domain on which the ad is served is a key factor determining whether and how much people will bid. As a result, web sites could easily host an ads.txt file on their website that all can see, in predefined location, and that would control all the ads served from that domain. In app, however, this is no precise analog. There is no "site" because apps are computer code that are distributed from a centralized app store and then run locally on the phone. This creates a fundamental challenge when attempting to define an app version of ads.txt - there needs to be some way for "web crawlers" or their equivalent to actually download the data that would correspond to an app - meaning a way for an app to eventually point to a real URL.
The IAB has released a preliminary solution for ads.txt for mobile app, which actually consists of three different proposals. The solution acknowledges that there are three primary app stores that do not operate in precisely the same way, thus creating certain challenges. It also acknowledges that not all of the app stores are as engaged with the IAB in this process. Further, and most notably, none of the proposals are currently viable across all apps - meaning there is no imminent solution.
At the heart of each proposal is the notion of translating something about the app into a URL in one form or another. The first proposal uses the sellerUrl metadata field that is available in the Apple App Store. Using the game Fortnite as an example, an entity would lookup App Store's information using the app's publicly available app ID. In this case, the API URL would be: http://itunes.apple.com/lookup?id=1261357853. The request returns a lot of metadata about the app, including the seller URL, which is in the form "sellerUrl":"http://www.fortnite.com" in the current example. A crawler would then ping http://www.fortnite.com/id1261357853/ads.txt (the seller URL plus the app ID plus ads.txt) to get the final ads.txt information. Unfortunately, Apple limits the number of times an entity can ping a particular app's information and also the seller URL is only sporadically used at the moment. Further, this data generally isn't officially available in Android. As a result, many app developers would have to update their app metadata - and Google and Amazon would both have to develop support. Both goals would require significantly more effort than was required for ads.txt to work on the web and would definitely not happen overnight, though there is hope that perhaps this proposal would create pressure on Google and Amazon to quickly support such an API.
The second proposal creates an entirely new API for the app stores that create a consistent way to obtain seller URLs across all app stores. This has all the same challenges above, with the additional challenge that Apple doesn't currently support it either. This requires all three app stores to participate and is probably the least likely to take shape anytime soon. The third and final proposal - perhaps the most immediately possible but also the most potentially controversial, would be to have a third party host the mapping. In this case, the app developer would need to do something to prove to the independent service that it owns the app, then it would host on that service some form of a URL that DSPs etc could use for the ads.txt lookup.
As our app business at TripleLift continues to grow meaningfully, ensuring a viable app solution is in our (and everyone's) interest. The IAB is in a good position to host the third-party translation service and it would be the most trusted and theoretically neutral party. As a result, despite the potential challenges associated with this solution, it is believed that the other two solutions are too unlikely to be implemented in the foreseeable future given the effort and concessions required by the major app stores.