Every row on this site is a claim about a business relationship. This page describes exactly what evidence each label requires, how often the evidence is re-read, and what the method deliberately does not do.
A network's sellers.json is its own published list of the publishers it sells for; a site's ads.txt is its own published list of who may sell its inventory. A membership appears here when a network's seller file names a site — that is the network's side. The site's side is confirmed when its ads.txt names the same relationship back: the same seller account the network published, matched tolerantly of formatting (zero padding, case) but never loosely.
Managed networks complicate the file match: a network that sells through upstream exchanges appears in its members' files under the exchange's name, not its own. For those we maintain a verified seat map — an exchange account counts for a network only when the exchange's own seller file names that network (or its registered corporate parent) as the account holder. Frequency alone never qualifies a seat.
Some sites run a network but publish no ads.txt. For those, the site's homepage is the site's side of the record: serving a network's ad script — or answering through its proxy, as Ezoic sites do — is the site pointing back at the network through its own markup. Only signatures we have verified as network-owned hosts count, and a detection expires if two homepage re-crawls in a row stop seeing it.
Confirmed both ways — the network's seller file names the site, and the site points back: its ads.txt carries the network's seller account, or its homepage runs the network's script. Different account id — the site's file names the network, but under an account the network's file doesn't publish for it. Unconfirmed — only the network's side exists. No longer detected — the network still lists the site, but the site shows no trace, on a network where absence is measurable: its members carry the ads.txt line at rates above ninety per cent, so a readable file without the line — or no file at all, for networks that require one — is evidence of a stale listing, not of a gap in our reading.
Every site page prints the verbatim evidence lines beside the label, so nothing here has to be taken on trust: the seller file entry, the ads.txt line, the detected script. If the evidence isn't there, the label doesn't claim it.
Seller files are re-read nightly. Site ads.txt files are re-read on a rolling three-week cycle, and homepages on a rolling half-year cycle. A failed fetch never changes a record — only a successful read does — and departures are only recorded after repeated consecutive absences, so a network's one bad publish doesn't erase its book.
It does not infer relationships from page markup alone — a script detection can confirm a listed membership, never invent one. It does not count generic reseller seats that hundreds of unrelated files copy from templates. It does not pretend to be a person: our crawler identifies itself in every request, respects robots.txt, and a site that walls off bots stays unread rather than deceived — its records simply stay unconfirmed. And it does not editorialise: a Confirmed both ways mark on a very large portal means the network is genuinely authorised there, not that it is the portal's main monetisation.
Found a case the method gets wrong? Report it or write to [email protected] — the labels above were shaped by exactly such cases.