As you may have seen, on March 13th we released the final version of app-ads.txt, the mobile and native app follow-up to ads.txt. In this post I’d like to address some of the misconceptions and clarify the value prop around app-ads.txt.
Background on ads.txt
If you recall, ads.txt (Authorized Digital Sellers) was intended to solve a very specific problem: enabling buyers to spend programmatic dollars only through channels which are explicitly trusted and authorized by the originating publisher. Prior to ads.txt, a malicious actor could easily sell low value (or even non-human) ad inventory through programmatic channels simply by masquerading as a higher value publisher.
With ads.txt, the high value publisher publicly declares their authorized programmatic channels – in the form of an exchange and a publisher account ID on that exchange – and buyers can validate inbound RTB inventory against this listing. Buyers and publishers quickly cooperated to support this specification, which had the effect of drying up this particular form of fraud. However in-app inventory remained vulnerable, which was a known issue at the time.
app-ads.txt
app-ads.txt seeks to solve the same problem for mobile and OTT applications. Compared to ads.txt however, there was one complication. With ads.txt, a publisher only needs to publish their monetization platforms in plain text, at a well-known location, on the same web site as their content. Control of the /ads.txt resource itself demonstrates ownership of the content domain. The web publisher, not any biased intermediary, by definition owns that domain and its content.
Apps are different: for any given app identifier, there is no obvious associated domain or URL at which the app developer would post authorized monetization partners in an ads.txt file. The only (relevant) actionable data for real-time bidding platforms is (1) an indication of the mobile platform (whether it is an iOS device, (Google) Android, some other Android variant, a Roku box, etc.); and (2) a unique ID for the app on that platform.
Combining these two pieces of information allows for the discovery of a web domain which is guaranteed to belong to the app developer, and where a posted file can list the authorized monetization channels for the app. This is because most app stores allow for the listing of a “developer URL” (see “Developer Website” on an iOS listing and the “Visit website” link for a Google Play listing).
This link – from a specific app on a specific platform, to a web domain – can be trusted because only the owner of the app on that app store can set the developer URL.
What it means for an App Store to Support app-ads.txt
Part of the app-ads.txt specification is a simple mechanism for the app store itself to declare this developer URL in a standardized way which does not require an API or scraping html.
<meta name="appstore:developer_url" content="http://www.irishtimes.com"> <meta name="appstore:bundle_id" content="ie.irishtimes.reader"> <meta name="appstore:store_id" content="ie.irishtimes.reader">
Google Play already supports this standard. Which means that the steps for ad platforms to find a developer URL are simple for a (Google) Android app:
- Given the app ID “ie.irishtimes.reader”, retrieve the contents of https://play.google.com/store/apps/details?id=ie.irishtimes.reader&hl=en_US (note that there are variations of this page by language [the “hl” query parameter], and google recommends normalization to avoid repeated requests);
- Find the meta tag “appstore:store_id” and confirm a match to “ie.irishtimes.reader” (although Google does not, some platforms may differentiate “bundle_id” and “store_id”);
- Find the meta tag “appstore:developer_url” and the URL contents;
- Follow the rules in the specification about translating from a developer URL to an app-ads.txt path;
- Retrieve the contents of app-ads.txt;
- Interpret the contents of app-ads.txt following the existing ads.txt specification.
Some app stores do not yet support this standard (looking at you Apple and Roku!). In these cases – fear not! – there are several choices for platforms to acquire mapping data.
Other Methods to Acquire Mapping Data
Direct App Store APIs
Many of these app stores offer partners a direct API integration. In such cases, a field similar in spirit to “developer URL” is likely to be present in the detailed listing for any particular app. An implementer would simply replace steps 1-3 above with a proprietary API for each app store.
Apple, for example, offers a public search API which exposes the necessary app details.
Data Licensing
Several companies offer a single API to aggregate data across multiple app stores. 42matters for example provides one API – as well as a data dump – to read detailed app listings from the iOS, Google Play, Amazon, and Tencent MyApp stores. Apptopia has a similar offering across the iOS App Store and Google Play Store.
Tech Lab Resources
In the interest of encouraging adoption, our friends at BidSwitch offer a free public mapping of app IDs to developer URL, compiled from both direct and indirect sources. Currently the data is limited to apps that can be observed through the programmatic traffic passed through the BidSwitch infrastructure network, however they expect to eventually expand this offering to include all apps in the Google Play and iOS app stores.
More information on this offering is available in the BidSwitch public documentation.
Here at Tech Lab we’ve been hard at work adding support for app-ads.txt to our ads.txt Aggregator. Subscribers now have access to aggregated app-ads data and will see app-ads data as a new table visible in the Explorer tool.
FAQ
- But what about Apple? Will they ever support this standard?
- We hope that they will but let’s not let their lack of support slow down adoption. See above – there are several other possibilities to source the necessary data.
- The Roku app store does not provide a developer URL field!
- Is that a question? In any case, please reach out to Roku and encourage them to support the specification. Another possibility might be for Tech Lab to offer a validation/mapping service. Reach out if you’d like for us to do this.
- Is this supported in the Tech Lab aggregator?
- Yes! See our Aggregator page for details.