Reducing Fraud & Increasing Transparency with App-Ads.txt

4
at
4
minutes
Technical Level
August 6, 2021
Kate Dye
Product Marketing Manager
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….

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

No items found.
About Behind Headlines: 180 Seconds in Ad Tech—

Behind Headlines: 180 Seconds in Ad Tech is a short 3-minute podcast exploring the news in the digital advertising industry. Ad tech is a fast-growing industry with many updates happening daily. As it can be hard for most to keep up with the latest news, the Sharethrough team wanted to create an audio series compiling notable mentions each week.

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

About Calibrate—

Founded in 2015, Calibrate is a yearly conference for new engineering managers hosted by seasoned engineering managers. The experience level of the speakers ranges from newcomers all the way through senior engineering leaders with over twenty years of experience in the field. Each speaker is greatly concerned about the craft of engineering management. Organized and hosted by Sharethrough, it was conducted yearly in September, from 2015-2019 in San Francisco, California.

Listen to Next—
3:00
August 13, 2021
Behind Headlines: 180 Seconds in Ad Tech — Fraud in CTV & Focus on Privacy
This week in Behind Headlines: 180 Seconds in Ad Tech we’re covering acquisitions, CTV fraud, privacy sandbox updates, and a new DSP launch.
3:00
August 6, 2021
Behind Headlines: 180 Seconds in Ad Tech — The Metaverse & Google Under Fire
This week in Behind Headlines: 180 we're covering the Metaverse, Google's antitrust suit, streaming viewership and new ad formats.
3:00
July 30, 2021
Behind Headlines: 180 Seconds in Ad Tech — CTV Deals & Platform Safety For Users
This week in Behind Headlines: 180 Seconds in Ad Tech we’re focusing on CTV, IPOs, platform safety and privacy sandbox updates.
Watch Next—
3:00
July 2, 2021
Behind Headlines: 180 Seconds in Ad Tech — Delayed Cookies & Investments
This week in Behind Headlines: 180 Seconds in Ad Tech we’re talking about the delay in the depreciation of third-party cookies & news on IPOs.
3:00
June 25, 2021
Behind Headlines: 180 Seconds in Ad Tech — Power Plays & Privacy
This week in Behind Headlines: 180 Seconds in Ad Tech we’re taking a look at the role of competition and key player’s growing dominance.
3:00
June 18 2021
Behind Headlines: 180 Seconds in Ad Tech — Lawsuits & Set Backs In Addressability
This week in Behind Headlines: 180 Seconds in Ad Tech we’re talking about the rise in privacy and addressability, from lawsuits to setbacks.
Kate Dye
Product Marketing Manager

About the Author

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

More from this author