Reducing fraud & increasing transparency with app-ads.txt

By Kate Dye
Wednesday, January 28, 2021

Last year, the IAB Tech Lab released the specs for app-ads.txt in an effort towards reducing fraud with app-ads.txt

Publishers list the vendors that are authorized to sell their inventory and advertisers use it to validate that a company’s access to a publisher’s inventory is in fact permitted. Without such a list, anyone could claim to have HBO or Wapo inventory. Here’s how the industry is working towards reducing fraud and increasing transparency with OTT/CTV app-ads.txt

A lack of transparency precipitates fraud

Fraudsters profit from a lack of transparency in the advertising supply chain. And since OTT already faces the opacity of server-side ad insertion, the relatively familiar implementation of app-ads.txt should be a quick win for everyone. And with 59% of buyers increasing their investment in the channel, all more more reason to clean things up.

For the biggest mobile app developers who are generally familiar and attuned to new adtech announcements, adoption was easy. And with some gentle prodding and help from various monetization companies, smaller developers have largely gotten on board, too. Today 73 % of iOS apps and 53% of Android have an app-ads.txt file.  

But that’s for mobile. In the mobile ecosystem, you only need to account for about two OSs—Apple and Android. They have different names for it, but they ultimately both have a unique id for each app in their store, which is conveniently standardized as a store id. The unique id is in the webpage URL for that app and the format is fairly consistent. And both app stores have offered a way to link to an app-ads.txt. 

While this likely sounds incredibly straightforward, the bad news is that OTT does not follow these guidelines. Each platform has its own way of exposing the store id and reducing fraud. Not all offer a link to a file. 

Roku’s unique id is a number that you can find in the html code on the webpage for that app. It’s not in the URL. Most others including Samsung, Amazon, and Vizio maintain the consistent store-id-the-URL approach, but when I took a sample of bundle ids from the requests we receive today on DMX and ‘reverse-engineered’ to get the store URL, I was redirected to their homepage, got 404s, and only some of the time…it worked. 

Now, I can find the app in the store and validate the store id that way, but not being able to go to the app’s page directly makes validation harder and can make it harder to build scripts—these scripts could unknowingly label legitimate apps fraudulent OR be forced to create so many exceptions, fraudsters sneak through. 

And once you find the app, there often isn’t an obvious link to the publishers website to find the authorized buyers txt file. A sample of links from Amazon TV pages took me to a few corporate subdomains that I could work from to find the actual page. The LG store didn’t offer a formal place for a link but apps that provided CCPA links gave me enough of a hint to do the same. Neither of these are something you could build into a scalable script. 

But overall these are taxonomy and naming problems—semantics that will be argued over and eventually (hopefully) resolved. 

Let’s assume everything works and a buyer can validate the inventory they are receiving is authorized—they took the publisher id, went to the store url using the unique id, the app store linked them to a webpage and they found the app-ads.txt and the publisher id in question was there.

But why send incorrect bundle ids?

There are valid reasons publishers would have done so. Some TV platforms have a default-like app with many channels. Samsung TV has a native Samsung TV Plus app, with channels ranging from Lego to CBS to Chivetv. Unfortunately many buying systems rely on an old assumption that the store id would tell you the content—Angry birds has its own id, separate from CandyCrush. 

In my sampling, I also found proper store ids, but pre-pended with the channel info. While incorrect, its a sensible effort to communicate information they know buyers are looking for. You may even argue that we need to expand the notion of store id, rather than sticking to the narrow scope we used in mobile.

As a stopgap, the bundle ids in the wild are defined by publishers and contain other information such as the channel, device make, or store. As a result, it can be impossible to answer what seems like a very simple question:  “Does publisher X have rights to sell inventory on CTV app Y?” 

To make matters worse, content syndication and monetization relationships in OTT are incredibly convoluted. MVPDs like DirectTV or Hulu have the rights to monetize content, but only in their app. Another example. So common sense methods like manually tracing inventory back to a content owner won’t work.

Much of the nuances of content and monetization rights are not actually covered by ads.txt and will require further guidance before we can establish broad transparency and trust from all players. But that’s a story for another post…. 

To end this one, let’s reiterate the key adoption gaps:

app.add.txt public

CTV apps need to have a publicly accessible and crawlable app store and page for each app.

app.add.txt list ids

CTV app stores need to list the website where the ads.txt can reliably be found.

app.add.txt bundle

Publishers need to send the proper bundle id and send the store url in the bid request .

app.add.txt support

Publishers and SSPs need to support the content, producer and other attributes in the bidstream, instead of layering that information elsewhere.

district m employee Stephen Denham

Kate Dye
Product Lead, DMX

Kate has spent her career in martech: from startups, to publishers, to setting new standards at the IAB techlab and building future-proof products on DMX.

Check out our solutions in action

Get in touch to schedule a live demo of our platforms with one of our dedicated experts.

Get in touch with one of our experts

If you’re interested in learning more about how we can help your business, reach out to us!