Reducing Fraud & Increasing Transparency with App-Ads.txt

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 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….