The IAB’s ads.txt standard, a simple method for fighting domain spoofing whereby publishers list authorised resellers of their inventory, has quickly become a part of the ad tech wallpaper. A report last year from Pixalate found that 1.2 million domains now have an ads.txt file, as use of the standard has become commonplace.
But bringing these same protections over to connected TV has proven trickier. The original ads.txt standard was designed specifically for web domains, meaning it wouldn’t work for CTV apps. And while the app-ads.txt specification released by the IAB in 2019 resolved this issue, it’s still taken time to work out the kinks specific to TV.
The regular ads.txt standard gives publishers an easy way to list which companies are authorised to sell their inventory, via an ads.txt file hosted on their domain. The aim of the standard is to help buyers spot fraudulent inventory sources and ‘domain spoofing’, where fraudsters mimic a legitimate publisher’s domain in order to sell inventory.
The app-ads.txt standard essentially adapts this idea to work in app environments – both mobile and CTV – which don’t have a domain on which they can list their ads.txt files. In these environments, app-ads.txt helps fight app spoofing, where fraudsters make it look like impressions are being generated by legitimate apps in order to steal ad revenues.
And recently, IAB Tech Lab has been working on improvements to the standard to help it deal with some of the specific characteristics of CTV advertising, namely the issue of multiple companies having ownership of inventory within individual apps.
The Technical Details
To implement the regular ads.txt standard, a publisher creates an ads.txt page within its domain, which can be found by adding ‘/ads.txt’ on to the end of the homepage web address (e.g www.theguardian.com/ads.txt).
In this file, the publisher lists the domain for each SSP and exchange authorised to sell their inventory, the publisher’s ID within those exchanges, the type of relationship each vendor has with the publisher (i.e whether they sell direct or are a reseller) and the type of inventory they’re authorised to sell.
Buyers can then use this information to check the legitimacy of information provided in bid requests.
For app-ads.txt, app owners can’t simply attach an ads.txt file to their domain, since there is no domain in the first place.
Instead, app developers provide a website URL within their app’s store metadata, and publish an ads.txt file on that domain, posting all the same information found within a regular ads.txt file. App developers are usually required to include a web address within their app store metadata anyway, which is typically used as contact information on the app’s store listing. So it’s simply a case of including an ads.txt file on this URL.
Interested parties can then crawl through app listings in order to find these ads.txt files. To be able to do so, they need to be able to recognise where within each app store they can find the developer’s URL for each app, and then crawl and interpret these pages to be able to tell whether an inventory reseller is legitimate or not.
To make this work, sell-side platforms and the app stores themselves also need to cooperate.
SSPs and ad networks need to include a ‘storeurl’ parameter within their bid requests. This specifies the individual app store listing for the app offering the impression, enabling buyers to find the relevant metadata. And app stores need to make sure this metadata is available for each app – namely the developer’s URL where the ads.txt file is found, and the app’s bundle_id or store_id (which identifies the app).
These adaptations to ads.txt allow it to work in a basic sense within app environments. But recently IAB Tech Lab has been working to solve the issue of ‘inventory sharing’, where multiple parties have the right to sell inventory within the same app.
For example, a Virtual Multichannel Video Programming Distributor (vMVPD) such as SlingTV, a device manufacturer such as Roku, and programmers (broadcasters or cable networks), such as ESPN, all might have the right to sell inventory within ESPN’s CTV app.
To solve for this, IAB Tech Lab has updated its specification for ads.txt files to include a new ‘inventorypartnerdomain’ variable.
Whichever company owns the CTV can include this variable within their own ads.txt files, which points towards a URL for another company who has the rights to sell inventory. That partnered company can then publish their own ads.txt files on that domain, listing their own authorised sellers.
The Pros and Cons
As fraud on CTV grows, with CTV’s high CPMs attracting bad actors, app-ads.txt is a simple way to help eliminate a portion of this fraud.
Last year Dimitris Theodorakis, director of detection for the Satori team at anti-fraud company White Ops, told VideoWeek that app-ads.txt makes it much harder to spoof CTV apps, and could have a significant impact in cracking down on CTV fraud. At the time, Theodorakis said work was still needed to tailor the app-ads.txt specification to CTV, meaning the latest updates are a welcome development.
But as with the regular ads.txt specification, app-ads.txt only works if everyone involved actually uses it.
A Pixalate study released last week shows that adoption from app owners is relatively high. Eighty percent of the top 500 CTV apps on Roku had adopted the standard as of Q4 last year, while 62 percent of the top 500 apps on Amazon’s Fire TV platform had app-ads.txt files.
But as VideoWeek has previously reported, buy-side adoption of the standard has historically been low. App-ads.txt doesn’t cut out fraud if buyers don’t actually check that bid requests they receive match up with an app’s app-ads.txt file.
And app-ads.txt isn’t a ‘set and forget’ tool – publishers need to be vigilant in keeping their app-ads.txt files updated. Failure to do so can lead to authorised resellers appearing illegitimate, or unauthorised resellers looking valid.