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.
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.
Many Publishers forget to remove ads.txt lines from companies they no longer do business with. These lines are referred to as dormant ads.txt lines. As the ads.txt file grows, there is a higher risk that former partners of Publishers who maintain access to the inventory will resell it without permission.
Numerous Vendors might send a Publisher the same ads.txt line(s), resulting in duplications in the ads.txt file. The duplication may expose the Publisher to risk. As in most cases, at least one of the Vendors is not representing the "duplicated Seller" directly but via a third party, allowing unauthorized reselling of the inventory.
Duplicated ads.txt lines can often occur due to an honest mistake of "copy-paste." In either case, remove unnecessary lines, as it signals a poorly maintained ads.txt file.
A very large ads.txt file is likely to contain dormant lines. These lines can expose the Publisher to multiple risks, such as: 1. Sellers can access Publisher's inventory without their knowledge. 2. Sellers can spoof the Publisher's domains and sell them "as if" they are the domain owner, increasing supply and harming the Publisher's demand.
The DIRECT and RESELLER lines in an ads.txt file inform Buyers of the relationship type between the domain owner and the Vendor/Seller. This helps Buyers find the shortest path possible to the media. Having two Vendors who legitimately represent the same Seller directly is extremely rare. If a Seller is listed more than once as DIRECT in the ads.txt file, we recommend investigating further and resolving the issue immediately to avoid confusing or misleading Buyers. If the same Seller does, in fact, represent the domain owner under different names (is listed as DIRECT more than once), we recommend the domain owner contacts their partners to ensure that they use the same name to avoid confusing or misleading Buyers.
Yes, in some cases, an SSP or Exchange may prefer to have multiple seats for the same Publisher. For example, they could have: 1. A seat used for Prebid and another seat for Open Bidding. 2. A seat for display and another seat for video. 3. A seat per placement. As long as the Seller's name associated with those seats is identical, the setup is legitimate.
A Vendor that has been authorized by the Publisher to sell its inventory on its behalf (e.g. Ad network or Exchange), should be listed as RESELLER in the ads.txt file of the Publisher.
It is very common for a Publisher to authorize a Vendor to resell its traffic to Third-Party Exchanges and SSPs. The IAB allows ads.txt lines to be listed as RESELLERs for this purpose. It may only be a problem if the aforementioned Vendor asks the Publisher to list additional Vendors as RESELLERS on its behalf. This can expose the Publisher's traffic to unwanted reselling, domain spoofing, arbitrage, and other malpractice by companies the Publisher doesn't know or do business with. The sellers.json file associated with the RESELLER's ads.txt lines should all represent the same Vendor.
Some of the domains have ads.txt files that are unreadable to our crawler. This could happen for several reasons, e.g., bots blockage, HTML redirect, geo blockage. A quick and easy bypass is to copy and paste all (yes ALL, even if it's thousands of lines long) of your ads.txt lines in the "Validate Ads.txt" section also on the Sellers.guide homepage. You will get the same analysis but without the score.
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.
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.
Ads.txt 1.1 is the latest version of ads.txt from the IAB Tech Lab. During real-time bidding, ads.txt 1.1 update provides another way to prevent fraud where ad inventory is offered to buyers with a misrepresented label and account. "OwnerDomain" and "ManagerDomain" are two values that will help buyers find the shortest path to inventory.
These values focus on instances where ad inventory is being offered to buyers with misrepresented labels or accounts during the real-time bidding process. Typically, the domain of the webpage or the app ID has been falsified to appear as a site or app that does not have permission to sell. "ManagerDomain" and "OwnerDomain" are values that indicate the shortest path to the inventory and prevent possible fraud.
When the owner of the site does not manage monetization, either globally or in a specific region, there can be more than one ManagerDomain value, but there can only be one per country.While the supply path contains multiple hops, it is still the most direct route for purchasing inventory from a supply path optimization (SPO) perspective.MANAGERDOMAIN = saleshouseDE.com, DE
According to the IAB Tech Lab specification, the ManagerDomain is a vendor that manages the majority of the inventory (at least 80%). Publishers should ask themselves: 1. Do I use a third-party company that manages the majority of my inventory? 2. Do I have my own seats that I am monetizing directly? If the answer to the first question is yes and the last question is no then the vendor in question can be listed as a ManagerDomain.
In order to be compliant to ads.txt 1.1, the OwnerDomain field is mandatory. On the other hand, the ManagerDomain value is dependent on if the site has a third-party vendor that manages the majority of its inventory.
In order for the supply chain to be as accurate and complete as it can be, ads.txt 1.1 values should match the "domain" value in the respective sellers.json file.
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.
Many Publishers forget to remove ads.txt lines from companies they no longer do business with. These lines are referred to as dormant ads.txt lines. As the ads.txt file grows, there is a higher risk that former partners of Publishers who maintain access to the inventory will resell it without permission.
Numerous Vendors might send a Publisher the same ads.txt line(s), resulting in duplications in the ads.txt file. The duplication may expose the Publisher to risk. As in most cases, at least one of the Vendors is not representing the "duplicated Seller" directly but via a third party, allowing unauthorized reselling of the inventory.
Duplicated ads.txt lines can often occur due to an honest mistake of "copy-paste." In either case, remove unnecessary lines, as it signals a poorly maintained ads.txt file.
A very large ads.txt file is likely to contain dormant lines. These lines can expose the Publisher to multiple risks, such as: 1. Sellers can access Publisher's inventory without their knowledge. 2. Sellers can spoof the Publisher's domains and sell them "as if" they are the domain owner, increasing supply and harming the Publisher's demand.
The DIRECT and RESELLER lines in an ads.txt file inform Buyers of the relationship type between the domain owner and the Vendor/Seller. This helps Buyers find the shortest path possible to the media. Having two Vendors who legitimately represent the same Seller directly is extremely rare. If a Seller is listed more than once as DIRECT in the ads.txt file, we recommend investigating further and resolving the issue immediately to avoid confusing or misleading Buyers. If the same Seller does, in fact, represent the domain owner under different names (is listed as DIRECT more than once), we recommend the domain owner contacts their partners to ensure that they use the same name to avoid confusing or misleading Buyers.
Yes, in some cases, an SSP or Exchange may prefer to have multiple seats for the same Publisher. For example, they could have: 1. A seat used for Prebid and another seat for Open Bidding. 2. A seat for display and another seat for video. 3. A seat per placement. As long as the Seller's name associated with those seats is identical, the setup is legitimate.
A Vendor that has been authorized by the Publisher to sell its inventory on its behalf (e.g. Ad network or Exchange), should be listed as RESELLER in the ads.txt file of the Publisher.
It is very common for a Publisher to authorize a Vendor to resell its traffic to Third-Party Exchanges and SSPs. The IAB allows ads.txt lines to be listed as RESELLERs for this purpose. It may only be a problem if the aforementioned Vendor asks the Publisher to list additional Vendors as RESELLERS on its behalf. This can expose the Publisher's traffic to unwanted reselling, domain spoofing, arbitrage, and other malpractice by companies the Publisher doesn't know or do business with. The sellers.json file associated with the RESELLER's ads.txt lines should all represent the same Vendor.
Some of the domains have ads.txt files that are unreadable to our crawler. This could happen for several reasons, e.g., bots blockage, HTML redirect, geo blockage. A quick and easy bypass is to copy and paste all (yes ALL, even if it's thousands of lines long) of your ads.txt lines in the "Validate Ads.txt" section also on the Sellers.guide homepage. You will get the same analysis but without the score.
Ads.txt 1.1 is the latest version of ads.txt from the IAB Tech Lab. During real-time bidding, ads.txt 1.1 update provides another way to prevent fraud where ad inventory is offered to buyers with a misrepresented label and account. "OwnerDomain" and "ManagerDomain" are two values that will help buyers find the shortest path to inventory.
These values focus on instances where ad inventory is being offered to buyers with misrepresented labels or accounts during the real-time bidding process. Typically, the domain of the webpage or the app ID has been falsified to appear as a site or app that does not have permission to sell. "ManagerDomain" and "OwnerDomain" are values that indicate the shortest path to the inventory and prevent possible fraud.
When the owner of the site does not manage monetization, either globally or in a specific region, there can be more than one ManagerDomain value, but there can only be one per country.While the supply path contains multiple hops, it is still the most direct route for purchasing inventory from a supply path optimization (SPO) perspective.MANAGERDOMAIN = saleshouseDE.com, DE
According to the IAB Tech Lab specification, the ManagerDomain is a vendor that manages the majority of the inventory (at least 80%). Publishers should ask themselves: 1. Do I use a third-party company that manages the majority of my inventory? 2. Do I have my own seats that I am monetizing directly? If the answer to the first question is yes and the last question is no then the vendor in question can be listed as a ManagerDomain.
In order to be compliant to ads.txt 1.1, the OwnerDomain field is mandatory. On the other hand, the ManagerDomain value is dependent on if the site has a third-party vendor that manages the majority of its inventory.
In order for the supply chain to be as accurate and complete as it can be, ads.txt 1.1 values should match the "domain" value in the respective sellers.json file.
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.
