Ads.txt is an initiative launched by the IAB (Interactive Advertising Bureau) in 2017 to stop the unauthorized reselling of publishers’ inventory and clean up the ad tech ecosystem by increasing transparency in the supply chain.
At the heart of the initiative lies the assumption that publishers can and need to keep track of all their authorized sellers and report to the buy-side about the type of relationship they have with each seller – either Direct or Reseller. This tracking is done through a file called “ads.txt” (which stands for Authorized Digital Sellers text file) in a predetermined path that everyone can access.
The initiative was a success, with the majority of publishers adopting it. Some criticism that surrounds ads.txt is that many publishers do not fully understand the logic of how to work with the file correctly. This confusion can lead to errors that allow many unauthorized sellers into the supply chain, files not being updated frequently, non-existing partners not being removed, and other problems.
To read more about ads.txt, go to this article in the IAB Tech Lab.
App-ads.txt was released by the IAB Tech Lab as an extension of ads.txt that supports both mobile app and CTV environments. It aims to improve transparency in app-specific inventory by providing the same information found in a regular ads.txt file, listing all the app's authorized sellers and more specific data for CTV, such as inventory partner.
Instead of attaching the file to an online domain, app developers provide a website URL within their app store's metadata and publish an ads.txt file on that domain. Buyers can crawl developer sites and gather app-ads.txt data to match the data they receive with a bid request to help them validate the legitimacy of each seller.
There are two ways a publisher can sell their ad inventory through programmatic bidding systems: Reseller or Direct. Reseller means a publisher authorizes another company to sell its inventory on its behalf.
There are two ways a publisher can sell their ad inventory through programmatic bidding systems: Reseller or Direct. Direct means a publisher works with an ad tech vendor or ad exchange to sell its ad inventory directly to the buy-side.
Seat ID is the same as “seller network ID” or “publisher ID.” It is an ID associated with a publisher’s or seller’s account on an ad tech vendor platform or ad exchange platform. The “Seat ID” is a unique number mentioned in an ads.txt file that represents an ad tech company working with the publisher directly or indirectly. The Seat ID is transmitted as part of the OpenRTB protocol as the publisher ID and the publisher’s domain in the publisher’s object.
Domain spoofing is a type of ad fraud where low-quality inventory is passed off as high quality or a premium site. Domain spoofing can be done in several ways, such as URL substitution, where fraudsters deceive advertisers at bid time by substituting a fake URL through an ad exchange or network, so the ad goes to a different site instead of the one that was bid on.
Tricky domain spoofing tactics come in many forms. For instance, custom browsers where bots can make the URL of any site appear as a different premium site, so the ad reports back the "spoofed" higher value URL. Another example is fake human browsers, where malware injects an ad inside a premium site, but the premium site is not paid for the ad. Instead, the fraudsters collect the revenue. Another method is cross-domain embedding, where two sites are paired together – one with high traffic and low-quality content and one with low traffic and safe content.
As noted by the IAB, dark pool sales houses aggregate thousands of ads.txt lines across thousands of domains. Misstating RESELLER traffic as DIRECT puts the traffic at risk because it is misrepresented to demand partners. Partnering with these entities or facilitating such activities might result in reputational damage or even blocked traffic.
Sellers.json is the mirror image of ads.txt. In ads.txt files, publishers report to buyers about their relationship with every seller representing them. In sellers.json files, sellers report to the buyers about the type of relationship they have with each publisher. Both methods help buyers build a fully transparent picture of the supply path to target the most efficient route of each available impression.
Like ads.txt, sellers.json is a file posted in a predetermined place where sellers (mostly exchanges, SSPs, and other ad tech vendors that represent supply) update their relationship status with every publisher. By scanning those files, DSPs can build a full map, including multiple hops/nodes that sometimes occur between the buyer and publisher to help them choose the most efficient path to the publishers and ultimately cut costs.
Seller ID is the same as “seller network ID” or “publisher ID”. It is an ID associated with a publisher’s or seller’s account on an ad tech vendor platform or ad exchange platform. The “Seller ID” in a sellers.json file needs to be the equivalent to the same seller’s “Seat ID” in the ads.txt file. This ID is transmitted as part of the SupplyChain object, allowing buyers to validate the inventory source, including the ability to identify direct inventory versus reseller inventory.
Seller type “PUBLISHER” indicates that inventory sold through this entity is on a site, app, or other medium owned by the listed entity. The advertiser pays the publisher directly.
Seller type “INTERMEDIARY” indicates that the listed entity sells inventory on behalf of the inventory owner or a third-party vendor. The Intermediary seller does not own the inventory it sells.
Seller type “BOTH” indicates that both types of inventory are sold through this entity, including sites or apps owned by them, as well as sites or apps owned by others.
In a sellers.json file, the “Confidential” field indicates whether the seller is confidential or not. There are two possible indications; 0 = not confidential, and 1 = is confidential (meaning the publisher’s name and the domain would not appear in the sellers.json file). There might be several reasons for defining the seller as confidential, and it is up to the entity who published the sellers.json file.
The OpenRTB SupplyChain object (aka “schain” in bid requests) enables buyers to see all parties selling or reselling a given bid request. The SupplyChain object is composed mainly of a set of nodes, where each node represents a specific entity that is participating in the transaction of the inventory. The entire chain of nodes, therefore, represents all entities involved in the direct flow of payment of inventory. This lets the buyer see not only which exchange or SSP the inventory came from but also the entire payment trail back to the original content creators.
Buyers.json is an initiative from the IAB Tech Lab. It is designed to bring transparency to the buy-side, in the same way, sellers.json did for the sell-side. The buyers.json file is published by DSPs to identify the names and ID of the buyers they represent. This helps validate buyers and rapidly flag up any suspicious activity to prevent fraud.
The DemandChain Object is a new buy-side transparency standard introduced by the IAB Tech Lab in June 2021. It mirrors the Supply Chain Object, enabling sellers to see all parties involved in buying the creative embedded in a bid response used in OpenRTB.
Programmatic advertising is the process of automating the buying and selling of digital advertising space in real-time through an automated bidding system. Programmatic advertising enables buyers to decide which ad call to buy and how much to pay for it within milliseconds through a sophisticated ecosystem.
Automating the media buying process enabled many small and medium advertisers and publishers to step into the online advertising ecosystem, building internet economics that allowed the world wide web’s exponential growth.
The joining of so many buyers and sellers to the online advertising ecosystem also introduced new threats. Those threats come in the form of unauthorized reselling of traffic, fraud botnets, spoofing domains, and other methods of fraudulent activities that aim to take a share of the $120B yearly ad spend.
Ads.txt is an initiative launched by the IAB (Interactive Advertising Bureau) in 2017 to stop the unauthorized reselling of publishers’ inventory and clean up the ad tech ecosystem by increasing transparency in the supply chain.
At the heart of the initiative lies the assumption that publishers can and need to keep track of all their authorized sellers and report to the buy-side about the type of relationship they have with each seller – either Direct or Reseller. This tracking is done through a file called “ads.txt” (which stands for Authorized Digital Sellers text file) in a predetermined path that everyone can access.
The initiative was a success, with the majority of publishers adopting it. Some criticism that surrounds ads.txt is that many publishers do not fully understand the logic of how to work with the file correctly. This confusion can lead to errors that allow many unauthorized sellers into the supply chain, files not being updated frequently, non-existing partners not being removed, and other problems.
To read more about ads.txt, go to this article in the IAB Tech Lab.
App-ads.txt was released by the IAB Tech Lab as an extension of ads.txt that supports both mobile app and CTV environments. It aims to improve transparency in app-specific inventory by providing the same information found in a regular ads.txt file, listing all the app's authorized sellers and more specific data for CTV, such as inventory partner.
Instead of attaching the file to an online domain, app developers provide a website URL within their app store's metadata and publish an ads.txt file on that domain. Buyers can crawl developer sites and gather app-ads.txt data to match the data they receive with a bid request to help them validate the legitimacy of each seller.
There are two ways a publisher can sell their ad inventory through programmatic bidding systems: Reseller or Direct. Reseller means a publisher authorizes another company to sell its inventory on its behalf.
There are two ways a publisher can sell their ad inventory through programmatic bidding systems: Reseller or Direct. Direct means a publisher works with an ad tech vendor or ad exchange to sell its ad inventory directly to the buy-side.
Seat ID is the same as “seller network ID” or “publisher ID.” It is an ID associated with a publisher’s or seller’s account on an ad tech vendor platform or ad exchange platform. The “Seat ID” is a unique number mentioned in an ads.txt file that represents an ad tech company working with the publisher directly or indirectly. The Seat ID is transmitted as part of the OpenRTB protocol as the publisher ID and the publisher’s domain in the publisher’s object.
Domain spoofing is a type of ad fraud where low-quality inventory is passed off as high quality or a premium site. Domain spoofing can be done in several ways, such as URL substitution, where fraudsters deceive advertisers at bid time by substituting a fake URL through an ad exchange or network, so the ad goes to a different site instead of the one that was bid on.
Tricky domain spoofing tactics come in many forms. For instance, custom browsers where bots can make the URL of any site appear as a different premium site, so the ad reports back the "spoofed" higher value URL. Another example is fake human browsers, where malware injects an ad inside a premium site, but the premium site is not paid for the ad. Instead, the fraudsters collect the revenue. Another method is cross-domain embedding, where two sites are paired together – one with high traffic and low-quality content and one with low traffic and safe content.
As noted by the IAB, dark pool sales houses aggregate thousands of ads.txt lines across thousands of domains. Misstating RESELLER traffic as DIRECT puts the traffic at risk because it is misrepresented to demand partners. Partnering with these entities or facilitating such activities might result in reputational damage or even blocked traffic.
Sellers.json is the mirror image of ads.txt. In ads.txt files, publishers report to buyers about their relationship with every seller representing them. In sellers.json files, sellers report to the buyers about the type of relationship they have with each publisher. Both methods help buyers build a fully transparent picture of the supply path to target the most efficient route of each available impression.
Like ads.txt, sellers.json is a file posted in a predetermined place where sellers (mostly exchanges, SSPs, and other ad tech vendors that represent supply) update their relationship status with every publisher. By scanning those files, DSPs can build a full map, including multiple hops/nodes that sometimes occur between the buyer and publisher to help them choose the most efficient path to the publishers and ultimately cut costs.
Seller ID is the same as “seller network ID” or “publisher ID”. It is an ID associated with a publisher’s or seller’s account on an ad tech vendor platform or ad exchange platform. The “Seller ID” in a sellers.json file needs to be the equivalent to the same seller’s “Seat ID” in the ads.txt file. This ID is transmitted as part of the SupplyChain object, allowing buyers to validate the inventory source, including the ability to identify direct inventory versus reseller inventory.
Seller type “PUBLISHER” indicates that inventory sold through this entity is on a site, app, or other medium owned by the listed entity. The advertiser pays the publisher directly.
Seller type “INTERMEDIARY” indicates that the listed entity sells inventory on behalf of the inventory owner or a third-party vendor. The Intermediary seller does not own the inventory it sells.
Seller type “BOTH” indicates that both types of inventory are sold through this entity, including sites or apps owned by them, as well as sites or apps owned by others.
In a sellers.json file, the “Confidential” field indicates whether the seller is confidential or not. There are two possible indications; 0 = not confidential, and 1 = is confidential (meaning the publisher’s name and the domain would not appear in the sellers.json file). There might be several reasons for defining the seller as confidential, and it is up to the entity who published the sellers.json file.
The OpenRTB SupplyChain object (aka “schain” in bid requests) enables buyers to see all parties selling or reselling a given bid request. The SupplyChain object is composed mainly of a set of nodes, where each node represents a specific entity that is participating in the transaction of the inventory. The entire chain of nodes, therefore, represents all entities involved in the direct flow of payment of inventory. This lets the buyer see not only which exchange or SSP the inventory came from but also the entire payment trail back to the original content creators.
Buyers.json is an initiative from the IAB Tech Lab. It is designed to bring transparency to the buy-side, in the same way, sellers.json did for the sell-side. The buyers.json file is published by DSPs to identify the names and ID of the buyers they represent. This helps validate buyers and rapidly flag up any suspicious activity to prevent fraud.
The DemandChain Object is a new buy-side transparency standard introduced by the IAB Tech Lab in June 2021. It mirrors the Supply Chain Object, enabling sellers to see all parties involved in buying the creative embedded in a bid response used in OpenRTB.
Programmatic advertising is the process of automating the buying and selling of digital advertising space in real-time through an automated bidding system. Programmatic advertising enables buyers to decide which ad call to buy and how much to pay for it within milliseconds through a sophisticated ecosystem.
Automating the media buying process enabled many small and medium advertisers and publishers to step into the online advertising ecosystem, building internet economics that allowed the world wide web’s exponential growth.
The joining of so many buyers and sellers to the online advertising ecosystem also introduced new threats. Those threats come in the form of unauthorized reselling of traffic, fraud botnets, spoofing domains, and other methods of fraudulent activities that aim to take a share of the $120B yearly ad spend.
An ad exchange is a sales channel for multiple publishers and ad networks that can provide aggregate ad inventory to advertisers. It is an automated technology platform that facilitates auction-based pricing and buying in real-time.
Per IAB assurance guidelines, a platform that enables direct media buying and selling between exchange participants is not considered an ad exchange.
An ad network provides sales capabilities for publishers, with the ability to aggregate inventory and audiences from various sources in a single buying opportunity. There may be specific capabilities for different ad networks, such as unique targeting, creative generation, or optimization.
A seller is an entity that sells inventory to other companies in the ad tech ecosystem. There's no one clear definition as there are various types of "sellers", from publishers and ad-ops to ad networks and ad exchanges. Each one of these entities may have different technological capabilities and services, according to its activity essence.
An ad request is measured as the number of ad units on a site which requests ads to be displayed. An ad request is also referred to as ad inventory or ad calls and is reported each time a request was sent to the buy-side, even if no ads were returned.
While an ad request is a single request sent to a demand partner, that single request, when passed on to multiple bidders, becomes a bid request. The number of bid requests will always be higher than the ad requests.
A DSP is a technology platform that provides centralized and aggregated media from multiple sources, such as ad exchanges, ad networks, or sell-side platforms, with real-time bidding capabilities across different sources.
On a DSP, advertisers can buy impressions across a range of publishers’ sites, targeted to specific users based on set parameters, such as location or browsing history. The DSP automatically calculates which opportunities make the most sense for the advertiser to buy, with pricing determined by a real-time auction process, otherwise known as ‘real-time bidding’.
An SSP (which stands for ‘supply-side platform’ or ‘sell-side platform’) is a technology platform that provides outsourced media selling and ad network management for publishers.
SSPs can send one ad call to multiple buyers simultaneously and increase the chances to monetize it. Inventory managed by an SSP is purchased by aggregated buyers, such as DSPs or ad exchanges, helping publishers to increase their advertising revenue through these multiple channels.
An agency trading desk (sometimes referred to as ATD) is a set of services or technology platforms provided by a media agency to its advertisers. The trading desk plans, buys, manages, and optimizes programmatic ad campaigns on behalf of the advertiser. Trading desks typically offer additional services, including human oversight over automated processes, analytics, and reporting. Advertisers using a trading desk do not get direct access to the media inventory. They have to go through the trading desk. Trading desks can draw from one or more DSPs.
According to the IAB, brand safety is the practice of making sure brands are safe when advertising online. Moreover, brand safety refers broadly to any method that compromises digital advertising activity within the advertising chain, related to both fraudulent activity and a brand’s reputation.
Ad tech vendors and SSPs should provide a safe environment for ad trading by ensuring the inventory they represent is high-quality. The entire supply chain can be flagged as fraudulent or invalid by brand safety vendors’ detection tools that reveal different misleading inventory types. Using brand safety vendors, such as Human (formerly known as WhiteOps), IAS, and MOAT has become common among significant SSPs, DSPs, and third parties in the ad tech ecosystem.
Supply path optimization (SPO) refers to the process or approach whereby buyers seek to gain more control over the ad supply chain and its costs by reducing the number of intermediaries needed to purchase the same impression.
Header bidding is a programmatic technique that allows publishers to offer inventory to multiple ad exchanges simultaneously. The result is that there is no longer a single SSP or exchange that has exclusivity over one impression. Instead, an impression is represented by numerous ad calls to various SSPs, creating an overhead of ad calls for end buyers.
SPO is a direct result of the header bidding technique’s increased usage, as this new economy creates an incentive for buyers to try and determine the best path for each impression. One method to gain an effective SPO is throttling mechanisms, which have been developed to save server costs and avoid spending resources on listening to ad calls that have a low chance of resulting in actual transactions.
A bid request contains the details required to sell inventory and display ads and is a set of information (transmitted through code lines) sent by ad exchanges to advertisers. It contains inventory details about the platform, impressions, and keys to user data (IP, pixels, tags, cookies, etc.). Through a bid request, advertisers place their bids for inventory and ultimately, their ads.
Bid requests are used for real-time bidding, exchange bidding, and header bidding.
Header bidding is an advanced programmatic technique that allows publishers to send bid requests simultaneously to multiple exchanges in real-time. The bids are passed through various targets, with the highest bid winning the ad inventory, potentially increasing the publisher’s overall yield.
Buyers bidding via multiple exchanges began to see an increase in the number of ad requests they had to handle. The related overhead costs were not always justified, as the traffic sent by exchange A and exchange B were the same.
This led to Supply Path Optimization (SPO) on the buyers’ side, to figure out the best path to each impression and respond to as few ad requests as possible, saving costs while getting the best reach for each client.
Queries per Second (QPS) refers to the number of times a request is sent to a server per second. The transition to header bidding caused DSPs to receive the same impression from multiple SSPs, resulting in higher costs for the same traffic and ad spend.
To make the traffic more attractive to buyers, sellers developed smart throttling technologies to help them send demand partners traffic with a good chance of being sold and reduce QPS while not harming revenue.
The act of preventing a bid from competing in an auction is referred to as bid throttling. Header bidding increased the publisher’s revenue but led to duplicating inventory to multiple ad requests for many buyers, causing a massive increase in the number of queries sent to advertisers (QPS). Most DSPs found they do not need to listen to tens of billions of bids to reach their clients’ goals. To reduce the load on their infrastructure, DSPs started screening bids to balance the exponential growth with the reach and quality of traffic. SSPs understood that DSPs were throttling their ad calls, so many of them took proactive steps. They developed technology that sends only relevant ad opportunities to each specific DSP, making their traffic more attractive to buyers.
Never miss out on new industry highlightsStay updated on the latest news about transparency and supply chain * By filling out this form, you agree to join Sellers.guide's mailing list, which you can unsubscribe from at any time.We will never spam you.
Frequently Asked Questions
Answers to the questions that members of the publishing community often ask us
Reducing unnecessary lines is likely to improve page speed and latency, especially when those lines are non-entities and serve no purpose at all. Removing lines of hidden/unauthorized sellers will likely improve performance on your direct accounts and may increase overall revenue.
Today's average score is 4.5, but it is not considered a good score, so there is plenty of room for improvement. A good score will run between 7 to 8.5.
No, it is more likely to have the opposite effect. Unauthorized sellers can expose your inventory to fraud, CPMs devalued by your inventory being spread thinly by cheap sellers who siphon off your revenues. In the long term, having a clean and transparent ads.txt file gives you control over who is selling your inventory and who is paying for it.
Some publishers don't sell ad inventory. To avoid an error and declare that to ads.txt crawlers they need to include one properly formatted line and can use the placeholder: placeholder.example.com, placeholder, DIRECT, placeholder. The domain "example.com" is not significant and is an alternative to a real advertising domain. For more information visit IAB. Tech Lab ads.txt Specification.
Ads.txt aims to combat malpractices in the supply chain by providing transparency about authorized Sellers to prevent unauthorized inventory reselling. Publishers should update their ads.txt regularly to ensure that they are represented only by authorized Sellers and Resellers and do not miss out on potential revenue.
Many Buyers will automatically not bid on traffic from domains that do not have ads.txt files. Therefore, we highly recommend that all Publishers monitor their ads.txt file carefully as part of their ongoing domain maintenance.
When you sell inventory via a new Vendor, we recommend adding the ads.txt file at the same time. This ensures that all Buyers can access the traffic and the supply chain works appropriately. Also, many Buyers will not buy traffic that is not verified by ads.txt files.
When you stop working with a Vendor, you should also remove the Vendor lines from the ads.txt file to ensure they can no longer access your inventory or resell it without your knowledge.
We also recommend that you periodically monitor your ads.txt file to verify it is up to date. Make sure that all active Vendors are listed in the file and all obsolete Vendors are removed.
Reducing unnecessary lines is likely to improve page speed and latency, especially when those lines are non-entities and serve no purpose at all. Removing lines of hidden/unauthorized sellers will likely improve performance on your direct accounts and may increase overall revenue.
No, it is more likely to have the opposite effect. Unauthorized sellers can expose your inventory to fraud, CPMs devalued by your inventory being spread thinly by cheap sellers who siphon off your revenues. In the long term, having a clean and transparent ads.txt file gives you control over who is selling your inventory and who is paying for it.
Some publishers don't sell ad inventory. To avoid an error and declare that to ads.txt crawlers they need to include one properly formatted line and can use the placeholder: placeholder.example.com, placeholder, DIRECT, placeholder. The domain "example.com" is not significant and is an alternative to a real advertising domain. For more information visit IAB. Tech Lab ads.txt Specification.
Ads.txt aims to combat malpractices in the supply chain by providing transparency about authorized Sellers to prevent unauthorized inventory reselling. Publishers should update their ads.txt regularly to ensure that they are represented only by authorized Sellers and Resellers and do not miss out on potential revenue.
Many Buyers will automatically not bid on traffic from domains that do not have ads.txt files. Therefore, we highly recommend that all Publishers monitor their ads.txt file carefully as part of their ongoing domain maintenance.
When you sell inventory via a new Vendor, we recommend adding the ads.txt file at the same time. This ensures that all Buyers can access the traffic and the supply chain works appropriately. Also, many Buyers will not buy traffic that is not verified by ads.txt files.
When you stop working with a Vendor, you should also remove the Vendor lines from the ads.txt file to ensure they can no longer access your inventory or resell it without your knowledge.
We also recommend that you periodically monitor your ads.txt file to verify it is up to date. Make sure that all active Vendors are listed in the file and all obsolete Vendors are removed.
An ads.txt file helps Buyers gain insights into the authenticity of the traffic they buy and its sources. An increasing number of Buyers won't buy traffic from a source, unless it has a valid ads.txt file. As a result, not having an ads.txt file will significantly reduce ad revenue.
It is recommended that all Intermediaries who participate in selling media programmatically have an updated sellers.json file indicating their relationship with each Seller. This includes Ad-Ops, Exchanges, Third-Party Vendors, and SSPs. A well-maintained sellers.json file brings greater transparency to the supply path and allows for greater trust in the entire ecosystem. It also enhances potential revenue by increasing the number of Buyers who participate in the bid request. To read more about sellers.json, visit Sellers.guide Transparency Wiki and the Sellers.json article by IAB Tech Lab.
You should update the sellers.json file when starting a new partnership with a seller or ending a partnership by adding or removing their details from the sellers.json file. Increasingly, Buyers won't buy traffic that is not verified by a sellers.json file. Including a new Seller in the sellers.json file ensures that all Buyers can access the traffic and the supply chain works appropriately. It is also recommended that you run quarterly maintenance to verify that active Sellers are included in the file, and obsolete Sellers have been removed.
Participating in the sellers.json initiative is not mandatory, but most ad tech companies have embraced it and published their sellers.json file. As a result, a bid request that lacks a sellers.json string can seem suspicious, making it less desirable to some DSPs, who may choose not to bid on it. This can hinder a site's full monetization potential because not all major DSPs will participate in the auction.
Today's average score is 4.5, but it is not considered a good score, so there is plenty of room for improvement. A good score will run between 7 to 8.5.
Publishers use Ads.txt to disclose their list of authorized trusted Sellers (Exchanges and more) that can access their traffic. Sellers.json is a mirror image of ads.txt, where SSPs and Exchanges list their inventory sources. Cross-referencing ads.txt with sellers.json files enables Buyers to identify all Sellers and Resellers participating in a bid request, all the way to the Publisher itself. Publishers can verify every line in their ads.txt file and examine who is selling and how their traffic is being sent to Buyers. DSPs can use ads.txt and sellers.json to improve their supply-path optimization and access inventory via the most direct path available.
You can cross-reference the ads.txt Seat IDs with the Exchanges' sellers.json file to identify the Seller. An easier option is to use Sellers.guide Validate Seller tool by copy and pasting in the relevant ads.txt lines. You will then receive a report detailing the type of relationships between the Seller and the other parties.
When a Seller is listed in the sellers.json file as an INTERMEDIARY, the Seller should be listed as RESELLER in the ads.txt file. Only companies that are listed as PUBLISHER or BOTH in the sellers.json file can sell traffic directly. Intermediaries are, by definition, Resellers. Some Buyers only target DIRECT Publishers and do not buy Intermediary traffic, giving Intermediaries an incentive to list themselves as DIRECT, instead of RESELLER, in their ads.txt lines. This type of mislabeling might result in the Buyer blocking traffic because the information provided is not consistent.
When a Seller is listed in the sellers.json file as a PUBLISHER, it should be listed as DIRECT in the ads.txt file. Only companies that are listed as INTERMEDIARY or BOTH in the sellers.json file can sell and resell third-party traffic. Buyers who notice this inconsistency will not understand the traffic source or will find the mismatched information misleading, which could lead to Buyers blocking the traffic entirely.
When an ads.txt line is missing its corresponding seat ID in the sellers.json file, that means a direct partnership between the Seller listed in the ads.txt file and the Exchange does not exist. This raises the question: Why is this seat ID in the ads.txt file? This situation can occur when seats are removed from the Exchange's sellers.json file due to fraud and traffic problems. However, it can also happen when a seat is shut down because companies have terminated their partnership, which can occur for numerous legitimate reasons. In either case, the Publisher should be informed and remove the seat ID from its ads.txt file.
No implementation is required for Buyers. The goal of ads.txt and sellers.json is to strengthen the supply side and prevent fraudulent Vendors from presenting themselves as Sellers. However, the buy-side has an essential role in ensuring these new tools' succeed by verifying, reviewing, and examining both ads.txt and seller.json files regularly. As these tools have led to increased transparency on the sell-side, there have been suggestions that there should be similar tools for the buy-side. Buyers.json is a new initiative by leading industry members who aspire to bring transparency to the buy-side in the same way that prior initiatives such as sellers.json and ads.txt brought transparency to the sell-side.
