Skip to main content

Compliance FAQ

Here at HUMAN, we collect a wide array of signals to power MediaGuard’s detection and prevention capabilities. A subset of these signals are what we refer to as “compliance signals”—metrics that determine whether bid requests are compliant with ads-specific media standards. These standards (ads.txt, app-ads.txt, sellers.json, and the OpenRTB SupplyChain object) are industry-wide standards created by the IAB Tech Lab and provide us with valuable information about the quality of each bid request and the advertising entities who drive them.

You can view detailed information about your own inventory’s compliance rates in the Compliance Dashboard section of the HUMAN Dashboard.

ads.txt​

What is ads.txt?​

The Authorized Digital Sellers list, also known as ads.txt, is the result of an IAB Tech Lab initiative to increase transparency in the programmatic advertising ecosystem and reduce ad fraud. Publishers use ads.txt files to specify a list of vendors who are allowed to sell their ad inventory. Since ads.txt files are publicly accessible, anyone can quickly and easily identify whether a participating publisher’s ad inventory was sold by an authorized party.

To learn more, consult the IAB Tech Lab’s About ads.txt guide.

Why does ads.txt matter?​

The IAB Tech lab has established ads.txt as an industry-wide standard for publishers. Since ads.txt provides much-needed transparency about approved sellers and makes it harder for bad actors to carry out ad fraud schemes, we believe that all publishers should have ads.txt files and all other ad tech entities should verify inventory against publishers’ ads.txt files accordingly.

What does a low “Ads.txt Adoption” rate mean?​

The Ads.txt Adoption metric checks to see whether publishers have an ads.txt file. If your Ads.txt Adoption rate is low, this means that a large percentage of your inventory comes from publishers whose websites don’t have an ads.txt file.

What does a low “Ads.txt Authorization” rate mean?​

The Ads.txt Authorization metric checks to see whether inventory is being sold by sellers who are authorized by the corresponding publishers’ ads.txt files. If your Ads.txt Authorization rate is low, this means that a large percentage of your inventory comes from sellers who aren’t listed in the corresponding publishers’ ads.txt files.

Sometimes this occurs when a publisher is okay with their ad inventory being sold through a given seller, but the publisher’s ads.txt file may be out of date or formatted incorrectly. Other times, especially if the publisher’s ads.txt file is formatted correctly, then the noncompliant seller probably wasn’t meant to be authorized in the first place—in other words, the publisher doesn't want their inventory to be sold through that seller and may not even know such a sale occurred.

Does HUMAN compile ads.txt metrics for both MediaGuard data and FraudSensor data?​

We compile ads.txt metrics in MediaGuard data (i.e., pre-bid inventory), but we do not compile ads.txt metrics for FraudSensor data (i.e., any corresponding post-bid impressions).

Does HUMAN compile ads.txt metrics for inventory in mobile app or CTV environments?​

No. Since inventory in mobile app and CTV environments is subject to app-ads.txt standards, ads.txt standards are not applicable. However, we do compile app-ads.txt metrics for mobile app and CTV inventory.

If a publisher doesn't have an ads.txt file, will their inventory affect my Ads.txt Authorization rate?​

No, inventory from publishers who lack an ads.txt file won’t affect your Ads.txt Authorization rate, only your ads.txt adoption rate. If a publisher lacks an ads.txt file, their inventory is neither classified as authorized nor as unauthorized; this inventory is omitted from Ads.txt Authorization calculations entirely.

This is because HUMAN can only identify unauthorized inventory when publishers have an ads.txt file to check against—if a publisher doesn't have an ads.txt file at all, there's no record of authorized sellers for us to reference, which means that we can't tell whether a seller was meant to be authorized or not!

app-ads.txt​

What is app-ads.txt?​

The Authorized Sellers for Apps list, also known as app-ads.txt, is the app-based equivalent of ads.txt. Publishers use app-ads.txt files to specify a list of vendors who are allowed to sell their in-app ad inventory.

Some publishers, like social media sites who offer a browser-based service as well as a dedicated mobile app, will use both ads.txt and app-ads.txt to specify which vendors are authorized to sell inventory in each environment. The list of vendors authorized to sell ad inventory on a publisher’s website may not be identical to the list of vendors authorized to sell ad inventory in that same publisher’s mobile app.

Why does app-ads.txt matter?​

Just like ads.txt, the IAB Tech lab has established app-ads.txt as an industry-wide standard; we’re simply following their lead. Since app-ads.txt provides much-needed transparency about approved sellers and makes it harder for bad actors to carry out ad fraud schemes, we believe that all app-based publishers should be implementing it and all other ad tech entities should verify their inventory against it.

What does a low “App-ads.txt Adoption” rate mean?​

The App-ads.txt Adoption metric checks to see whether publishers have an app-ads.txt file. If your App-ads.txt Adoption rate is low, this means that a large percentage of your inventory comes from publishers whose apps don’t have an app-ads.txt file (or from publishers whose app-ads.txt files aren’t properly linked from their app store pages).

What does a low “App-ads.txt Authorization” rate mean?​

The App-ads.txt Authorization metric checks to see whether inventory is being sold by sellers who are authorized by their publishers’ app-ads.txt files. If your App-ads.txt Authorization rate is low, this means that a large percentage of your sellers aren’t listed in their corresponding publishers’ app-ads.txt files.

Sometimes this occurs when a publisher is okay with their ad inventory being sold through a given seller, but the publisher’s app-ads.txt file may be out of date or formatted incorrectly. Other times, especially if the publisher’s app-ads.txt file is formatted correctly, then the noncompliant seller probably wasn’t meant to be authorized in the first place—in other words, the publisher doesn't want their inventory to be sold through that seller and may not even know such a sale occurred.

Does HUMAN check for app-ads.txt violations in both MediaGuard data and FraudSensor data?​

We check for app-ads.txt violations in MediaGuard data (i.e., pre-bid inventory), but do not check for app-ads.txt violations in FraudSensor data (i.e., any corresponding post-bid impressions).

If a publisher doesn't have an app-ads.txt file, will their inventory affect my App-ads.txt Authorization rate?​

No, inventory from publishers who lack an app-ads.txt file won’t affect your App-ads.txt Authorization rate, only your app-ads.txt adoption rate. If a publisher lacks an app-ads.txt file, their inventory is neither classified as authorized nor as unauthorized. This inventory is omitted from App-ads.txt Authorization calculations entirely.

This is because HUMAN can only identify unauthorized inventory when publishers have an app-ads.txt file to check against—if a publisher doesn't have an app-ads.txt file at all, there's no record of authorized sellers for us to reference, which means that we can't tell whether a seller was meant to be authorized or not!

Does HUMAN compile app-ads.txt metrics for inventory in desktop web or mobile web environments?​

No. Since inventory in desktop web and mobile web environments is subject to ads.txt standards, app-ads.txt standards are not applicable. However, we do compile ads.txt metrics for desktop web and mobile web inventory.

Which app-based publishers should have app-ads.txt files?​

Publishers should have app-ads.txt files for Android apps, iOS apps, and certain CTV apps (e.g., Roku).

sellers.json​

What is sellers.json?​

Much like ads.txt and app-ads.txt, sellers.json is part of the IAB Tech Lab initiative to increase transparency in the programmatic advertising ecosystem and reduce ad fraud. Unlike ads.txt and app-ads.txt files, which are created and distributed by publishers, sellers.json files are created by advertising systems who facilitate the buying and selling of ads.

Ad exchanges and supply-side platforms (SSPs) use sellers.json to list all of the publishers and intermediaries who are authorized to sell ads through their system. Since sellers.json files are publicly accessible and contain standardized information, this data can be used to determine who owns the seller account that is being used to sell ad inventory.

Why does sellers.json matter?​

Alongside ads.txt and app-ads.txt, the IAB Tech Lab has established sellers.json as an industry-wide standard for sellers as part of their goal to increase transparency in the ads ecosystem. Here at HUMAN, sellers.json files are especially valuable because we can use this information to improve our own detection models—by cross-referencing the seller names and domains in various sellers.json files, we can concretely identify the companies behind each ID and assemble a bigger picture of how inventory moves through sell-side channels.

What does a low “Sellers.json Adoption” rate mean?​

The Sellers.json Adoption metric checks to see whether sellers have entries in their respective ad systems' sellers.json files. If your Sellers.json Adoption rate is low, this means that a large percentage of your inventory comes from sellers who don’t have a sellers.json entry.

What does a low “Sellers.json Domain Presence” rate mean?​

The Sellers.json Domain Presence metric checks to see whether the ad system provided a domain for the seller in its sellers.json file, when the sellers.json file is present. If your Sellers.json Domain Presence rate is low, this means that a large percentage of your inventory with sellers.json present, being sold via sellers without domains.

SupplyChain object​

What is the SupplyChain object?​

The SupplyChain object (sometimes referred to as the schain) is part of the OpenRTB protocol that powers the programmatic advertising ecosystem. The SupplyChain object provides buyers with an overview of every seller involved in a bid request, including the first seller and any intermediaries. This overview is presented as a series of nodes where each node represents a specific seller; taken as a whole, these nodes form a "chain" that shows each bid request's path through the programmatic ecosystem.

SupplyChain objects in bid requests can be validated by pulling information from ads.txt/app-ads.txt files and sellers.json files—assuming that these files were available in the first place. This is one reason why it’s important for publishers and ad systems to comply with their respective standards!

To learn more, consult the IAB Tech Lab’s sellers.json and SupplyChain object guide.

Why does the SupplyChain object matter?​

We use the SupplyChain object to trace each bid request’s path through the advertising ecosystem. Information about the current seller alone doesn’t always provide full visibility into all of the various entities who participate in the chain of transactions for a given bid request; the added transparency of the SupplyChain object makes it easier for us to determine where inventory originates and helps us improve our detection models accordingly.

What does a low “SChain Adoption” rate mean?​

The SChain Adoption metric checks to see whether a bid request includes a SupplyChain object. If your SChain Adoption rate is low, this means that a large percentage of your inventory comes from ad systems who aren't including the SupplyChain object in their bid requests. If your adoption rate is 0%, this means that you probably aren’t including SupplyChain objects in your requests to the MediaGuard API/SDK.

What does a low “SChain Declared Completeness” rate mean?​

The SChain Declared Completeness metric checks to see whether a SupplyChain object in a bid request is declared complete, to ensure the suppliers are providing transparency into the full supply chain of the inventory they are supplying. If your SChain Declared Completeness rate is low, this means that a large percentage of your inventory, where the SupplyChain object is present in a bid request, comes from ad systems who don't declare the SupplyChain object complete in their bid requests, via “complete“ attribute of the SupplyChain object.

Where does the declaration of SupplyChain “complete” originate from?​

The entity that determines "its complete" is the ad system (SSP) that first added the SupplyChain to the bid request. When an ad system gets inventory directly from the publisher, they create a new SupplyChain and set the "complete" attribute to 1 (true), since they know it starts from the publisher.

When an ad system gets a bid request from somewhere other than the publisher (i.e. they're reselling it) they check if it has a SupplyChain. If it does, they simply append their node to the existing SupplyChain, leaving the "complete" attribute as-is. If it doesn't, they create a new SupplyChain and set the "complete" attribute to 0 (false), since the node(s) between the publisher and themselves are missing from the SupplyChain.

See the OpenRTB spec for more details on this process.