When the IAB Tech Lab released the original specification for ads.txt to combat growing concerns around domain spoofing and arbitrage, digital publishers across the globe steadily adopted the new standard for validating authorized digital sellers.
According to Q3 2018 Pixalate data, 77 percent of the top 5,000 global websites selling programmatic ads have adopted ads.txt since the spec release in May of 2017. Companies, like PubMatic, have been fully in support of these initiatives and as of August 2018, we do not allow our supply partners to monetize inventory that is unauthorized per a site’s ads.txt entry. Additionally, other industry bodies, such as TAG, have done an excellent job promoting ads.txt.
While the release of ads.txt marked an important step towards eradicating domain spoofing and providing buyers transparency into authorized ad selling, the original spec was designed only for desktop and mobile web inventory. In this post, we will take a look at the background on app-ads.txt and a brief primer on how it works.
Why Did app-ads.txt Take So Long?
The IAB Tech Lab has been working with ad tech industry leaders to extend the ads.txt functionality to include inventory from mobile apps and over-the-top (OTT) video. On November 30th, the IAB released app-ads.txt beta spec which will be available for public comment until February 4th, 2019.
The primary reason for the long delay in releasing the app-ads.txt standard was solving for the difficulty of securely hosting an app publisher’s ads.txt file. On web inventory, we can tie the publisher-owned domain, available in bid request, to an ads.txt file destination. Bundle IDs on app inventory are the closest match to a publisher domain on web inventory and they cannot replace the domain role. Thus, we needed a neutral entity to associate each app to its ads.txt destination URL.
The IAB industry task force concluded that app stores would be a reliable neutral entity to establish the app and publisher’s ads.txt destination URL relationship. All of the popular stores offer secure login access to app publishers to update app store pages. This access allows the app developer to publish all app related information including the publisher’s ads.txt destination URL.
The new app-ads.txt specification relies on the publisher URL, available on app store HTML pages, as the centrally located, crawler-friendly, trusted source.
How app-ads.txt Works
The specification identifies four entities that play a vital role in enabling authorized digital seller validation on in-app inventory:
- App stores
- App publishers
- Sell-side platforms
- Authorized seller verifiers
App stores will enable mobile authorized seller specifications. They are expected to connect the app with its publisher’s URL that hosts seller information. Specification requires the app stores to publish the app publisher’s URL, bundle_id, and store_id as HTML <meta> tags within the <head> tag at the beginning of the HTML doc.
App publishers are required to complete the following steps to enable seller authorization on their app inventory:
- Register the URL that hosts app-ads.txt file on the app store
- Publish an app-ads.txt file with authorized seller information.
The file format for mobile authorized seller information will be identical to that of web ads.txt. Each record will have an ad tech domain, publisher account ID, relationship\account type and optional TAG ID.
Please note that app inventory seller information must be published in a separate file entitled “app-ads.txt.” Therefore, the web seller information will be available in “ads.txt” but independent of app seller information.
Sell-side platforms are required to include a store URL parameter on all bid requests. Only requests with valid store URL parameters are eligible for authorization.
Authorized seller verifiers must follow the below steps to verify authorization:
- Identify the app store URL in the bid request
- Crawl the app store URL page for the publisher’s URL, bundle_id and store_id
- Translate the publisher URL to an app-ads.txt path
- Crawl and interpret the app-ads.txt file for enforcement
It is important to point out that mobile app-ads.txt specification ignores sub-domain directives, unlike web ads.txt file. Under web ads.txt specification, verifiers are expected to crawl the root domain and parse sub-domain directives to track sub-domains to specific authorized sellers.
In-app environment verifiers must start at second level domains and then fall back to root domains only when there is a missing file. This special provision is made to handle app-specific authorized seller information.
What Does This Look Like?
Let me explain how this works with a hypothetical scenario:
Consider a publisher’s “Pet Destination” with two apps (let’s call them Pet Snaps and Pet Videos), each having different authorized seller information.
“Pet Destination” can host different authorized seller information files for each app. This means one for the Pet Snaps app at petsnaps.petdestination.com/app-ads.txt and the other for the Pet Videos app at petvideos.petdestination.com/app-ads.txt.
Pet Destination should list “petsnaps.petdestination.com” as the publisher URL for Pet Snaps and list petvideos.petdestination.com as the publisher URL for Pet Videos.
The verifier will use the app store URL available in the Pet Snaps app bid request to read the publisher URL. The publisher URL listed on app store page (petsnaps.petdestination.com) is then converted to (petsnaps.petdestination.com)/app-ads.txt to access app-ads.txt file. The Pet Videos app-ads.txt path is also constructed similarly to access the file at (petvideos.petdestination.com)/app-ads.txt.
It is important to call out that only the first subdomain of a multi-subdomain URL will be used to access app-ads.txt. So, a URL like dogs.petsnaps.petdestination.com will be canonicalized to petsnaps.petdestination.com to access the app-ads.txt file.
Publishers who have same authorized sellers for all their apps can publish just one file at the first level root domain. A verifier can access authorized seller information from rootdomain.com/app-ads.txt.
What’s Next?
Now is the time for app publishers to up their ante against app spoofing and recapture ad revenue from fraudsters. The first step for any app publisher is to consolidate your seller information into either single or multiple app-ads.txt files. The next step is to host these files on your web servers. Finally,make sure the app store publisher website attribute is updated to include the correct app-ads.txt destination URL.
PubMatic is working on the tools required to process your seller information and validate sellers for authorization. All major buying platforms are also working on similar enforcement tools. However, no tool will be useful unless app publishers adopt the spec and publish their app-ads.txt files.
Make sure to review the detailed app-ads.txt beta specification and let us know of any gaps that are of concern to you. We look forward to an exciting year of app developments and the positive changes ahead.
