How does… ads.txt work?
In a new feature for Mumbrella, some of the industry's most knowledgable boffins break down industry jargon to help you through those confusing meetings and indecipherable conferences. This week, IAB Australia's Jonas Jaanimagi explains how ads.txt works.
What is it?
Ads.txt is a solution developed by IAB Tech Labs in 2017 as a way to increase transparency in the programmatic advertising space.
The ‘ads’ part stands for Authorised Digital Sellers and “txt” means, well, text. It is a text file that is hosted on a site’s domain declaring that it’s an authorised seller. It was invented to prevent criminals from monetising misleading ad opportunities via domain spoofing.
Need the simpler version please
There are some bad actors online who pretend to be someone else in order to make money from digital advertising (aka domain spoofing).
For example, one of these bad actors might be offering ad space on a sub-standard site – such as a conspiracy theory chat room – but be representing that space as if it were on a popular news site. Essentially, they are pretending to be a legitimate site when they aren’t. They do this by masking the identity of the URL in the programmatic bid stream.
Ads.txt was invented to stop them. If the good guys put the ads.txt text file on their website domain, it shows who the legitimate seller is – this means the bad actors can’t pretend to be anyone that they are not.
Got it. Is it easy to use?
Yes. It’s easy to put the file on a domain which you own; which in turn makes it easy for buyers of programmatic inventory to quickly and easily identify which sellers are whitelisted (aka authorised) to sell the inventories for certain publishers.
Think of it as a digital handshake between the publisher and an exchange that signifies a legitimate connection. The buyer can check to see if the correct parties are shaking hands, and if so, can be confident that the inventory they are buying will actually appear in the place they wish it to appear.
Hit me with some more of the tech stuff (less techie folk should skip to ‘Is it working?’)
A publisher will install the ads.txt text file on their root domain (or any necessary sub-domains), listing all the platforms, ad-exchanges or supply-side platforms (SSPs) sanctioned to directly or indirectly sell their inventory. Each listing on the root domain includes the publisher’s “seller account ID” for that particular SSP, which links it to that publisher’s account on that SSP.
The data needed to populate the file is available in OpenRBT protocols, making it easy to gather and target. In the programmatic bidding process, this publisher ID is transmitted through OpenRTB protocols as the “SellerAccountID” along with the publisher’s domain and the list of authorised sellers. It makes more sense if you consider the below example.
Demand-side platforms (DSPs) can crawl the web for ads.txt files and create a list of sellers authorised to handle inventory for specific publishers or domains. That list can then be used to create a filter that checks your ads.txt list with the data from OpenRBT bid requests. Matching IDs signal that the exchange or SSP is a sanctioned seller for that publisher.
The process is outlined in the infographic below.
Is it working?
Yes. Adoption of ads.txt got off to a sluggish start but it’s beginning to accelerate both globally and locally (it was given a boost when big companies like Google, AppNexus and a number of large marketers also got on board).
The latest global data from Pixalate published in January 2018, tells us that of the top 5,000 sites globally, 45.2% have implemented the ads.txt solution. When it hits critical mass (expected soon), ads.txt will all but eliminate domain spoofing – thus dramatically reducing globally the levels of fraud in programmatic advertising.
Jonas Jaanimagi is technology lead at IAB Australia. For more information on ads.txt click here.
Missed out some key points on how this isn’t working and has plenty of bad actors verified mate. Most initiatives from the Tech Lab aren’t thought through enough. Be good to hear what IAB AU is doing to improve this.
https://digiday.com/media/publishers-getting-fooled-ads-txt-fraud/
User ID not verified.
The ads.txt solution is very simple to implement, however publishers must always ensure that they fully understand and verify exactly who they are allowing onto the list as an authorised seller and re-seller. It’s their domain and their inventory, so they need to take control of who they verify to sell and/or resell it.
For additional guidance for publishers, also see this article on ExchangeWire
http://www.exchangewire.com/bl.....-traction/
As for the current limitations of the solution – these have been openly called-out by the IAB Australia from the very beginning. Simply review the initial support articles up on the site (www.iabaustralia.com.au/ads-txt) back in early October.
“…we will work with the IAB Tech Labs in New York to provide timelines for when we can expect a workable update for non-web environments (i.e. mobile apps), when we can expect the inclusion of a wider range of ad formats and guidelines on the forthcoming updates to the OpenRTB protocol (OpenRTB 3.0).”
For desktop inventory, the solution is now out there and buyers should insist upon it being utilised.
Moving forwards, we are now eagerly awaiting the opportunity to test the in-app solution with our members in the next month or so – and after testing intend to release the update and guidelines to the Australian market within the next couple of months.
User ID not verified.
C’mon, if publishers aren’t taking the care to actually have a relationship with people they put in their ads.txt file, they deserve to have their money taken. If ads.txt is too hard, they really don’t have the sophistication to play programmatic.
One avenue that is still open sneaky brand hacks like registering “guard1an.com” instead of guardian.com or “times.co.uk” instead of “thetimes.co.uk”, and marketers thinking they’re buying the kosher brand. Well vetted blacklists and whitelists required.
User ID not verified.