![In-App Ads.txt: What You Need to Know [VIDEO]](png/app-ads.txt_video_blog_about.png)
Did you know that in-app ads.txt is now available for mobile apps? This revolutionary ad tech dramatically improves trust and transparency in the digital ecosystem by allowing publishers to specify who is authorized to sell their inventory.
Ads.txt has already proven to be enormously beneficial and popular in the browser world, and it’s now finally available to mobile apps. To explain how it works in in-app environments and why it’s so advantageous, check out our latest Whiteboard Wednesday video featuring Sergio Serra from InMobi's product management team.
Hi, and welcome to a new version of Whiteboard Wednesday. Today we’re going to talk about a new innovation for the advertising ecosystem, more specifically for the in-app world, this extension of ads.txt.
Before digging in a little bit more into what ads.txt for in-app looks like, let’s try to assess what ads.txt was trying to solve in the ecosystem itself. So ads.txt is basically a file that gets uploaded into the website of the publisher, which is the property that publisher is trying to monetize against. And the file is supposed to basically look exactly like a ledger in which the publisher can list down the authorized sellers for that specific inventory.
So let’s look a little bit more into how the template and the schema will look like. So basically you have a domain, a publisher ID per the advertising platform and relationship type and certification authority. Now in the case of InMobi, being an SSP for that particular property, it would be inmobi.com comma 1234 or whatever publisher ID that we give to the publisher and then the relationship type, might be either direct or reseller, and then the certification authority, which happens to be a TAG ID.
I think one important thing to note is that once the IAB released ads.txt in 2017, publishers of course started to integrate and build to the spec massively. And the great thing is that towards 2018 we could observe a decrease in fraud of 10 percent and plus for the cases of domain spoofing. So ads.txt was trying particularly to solve for domain spoofing.
And let’s try to understand what domain spoofing is. So in this specific case you have a site, which is xyz.com, that is sending its request to an SSP, so this is a very legitimate use case, and the SPP will be as such sending the request to the DSP, which in turn might decide to bid against that specific property. But, let’s assume now a fraudster is trying to set up a fake site, which is abc.com, but in the request to the SSP is sending still the same site, which is xyz.com.
Now the DSP will not know that actually the ad that is trying to serve will be served in another property. And consequently this is a lose-lose situation because if you think about it, the publisher - the real publisher, which in this case is xyz.com - is not monetizing against the budget that the DSP was meant to allocate against this property. And on the other hand, the DSP on the demand side is wasting his budget because he’s sending an ad which is probably not in a brand-safe environment, and at the same time will not lead to any good performance.
So this is a massive innovation. This was a massive innovation for the whole ecosystem. But the problem with in-app was that for a web property like in this case, you are just supposed to append ads.txt to the domain or subdomain. But in the case of app, an app by definition doesn’t live online. It’s basically in the device, so you can’t just append ads.txt into its name but you rather need to find a way to retrieve a URL first.
So there was a need for standardization, and that’s where InMobi along with the IAB community sat and decided to face this problem by issuing a spec that was released on beta in 2018, in November 2018. And this is basically a guidance that applies to both the publisher and the app store.
So the need from a publisher in this case is just to go on its app store page in which the apps that he wants to monetize on are hosted. And over there it’s supposed to update the seller URL or developer URL field, and from that this will be basically the online resource from which eventually the ads.txt file, which for in-app again is app-ads.txt, will be found.
The second step that the publisher needs to do is to go practically to that site that again he owns and upload the app-ads.txt file accordingly. Now from here onwards, the same guidance as the desktop or web ads.txt will apply. So it’s exactly the same guidance, with some nuances on the subdomain that active, for instance not being supported anymore. But I would really invite everybody to just go on the IAB repository and take a look more granularly at both ads.txt and app-ads.txt guidance.
Now on the other hand, for the stores, there is another thing. So obviously IAB, it’s important to note, cannot really enforce standards. So IAB tries to give guidance and then it’s up to the stores to of course pick up and build to support this. So what the IAB community tried to release was a document in which they will describe, IAB will describe how to basically retrieve the same URL for finding the app-ads.txt.
So this happens through three new meta tags that the app store is supposed to support within the head tag of the HTML page of the bundles. And these three new meta tags are appstore:developer_URL, appstore:bundle_ID and appstore:store_ID.
Now the flow will be as follows: Once this is deployed by the app store, the DSP is supposed to visit the page of the store ( plus app store ID) where the bundle is, and from here it will check for the bundle is looking for. So if the lookup is correct, then it will just retrieve the developer URL. And from here it will just cache the app-ads.txt file and at the run time, whenever it gets the request, whenever the DSP gets the request, it will just verify that for that specific vendor, there is a name tree for InMobi or for any other SSP.
So this is as simple as this, but obviously even if these are smaller in terms of implementation, this might change the whole stack of an app store. So obviously not everybody would be building to this. But this is not a friction because actually if the store hasn’t built to support this, the implementer should just try to look at any other way to, a methodology, to retrieve that seller URL field, which could be through an API that they might expose or by just parsing the HTML page of the bundle.
Now I think this big innovation - of course InMobi’s a huge supporter of this, so we really recommend if you’re a publisher to go and take the steps that we just described, and should you have any questions reach out to InMobi - and please go and check out the IAB repositories for ads.txt and app-ads.txt.
Note: To view the latest specs on ads.txt and app-ads.txt from the IAB Tech Lab, go to iabtechlab.com/ads-txt.
Be sure to check out these resources:
Register to our blog updates newsletter to receive the latest content in your inbox.
