Ads.txt: what’s the function of the file?

Lots of websites finance them­selves through ad­vert­ise­ments. Adverts allow website providers to generate revenue and make the media content on their pages available to visitors for free. A big market for pro­gram­mat­ic ad­vert­ising (fully automatic sale and purchase of online ad­vert­ise­ment spots) has appeared as a result – and it sometimes handles pretty sub­stan­tial amounts of money. So it’s no wonder that there are also plenty of black sheep romping about in this area, trying to get a piece of the marketing cake without any actual effort. With the ini­ti­at­ive ads.txt, the In­ter­act­ive Ad­vert­ising Bureau (IAB) wanted to hamper attempts at ad fraud. Ad fraud refers to mock ad­vert­ising efforts that either aren’t provided at all, or only to an in­suf­fi­cient extent.

The In­ter­act­ive Ad­vert­ising Bureau (IAB) is an in­ter­na­tion­al advocacy group for the online marketing industry. Their goal is to strengthen the industry, develop standards, and sus­tain­ably improve online ad­vert­ising. Along with this, the as­so­ci­ation also endeavors to detect and prevent fraud within the industry. This concerns ad fraud in par­tic­u­lar, which squanders huge sums of money every year. Both ad­vert­isers and honest pub­lish­ers suffer from this type of fraud: While ad­vert­isers invest their money in scammers without receiving anything in return, website providers lose important revenue as cy­ber­crim­in­als pocket the money in their place.

Pro­gram­mat­ic ad­vert­ising functions auto­mat­ic­ally, for the most part: pub­lish­ers offer ad­vert­ising spots on their pages (e.g. on online magazines or blogs) and ad­vert­isers purchase or bid on these spots. The whole process usually takes place via a middleman – generally on a platform where sales or auctions take place. In this en­vir­on­ment, cy­ber­crim­in­als fre­quently rely on the domain spoofing scam: ad­vert­isers believe that they’re buying an ad space from a renowned publisher (e.g. the online presence of an in­ter­na­tion­ally re­cog­nised newspaper) – but the ads are later displayed on a com­pletely different page.

The platform on which the ad fraud takes place doesn’t even have to be involved in the fraud. Often, the operator has no idea that scams are happening on their site. With ad fraud, cy­ber­crim­in­als feign that the website that they want to place the ad­vert­ise­ment on is another, far more renowned one – in other words, they conceal the identity of their actual website. This is referred to as website cloaking. The website actually being offered usually has com­par­at­ively little traffic and often also has a bad repu­ta­tion that could even cast the ad­vert­iser in a bad light. The ads.txt file is meant to prevent such scams.

IAB uses “ads” as an acronym for “au­thor­ised digital sellers” – although the term “ad” is more often used as an ab­bre­vi­ation for “ad­vert­ising.” In this simple text file, the publisher should list out all providers that are permitted for the sale of their ad­vert­ising space. The file gives pub­lish­ers a greater say in trading their ad­vert­ising space. At the same time, it also ensures more trans­par­ency, as it specifies exactly which providers are to be co­oper­ated with.

Pub­lish­ers deposit the ads file into the root directory of their web presence, the uppermost directory of the website. This is where robots.txt is located, for example, which provides the in­form­a­tion for search engine crawlers. Ads.txt can also be processed by crawlers in the exact same way. The text file is pub­lic­ally ac­cess­ible and can be read by machines as well as humans.

Since the file is located in the root directory and is required to be called ads.txt (example.com/ads.txt), it’s pretty quick and easy to find: For example, the ads.txt files of The New York Times, The Guardian, or The Wash­ing­ton Post can be called up with no further ado. This way, ad­vert­isers and platforms can check whether the sale is even permitted by the merchant in question. If a publisher is listed on an ad­vert­ising mar­ket­place and the cor­res­pond­ing ads file can be checked by all those involved, then it’s sig­ni­fic­antly more difficult for scams to run on platforms that spoof a false identity that’s not listed in the ads.txt.

With ads.txt, it’s now veri­fi­able whether an offer is real or not. Some mar­ket­places, such as Google, have already im­ple­men­ted the standard on their own platforms. Ads.txt is auto­mat­ic­ally crawled if a publisher has made their inventory available. If the publisher hasn’t noted the mar­ket­place in their ads.txt file, then no trans­ac­tion can take place.

Since ads.txt is a simple text file, it can also be created with a simple text editor. There are three pieces of in­form­a­tion that are necessary for au­thor­ised sellers – and a fourth that’s optional.

• Domain name of the seller: the domain under which the company that is permitted to sell the ad­vert­ising inventory operates. The correct name can often be read directly from the provider or you can contact them to find out the correct domain name. For example, with Google offers, the correct name is always google.com.
• Account ID: if you’re re­gistered with a provider as a publisher, then you have an account iden­ti­fic­a­tion number. The same ID is also given for trans­ac­tions.
• Re­la­tion­ship to the provider: you can enter two different values for this field. If “DIRECT” appears here, then the publisher un­der­takes man­age­ment of their inventory on the platform them­selves (under the ID that’s entered in the second field). The entry “RESELLER” signals that the publisher has charged a third party with the man­age­ment.
• Cer­ti­fic­a­tion ID (optional): if the ad­vert­ising system is listed with a cer­ti­fic­a­tion body, you can name the cor­res­pond­ing ID here. One such body is the Trust­worthy Ac­count­ab­il­ity Group (TAG). If an entry is submitted here, you would enter the TAGID.

All of these fields are entered one after another within one line, with the in­di­vidu­al fields separated by a comma. If you want to include ex­plan­a­tions in the file that aren’t meant to be con­sidered by bots, you have to exclude them with hashes (#). Everything from the hash to the end of the line will be ignored. So if the character is put at the very beginning of the line, then the entire line will not be con­sidered.

In addition to the seller entries and comments, the standard also allows two other pieces of in­form­a­tion: “CONTACT” and “SUBDOMAIN.” Both values are entered into the file in the “Variable=Value” format, for example, “CONTACT=example.com/about_us.” While the first entry specifies a contact option, the second refers to an ads.txt file in a subdomain. Without the note on this second text file, bots would overlook it, because only the root directory of the main domain is usually crawled.

Whether you make an ads file yourself or prefer to have it created, how it should be made depends on how many platforms you work with. In principle, though, it doesn’t take much effort. If you’re a publisher and would like to protect your ad­vert­ising inventory from fraud in the future, you can create the required text file in just a few steps. To do this, open a text editor (like Editor on Windows or TextEdit on Mac, for example) and enter the required para­met­ers for the seller you’re working with. In our example, we’re working with Google for the ad­vert­ising spaces that we offer on our fic­ti­tious blog.

Here, we confirm that we have two different Google accounts. Account IDs on Google always follow the same pattern: “pub-” (publisher) followed by a 16-digit number sequence. Some pub­lish­ers have multiple accounts on platforms, if – like in our example – they’re logged into both AdSense and Ad Exchange. We can manage our own inventory in both accounts, and since Google has a unique TAGID, we also enter this.

To improve the clarity and provide in­ter­ested parties with more in­form­a­tion, we’ll specify exactly what the accounts are in the form of comments. We’ll also provide you with an e-mail address where you can contact us.

While the order of the in­di­vidu­al para­met­ers is already set, you can choose the order of the au­thor­ised sale platforms for yourself. For example, some pub­lish­ers split their lists so that all “DIRECT” entries come first, and then all “RESELLER” entries. Within the in­di­vidu­al para­met­ers though, there shouldn’t be any spaces, tabs, or commas. If these are necessary, for example because part of the ID has a space, then you need to use URL encoding: This method, also known as per­cent­age coding, uses the hexa­decim­al code of the character in the ASCII character set and places it directly after a per­cent­age sign. For example, a space is rep­res­en­ted by the character set “%20.”

When saving the file, make sure that you’ve stored it as a .txt file with the name “ads.” This is only way that ads.txt will be uploaded to the root directory of your server. This is possible with an FTP program, for example. The root directory is hier­arch­ic­ally the highest. Now you should be able to access the file under example.com/ads.txt.

Using an online generator can be worth­while, es­pe­cially if you work with lots of platforms. Some of them offer the service in exchange for your e-mail address, while others – such as the generator in Google’s DFP network – only add the entries to the text file for your own mar­ket­place.

With an ads.txt validator you can check whether your au­thor­isa­tion file was correctly created and no errors crept in. For most val­id­at­ors, it’s usually suf­fi­cient to enter the URL. Some web services also offer an option to directly upload the file and so check it before pub­lish­ing it on your own website. The ads.txt validator from AppNexus, a pro­gram­mat­ic ad­vert­ising platform provider, even allows users to make changes to the file directly in the tool, check them right away, and then download the new file. You then just have to transfer the altered ads.txt to your server.

But an ads.txt validator only checks if the syntax in the entries is correct. The online tools don’t check whether the in­form­a­tion is true. This is important for ad­vert­isers, though: it’s not possible yet to use a validator to check if the publisher actually works with the named platforms.

Like so many standards, ads.txt didn’t catch on right from the beginning. One definite reason for its initially re­strained use in the industry was un­cer­tainty: How would the file influence in­di­vidu­al busi­nesses? It was only when the heavy­weight Google started sup­port­ing the ini­ti­at­ive and insisted on using the file from that point on that ads.txt gradually prevailed.

One point that has created un­cer­tainty within the industry is that resale of inventory is somewhat com­plic­ated. Providers buy ad­vert­ising space from a platform and sell it on their own. This isn’t always fueled by criminal intent, but ads.txt prevents such behavior. Pub­lish­ers have no direct con­nec­tion with these resellers and often know nothing about the processes. As a result, the provider doesn’t appear in the ads.txt file. This has caused some resellers to target pub­lish­ers, which in turn has generated a lot of dis­cus­sion within the industry and is seen by many as an attempt at fraud.

A point of criticism for many sellers is the manual creation of the file: it’s not guar­an­teed that there are no typos. An error can quickly creep into the domain name, and then the publisher’s inventory can no longer be traded on the platform. This can cause both the seller and the publisher to miss out on large sums of money. The use of an ads.txt validator, though, can sig­ni­fic­antly reduce the risk of typos, while checking whether the domain is con­ceal­ing a pro­gram­mat­ic ad­vert­ising mar­ket­place. And ul­ti­mately, typos can also be avoided through careful attention to the process.

Another weakness of ads.txt is the missing tagging of the type of agreed upon inventory: pub­lish­ers can’t use the text file to signal whether the seller may sell display ads, video ads, or both. This means that platforms can continue to pretend that display ads are actually ad­vert­ising space for video ads, and so receive ad­di­tion­al com­mis­sions. Just because a seller appears in an ads.txt, it’s still not guar­an­teed that they’re le­git­im­ate. The re­spons­ib­il­ity for not entering into an agreement with scammers lies solely with the pub­lish­ers.

You should also consider that ads.txt isn’t an all-purpose solution. Sure, you can protect yourself very well against domain spoofing with the file, but other forms of ad fraud remain un­af­fected. The ad­mit­tedly laudable ini­ti­at­ive still can’t put a stop to the fraud­u­lent tricks of im­pres­sion fraud and click fraud, which still cost ad­vert­isers a large portion of their ad­vert­ising budget.

Despite its weak­nesses, the ini­ti­at­ive is still widely accepted in the industry and will continue to influence the ad­vert­ising market in the future. Through the support of huge market players such as Google or well-known pub­lish­ers, ad fraud scams can at least be put to a stop, because all other com­pet­it­ors have to follow suit with the im­ple­ment­a­tion of ads.txt – unless they want to be at a dis­ad­vant­age when it comes to dealing in online ad­vert­ising spaces.