Ads.txt is starting to get adopted by major players in the ads ecosystem, and the IAB is also developing new versions of the specification. But what does ads.txt solve, and what’s the benefit of using ads.txt? Is it possible to shoot yourself in the foot by implementing it?

In an effort to make ads inventory more credible (and prevent spammers from domain spoofing), the industry is beginning to adopt ads.txt. The IAB released a finalised initial specification of ads.txt mid-2017, in order to help combat fraudulent inventory in the ads ecosystem.

IAB

The IAB has estimated that $8.2 Bn worth of advertiser budget was spent on fraudulent content in 2015, of which $2.4 Bn was due to infringed content (spoofed domains), and the majority of the rest due to invalid traffic.

This number is mind-blowing considering how simple the solution to the infringed content problem is. Ads.txt sets out to give publishers a tool to prevent their domain from being spoofed and sold fraudulently by others, by allowing the seller accounts to be defined in a static file uploaded to the root of the domain (where the root of the domain is specified according to the Public Suffix list).

How do spammers create fraudulent inventory?

Fraudulent inventory, or infringed content is actually rather simple to create. All one has to do is request ads from ad networks and feed a different URL as the originating source of the impression. Depending on the ad network, it can be done in several ways, but to give you an idea, it can be as simple as specifying a parameter in the ad code.

Let’s take AdSense as an example. AdSense ad codes have the capability to specify certain parameters that are used in the ad request and how the ad unit is rendered on the page. They include:

  • Dimensions
  • Publisher ID
  • Ad unit ID

AdSense features an optional parameter that can be used to overwrite the URL where the ad request is originating from, and manually define it. This parameter is data-page-url and goes alongside the other parameters that are specified in the tag. Here’s an an example:

<ins class="adsbygoogle"
    style="display:block"
    data-ad-client="ca-pub-1234567890987654"
    data-ad-slot="1234567890"
    data-ad-format="auto"
    data-page-url = "http://example.com/"
></ins>

Now you can put that ad unit anywhere you like, on any page you like. As soon as it starts getting impressions, it’ll tell the ad auction that the impression is appearing from example.com, even though it may be coming from http://a-spam-site.com.

Why pretend that impressions are coming from somewhere else?

It all comes down to the money. It can be relatively easy to generate cheap traffic, and send it to a website that isn’t known at all with AdSense ads on it. By boosting the RPMs that are generated on a site, you effectively boost the earnings. One method of boosting RPMs is to pretend that impressions are coming from a well-known website. For example, if the impressions are spoofed to originate from nytimes.com, those impressions are likely to generate much higher RPMs.

Why does this parameter exist?

Now don’t get me wrong, this parameter can be extremely useful for websites that don’t render content statically. If you’re using Angular, React, or any other framework which dynamically loads content onto your page, you’ll need to use the data-page-url parameter. The reason is because crawlers (which are used to categorise your content, and enable contextual targeting) aren’t able to parse JavaScript very well in order to view the content on a page where the content is dynamically loaded in. Hence a canonical, static version of the page can be created to help crawlers see the content, and that same canonical URL can be passed in the data-page-url parameter to help the auction.

Why should I implement ads.txt?

The truth is you’ll only ever suffer from others spoofing your domain if your domain experiences high RPMs. Low RPM sites aren’t targets for spammers. If you do not implement ads.txt, there will be no impact to your earnings, and everything will remain as it is. However if you believe others are receiving ad budget that was intended for your site, by implementing ads.txt, you’ll begin to see more of that intended advertiser spend. It’ll drive up auction pressure, and as a result you’ll earn more money due to higher RPMs.

Having said that, adding an ads.txt file to your site is extremely easy, and there aren’t really any reasons to not implement it if you can. Better be safe than sorry.

The only problem to keep in mind is that if you have a complex ad setup, with relationships with many sellers and resellers, whitelisting them all in your ads.txt file can be quite difficult to do, and if you create an ads.txt file on the root of your domain (even if it’s empty) you risk all your earnings. Well if you create an empty ads.txt file on the root of your domain, you’re essentially saying that no one is allowed to sell that inventory. Similar to what YouTube has implemented on their ads.txt file:

youtube.com/ads.txt

How to implement ads.txt

It’s pretty straight-forward for most publishers. Upload a new file on the root of your domain named “ads.txt” (where the root of the domain is defined as one level down from what is listed in the Public Suffix list). Add the following content:

sellers-domain.com, account_id, type_of_relationship, certification_authority_ID

An example of an AdSense ads.txt implementation will be the following:

google.com, pub-0000000000000000, DIRECT, f08c47fec0942fa0

Real-life ads.txt examples

Below is a list of real implementations of ads.txt:

If you’re an AdSense publisher, you can learn more about it on the AdSense Help center, with slightly more information about what each field is.

Why aren’t many publishers using it yet?

The main reason is that no ad networks or ad exchanges are enforcing the use of ads.txt yet. Meaning whether or not you’ve uploaded an ads.txt file to your domain, it doesn’t get used in the auctions yet.

DoubleClick Bid Manager will start enforcing ads.txt rules soon (at some point in October 2017).

According to the DoubleClick Advertisers blog, DBM (DoubleClick Bid Manager) will start enforcing the existence of ads.txt by the end of October. According to the blog post:

We believe the ads.txt standard is a significant step forward in the fight against ad fraud, and by the end of October, DoubleClick Bid Manager will only buy a publisher’s inventory from sources identified as authorized sellers in its ads.txt file when a file is available.

It is important to note that many other players in the ads ecosystem such as AppNexus, Index Exchange, OpenX, Pubmatic, SpotX, Teads, Telaria and DoubleClick Ad Exchange are all supportive of the ads.txt standard, and are all expected to enforce it.

I can’t edit the root of my domain – what shall I do?

Short answer is don’t worry about it too much. Implementing ads.txt isn’t a requirement. It’s an optional step publishers can take to prevent others from spoofing their domains.

So in summary, I recommend creating an ads.txt file, but be careful to capture all the sellers you use otherwise you’ll risk all the earnings you currently have with sellers you miss out.