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.