ads.txt Explained: Authorized Sellers, Not a Performance Guarantee

ads.txt Explained: Authorized Sellers, Not a Performance Guarantee

ads.txt Explained: Authorized Sellers, Not a Performance Guarantee

ads.txt is a public text file that a website publisher can use to declare the advertising systems authorized to sell that publisher’s digital inventory. It is part of the IAB Tech Lab’s supply-chain transparency work. The file can be useful for buyers, publishers, and intermediaries trying to understand an authorization relationship, but it is important to be precise about what it does and does not establish.

An ads.txt file is not a promise of revenue, traffic quality, viewability, brand suitability, regulatory compliance, or fraud prevention. It is also not a substitute for due diligence. It is one technical signal in a larger advertising supply chain.

What the file is for

The IAB Tech Lab describes ads.txt as an Authorized Digital Sellers standard. In practical terms, a publisher places a file at a predictable location on its domain, and the file lists advertising systems the publisher says are permitted to sell its inventory. A buyer or platform can retrieve the file and compare the declared relationship with information it sees elsewhere in a transaction.

That use case explains the name. The file is about declared authorization. It is not a performance report and it does not assign a quality score to a publisher, seller, or campaign.

Read a record as a declaration

A standard ads.txt record contains fields that identify an advertising system, an account or seller identifier, the relationship type, and sometimes a certification authority identifier. The exact syntax belongs in the technical specification; a nontechnical reviewer can still ask useful questions:

  • Which domain is named as the advertising system?
  • Which seller or account identifier is being declared?
  • Is the relationship described as direct or reseller?
  • Is the record current, legible, and located on the publisher domain being evaluated?

These questions do not decide whether a transaction is appropriate. They help a team understand what the publisher has declared and identify discrepancies that may need a technical or business follow-up.

Direct and reseller are relationship labels

Relationship labels are often treated as a ranking system. They are better understood as labels describing how the publisher characterizes the selling relationship with the named advertising system. A direct record and a reseller record can be relevant in different commercial and technical arrangements. The label alone does not establish price, inventory quality, exclusivity, buyer access, or the number of parties involved in a broader transaction.

When discussing these labels, avoid turning a technical declaration into a conclusion about a company or a campaign. A careful explanation says what the record represents and identifies the additional information required for a business decision.

Why absence needs care

An expected record may be absent because a relationship has changed, a file has not yet been updated, a domain has been entered incorrectly, a crawl has not refreshed, or a configuration problem exists. It may also merit investigation. The appropriate conclusion is not “absence proves wrongdoing.” The appropriate conclusion is “the expected declaration was not found, so the relationship should be checked with the responsible technical and commercial contacts.”

The same caution applies to a file that looks complete. A file can be correctly formatted and still leave questions that ads.txt was not designed to answer. For example, it cannot explain the commercial terms of a deal, validate a creative, or show what happened after an impression opportunity was offered.

A practical review sequence

  1. Start with the publisher domain. Retrieve the file from the site being assessed rather than relying only on a copied record.
  2. Record the observation. Note the retrieval date, file location, relevant record, and the question being checked.
  3. Compare identifiers carefully. Confirm that differences are not merely formatting, domain, or account-identifier mistakes.
  4. Ask for context. If the record is unexpected, ask the appropriate owner to explain the relationship or configuration.
  5. Use other evidence. Keep authorization review separate from decisions about quality, commercial terms, policy, privacy, or performance.

Use accurate language in reports

A concise report can be both useful and restrained. Instead of writing “this inventory is verified,” write “the publisher’s ads.txt file contained a record declaring this advertising system and seller identifier on the retrieval date.” Instead of writing “there is no fraud risk,” write “ads.txt is one supply-chain transparency signal; this review did not evaluate other risk factors.”

Specific language preserves the value of the standard. It tells readers exactly what was observed without asking the file to answer questions it was not designed to answer.

Sources