Key Takeaways

• Authorized Digital Sellers (ADS) is the umbrella framework from the IAB Tech Lab. It includes ads.txt, app-ads.txt, and sellers.json as its core components.
• ADS sets up a two-sided verification system. Publishers declare authorization (ads.txt). SSPs declare identity (sellers.json). Buyers check both sides.
• The framework evolved in phases. ads.txt came first for web publishers. app-ads.txt extended it to mobile apps. sellers.json added SSP-side identity verification.
• TAG certification builds on ADS compliance. The Trustworthy Accountability Group uses ADS adoption as a factor in its anti-fraud certification program.
• ADS isn't optional for serious programmatic revenue. Major DSPs enforce ADS standards in their bidding logic. Publishers without proper ADS implementation lose demand.

---

Understanding Authorized Digital Sellers (ADS)

When people in programmatic advertising talk about "ads.txt," they're actually talking about one piece of a bigger framework called Authorized Digital Sellers, or ADS.

The IAB Tech Lab designed ADS as a comprehensive system for declaring, verifying, and enforcing authorization across the programmatic supply chain.

Understanding the full framework matters because the individual standards (ads.txt, app-ads.txt, sellers.json) are designed to work as a system. Implementing one without understanding the others leaves gaps that cost revenue.

What ADS Covers

The Authorized Digital Sellers framework has three core specifications:

ads.txt (Authorized Digital Sellers for Web)

The original specification, released in 2017. Publishers host a plain text file at their root domain (/ads.txt) listing every SSP, exchange, and reseller authorized to sell their web inventory.

Each line contains:

• The exchange or SSP domain
• The publisher's account ID on that exchange
• The relationship type (DIRECT or RESELLER)
• An optional TAG-ID for certification

ads.txt addresses web-based inventory. It needs the file to be hosted on the same domain where the ads appear, which is what ties the authorization to the actual publisher.

app-ads.txt (Authorized Digital Sellers for Apps)

Released in 2019, app-ads.txt extends the same concept to mobile and CTV applications. Since apps don't have domains in the same way websites do, app-ads.txt uses the app store listing's developer website URL as the hosting location.

The file format is identical to ads.txt. The difference is in how it's located: through the developer URL registered in the Google Play Store or Apple App Store, then checking that domain for the app-ads.txt file.

sellers.json

Also released in 2019, sellers.json flips the perspective. Instead of publishers declaring who's authorized to sell, SSPs and exchanges declare the identity of every seller on their platform.

Each entry maps a seller_id to a business name, domain, seller type, and confidentiality status. This gives buyers the identity verification layer that ads.txt alone doesn't provide.

How ADS Creates a Verification Loop

The framework creates a verification loop where authorization flows in one direction and verification flows in the other:

Publisher side (ads.txt/app-ads.txt): "I authorize SSP-X account 12345 to sell my inventory as a DIRECT seller."

SSP side (sellers.json): "Account 12345 on our platform belongs to Publisher Corp at publisher.com. They're a PUBLISHER type."

Buyer side (verification): "The publisher says SSP-X is authorized. SSP-X says account 12345 is Publisher Corp. The domain matches. The relationship type matches. This supply path is verified."

When both sides declare consistent information and the buyer cross-references them, the full authorization and identity chain is established. This is the core design of ADS.

The DIRECT and RESELLER Distinction

One of ADS's most important concepts is the distinction between DIRECT and RESELLER relationships.

DIRECT means the publisher has a direct business relationship with the SSP or exchange. The publisher's ad server sends requests to that SSP. Payment flows directly from the SSP to the publisher. In sellers.json, this maps to seller_type: PUBLISHER.

RESELLER means an intermediary is involved. The publisher authorized SSP-X, but the inventory actually reaches SSP-X through another entity. In sellers.json, this maps to seller_type: INTERMEDIARY.

This distinction matters for supply path optimization. DSPs generally prefer DIRECT paths because they're shorter, have fewer intermediaries extracting fees, and are easier to verify. A supply path marked DIRECT in ads.txt but showing multiple hops in the SupplyChain object raises questions.

Mislabeling the relationship type (marking a reseller as DIRECT or vice versa) creates a verification mismatch. The ads.txt says one thing. The sellers.json says another. The DSP's trust in that supply path drops.

TAG Certification and ADS

The Trustworthy Accountability Group (TAG) runs an anti-fraud certification program that uses ADS adoption as one of its criteria. TAG-certified companies are expected to:

• Keep accurate ads.txt/app-ads.txt files
• Keep accurate sellers.json files
• Use the TAG-ID system to identify certified entities
• Participate in industry anti-fraud initiatives

The TAG-ID that appears as the fourth field in ads.txt entries is a certification identifier. When present, it tells DSPs that the SSP or exchange has been certified by TAG, adding another layer of trust.

TAG certification isn't needed for programmatic participation, but many large buyers prefer or require TAG-certified supply partners. Having TAG-IDs in your ads.txt entries signals to buyers that your SSP partners meet industry anti-fraud standards.

ADS Adoption Numbers

ADS adoption has grown significantly since the initial ads.txt release:

• ads.txt: Adopted by the vast majority of publishers who participate in programmatic advertising. Coverage among top publishers exceeds 90%.
• app-ads.txt: Adoption is lower than web ads.txt but growing. Many app developers still haven't implemented it, particularly smaller studios and developers outside the US and EU.
• sellers.json: Adopted by most major SSPs and exchanges. But data quality varies wildly. Some sellers.json files have high rates of confidential entries or stale data.

The gap between adoption and accuracy is where revenue leaks occur. Having ads.txt is necessary. Having an accurate ads.txt that cross-verifies cleanly against sellers.json is what actually drives premium demand.

Common ADS Implementation Gaps

Missing Entries

The most basic gap: a publisher sells through an SSP but doesn't include that SSP in ads.txt. Or the SSP has the publisher as a seller but doesn't include them in sellers.json. Every missing entry is a failed verification.

Inconsistent Data

The account ID in ads.txt doesn't match the seller_id in sellers.json. The domain differs. The relationship type conflicts. These inconsistencies create verification failures even though both entries technically exist.

Stale Files

Publishers add entries to ads.txt when they onboard a new SSP but never remove entries when they end a relationship. SSPs add sellers to sellers.json but don't clean up departed accounts. Stale entries don't cause direct verification failures for current relationships, but they expand the attack surface and cut overall file quality.

Confidential Sellers

SSPs marking publisher entries as confidential in sellers.json effectively breaks the identity verification loop. The authorization side (ads.txt) is complete, but the identity side (sellers.json) is hidden. DSPs can't complete the verification.

What Publishers Should Do

Implement all applicable ADS specifications. If you have web inventory, keep ads.txt. If you have app inventory, keep app-ads.txt. Both should be accurate and up-to-date.

Cross-verify against sellers.json regularly. Your ads.txt is only half the equation. Use BeamFlow's scanner to check every entry against the corresponding SSP's sellers.json and catch mismatches.

Use consistent account IDs. Make sure the account ID in your ads.txt exactly matches what the SSP has in sellers.json. Even minor formatting differences cause verification failures.

Request TAG-IDs from SSP partners. If your SSPs are TAG-certified, include their TAG-IDs in your ads.txt entries. This extra signal helps your inventory in DSP evaluation.

Clean up stale entries. Remove SSPs you no longer work with. Remove reseller entries for relationships that have ended. A lean, accurate file is better than a big, outdated one.

Frequently Asked Questions

Is ADS the same as ads.txt?

No. ADS (Authorized Digital Sellers) is the framework. ads.txt is one specification within that framework. ADS also includes app-ads.txt and sellers.json.

Do small publishers need ADS?

Yes. DSPs check ads.txt regardless of publisher size. A small publisher without ads.txt loses the same percentage of potential demand as a big publisher without it. The absolute dollar amount is smaller, but the proportional impact is the same.

Does ADS prevent all ad fraud?

No. ADS prevents domain spoofing and unauthorized reselling, which were two of the biggest fraud vectors. Other forms of fraud (invalid traffic, click fraud, viewability fraud) need different countermeasures.