The IAB’s new Ads.txt initiative — what does it mean for Video Publishers?
https://iabtechlab.com/ads-txt/ — An IAB initiative as a step towards cutting down on fake ad-requests for domains, allowing publishers (domain owners) to publically declare the Exchanges authorised to sell their inventory.
What’s the overview?
- Aim is to remove domain spoofing and arbitrage, not bot fraud.
- Spoofed ad requests fraudulently inflate the amount of inventory available for a domain, thus diluting the price the real owner can sell it for themselves; ads.txt removes criminals’ incentive for spoofing a particular domain.
- There’s still a lot of education needed in the industry, and a large amount of use-cases that aren’t covered by this, but it’s a solid first step.
- Well thought out & led by Neal Richter (Ex CTO Rubicon), the IAB working group with members from across the industry.
- Expectations set that this is just the first version, with future versions providing more use-case coverage.
How is it implemented?
- A publisher publicly lists the Exchanges, and account IDs that are approved to sell their ad-space in a file called Ads.txt on their domain e.g. http://uk.businessinsider.com/ads.txt
- DSPs crawl the domains they’ve previously served impressions on looking for this /ads.txt.
- When a standard OpenRTB BidRequest is made from an Exchange to the DSP, it checks the declared Domain and Publisher ID against the ads.txt previously crawled from that domain.
- No match — no Bid.
- If no ads.txt is present, it’s considered open for any Exchange to sell
What’s required for success?
- A critical mass of publisher adoption before DSPs implement crawler & filters.
- Educating Advertisers to take action on the data.
- Publishers have to keep their sellers list up to date, especially as they add new vendors.
- Dealing with international reselling will be very messy. e.g. publisher allows an exchange or ad network to sell in one geo but not others.
- Ambiguity with top level domains will be another problem e.g. big publishers with lots of domains with complex policies.
- Gets complicated for publishers with distributed or syndicated content across many domains they don’t own, especially if those embeds are done by users.
What does an ads.txt file look like?
Check out a live example: http://uk.businessinsider.com/ads.txt
It’s a standard CSV format, which could either be dynamically generated or simply a file, just named ads.txt. Publishers should host the “/ads.txt” file on their root domain and not on subdomains.
Format specification: IAB Ads.txt Version 1.pdf
Some well laid out example use-cases — PartnerInteractionGuide_ads-txt.pdf
What isn’t covered in version 1?
- Doesn’t yet solve In-banner video arbitrage — future plan to add a 5th column for ‘Media Type’ will
- Not suitable for In-App inventory — that’ll come in OpenRTB 3.0
- Limits long tail Demand sources, where a publisher might have AdNetworks that provide high fill across non-core geos with an ever changing list of local demand sources
- Domain spoofing could still get through if the Exchange or DSP is complicit, particularly where a company owns the full stack.
- Gets complicated when dealing with syndicators or where video players are embedded on other sites.
- Agencies will probably want changes as they are large arbitrageurs themselves (albeit under a nicer name).
What’s special about Video then?
- VPAID true domain detection
Most domain spoofing can be caught before the initial Ad Request, with the VPAID wrapper providing a way to run ‘true domain’ detection code.
The problem comes when less scrupulous or sophisticated SSPs are the originating source. If they don’t run code to detect the true domain, and unmask any fraud, then any subsequent Bid Requests they make will be compromised.
- Content Syndication
For anyone producing video, relying on views on your own site generally doesn’t cover cost of production. Syndicating it across Facebook, apps and other publishers on a revenue share model is key.
Generally the content producer will syndicate the content wrapped in their own Video player, with their own Exchange accounts. For valuable content like sports highlights, they’ll sell any inventory for far more than the embedding publisher could as a package directly to brands.
e.g. Football highlights pre-roll to Nike
The content syndicator will need to have all their Exchange accounts added to the embedding publishers /ads.txt. This won’t give away any sensitive commercial information, but will validate that the syndicator has the right to sell inventory created on the publisher’s domain.
This creates a workflow bottleneck, which could potentially lead to delays if the syndicator changes or adds Exchanges. In future versions of the Ads.txt there is potential for a ‘related’ flag. The embedding publisher would simply add one line linking to the syndicators own ‘/ads.txt’ file
e.g. A line in publisher1.com/ads.txt -> ‘related: syndicator.com/ads.txt’
- Users sharing & embedding
Most Video players can be easily taken and embedded in social media, news sites, or even personal blogs like Tumblr. The owners of these sites have no relationship with the video player owner, and won’t add anything special to their own /ads.txt file.
Any inventory created by the embedded video player will therefore either be discarded by DSPs, or need to be explicitly packaged as ‘embedded inventory’ and sold via a PMP — ideally with a domain whitelist for brand safety.
What’s to stop a spoofing domain using the ads.txt file from the real site?
In this case the exchange would need to be complicit in the fraud, or the defrauded publisher would just get paid for the fake impressions. Something all DSPs should be wary of, especially if they accept traffic from bid-syndicators.
What will future versions contain?
- Plans to work with in-app inventory.
- Cryptographic signing of the adrequest at the legitimate source of inventory will remove more fraud from the eco-system.
- Adding a 5th column to specify the ‘media-type’ — video/display/native etc
- Exchanges providing an open API to list all the domains approved per publisher, or even just that a publisher is valid on their platform
This is a great first step, and shows the industry actually cares about getting rid of fraud.
- The IAB, the authentication working group, and Neal Richter (ex CTO of Rubicon) especially should be congratulated on an elegant initial solution taking into account many use-cases, laying the groundwork for a more comprehensive one to come.
- It requires critical mass of adoption, but once hit it should remove a large amount of domain spoofing and arbitrage.
- It will no doubt need tweaks and custom extensions to get over Publishers concerns about too much transparency on their pricing, and Agencies that do their own arbitrage — albeit under a better name.
- Well thought out plans for the future, which are still open for consultation — i actively encourage anyone with concerns or suggestions to get in touch with them.