Gebruik van ads.txt & sellers.json voor advertentie‑intelligentie (praktische gids)

ads.txt en sellers.json zijn twee kleine, publiek gehoste tekstbestanden die, samen gelezen, laten zien wie bevoegd is om de advertentie‑inventaris van een uitgever te verkopen en wie daadwerkelijk eigenaar is van een bepaalde seller‑ID in de keten. Voor competitief en supply‑chain onderzoek zijn ze een van de weinige echt feitelijke, verifieerbare gegevensbronnen in een industrie waar de meeste claims (uitgaven, bereik, "premium inventory") niet kunnen worden gecontroleerd. Hier lees je hoe je ze daadwerkelijk gebruikt.

Wat elk bestand bevat, in de praktijk#

ads.txt staat op domain.com/ads.txt op de root van elk uitgeversdomein, en het is een platte‑tekstlijst van elk bedrijf dat bevoegd is om die uitgeversinventaris te verkopen, één regel per relatie. Een typische regel ziet er als volgt uit:

google.com, pub-1234567890123456, DIRECT, f08c47fec0942fa0

Dat is het exchange‑ of SSP‑domein, de account‑ID van de uitgever bij die exchange, of de relatie DIRECT (de uitgever werkt rechtstreeks met hen) of RESELLER (een tussenpersoon is betrokken), en een optioneel certificerings‑authority‑ID. sellers.json is de spiegelbeeld, gehost door de exchange of SSP op exchange.com/sellers.json, waarin elke verkopersaccount wordt opgesomd waarmee die exchange werkt, hun naam (soms), en of ze een PUBLISHER, een INTERMEDIARY of BOTH zijn. Door de twee te kruisen kun je bevestigen of een specifieke ad‑slot‑geclaimde verkoper daadwerkelijk een geautoriseerde relatie heeft, of dat er iets niet klopt.

Waarom dit belangrijk is voor competitief en merk‑veiligheids­onderzoek#

De ad supply chain tussen het advertentiebudget van een adverteerder en de pagina van een uitgever is zelden één enkele hop. Advertenties stromen vaak via één of meer resold inventory relaties voordat ze landen, en elke hop is een kans voor misrepresentatie, domein‑spoofing of eenvoudige verwarring over wie de advertentie werkelijk runt. ads.txt en sellers.json bestaan specifiek om die keten controleerbaar te maken:

• Een netwerkclaim verifiëren. Als een native‑netwerk of DSP claimt directe toegang tot de inventaris van een uitgever, zal het ads.txt‑bestand van die uitgever hen als DIRECT vermelden. Als ze alleen als reseller enkele hops verwijderd verschijnen, of helemaal niet, is dat nuttige informatie voordat je koopt.
• Domein‑spoofing opsporen. Frauduleuze operaties claimen soms een premium uitgeversinventaris te vertegenwoordigen zonder enige autorisatie. Het vergelijken van ads.txt met het daadwerkelijke biedverzoek‑domein is een standaard, gratis manier om dit te detecteren.
• Begrijpen waarom een advertentie er zo uitziet. Wanneer je hoe ad‑spy‑tools native ads vastleggen traceert, is de ads.txt/sellers.json‑koppeling vaak de snelste manier om te bevestigen welk netwerk een bepaalde plaatsing heeft geleverd, in plaats van te gokken op basis van de visuele stijl van de widget.
• Je eigen supply‑paden auditen. Als je een uitgever bent, is je eigen ads.txt‑bestand ook de snelste manier om te controleren of een partner die je hebt afgesneden (of nooit geautoriseerd) nog steeds wordt vermeld, of dat een integratie regels heeft toegevoegd die je niet verwachtte.

Een praktische vijf‑stappen workflow#

1. Haal het ads.txt‑bestand van de uitgever op. Haal https://[publisher-domain]/ads.txt direct op in een browser of met een simpel script. Het is platte tekst, geen authenticatie nodig.
2. Zoek de regel voor de exchange of het netwerk dat je onderzoekt. Zoek naar het domein (bijv. taboola.com, outbrain.com of de relevante SSP) en noteer de uitgeversaccount‑ID en of deze gemarkeerd is als DIRECT of RESELLER.
3. Haal het sellers.json‑bestand van die exchange op. Haal https://[exchange-domain]/sellers.json op en zoek naar de seller‑ID die je in stap 2 vond.
4. Vergelijk de verkopersnaam en het type. Komt de sellers.json‑vermelding overeen met de uitgever waarmee je begon? Is het gemarkeerd als PUBLISHER (zoals verwacht voor een directe relatie) of INTERMEDIARY (verwacht voor een reseller‑keten)?
5. Volg de keten als het een RESELLER‑relatie betreft. Een RESELLER‑regel betekent dat er een andere entiteit tussen de uitgever en de exchange zit. Idealiter zou die tussenpersoon zijn eigen SupplyChain‑object (schain) data in het biedverzoek moeten dragen, die elke hop registreert voor volledige auditbaarheid, hoewel schain‑data niet zichtbaar is vanuit de ads.txt/sellers.json‑bestanden alleen; het vereist toegang tot de daadwerkelijke biedstroom of een tool die die vangt.

Veelvoorkomende bevindingen en wat ze betekenen#

Waar dit past bij bredere ad network identificatie#

ads.txt en sellers.json zijn het sterkst voor het verifiëren van supply‑side relaties, niet voor het identificeren van welk netwerk een specifieke advertentie heeft geleverd die je als koper ziet. Hiervoor werk je meestal vanuit de creatieve redirect chain, de visuele handtekening van de widget, en de tracking pixel‑domeinen die betrokken zijn, wat de aanpak is die wordt behandeld in hoe je het advertentienetwerk achter elke advertentie identificeert. Beschouw ads.txt en sellers.json als het audit‑pad voor supply‑relaties, en creatieve/redirect‑analyse als het audit‑pad voor wat een adverteerder daadwerkelijk runt.

Opmerkingen over tooling#

Beide bestandsformaten worden beheerd door IAB Tech Lab‑specificaties, en de bron‑specificaties zijn de definitieve referentie als je een randgeval tegenkomt dat deze bestanden niet netjes afdekken, zoals multi‑account‑opzetten of OWNERDOMAIN‑velden. Voor handmatige spot‑checks is een browser en een tekst‑zoekopdracht ruimschoots voldoende; je hebt geen betaald gereedschap nodig voor incidentele verificatie. Het wordt echter tijdrovend op schaal over tientallen uitgevers of bij het volgen van veranderingen in de loop van de tijd, en daar komt een platform dat al de supply‑chain over netwerken indexeert van pas om het repetitieve fetch‑and‑diff‑werk te besparen. OpenAdLibrary's ad intelligence‑index koppelt dit soort supply‑path‑context aan de daadwerkelijke live creatieve en getraceerde landingspagina, zodat je niet handmatig drie afzonderlijke bronnen hoeft te kruisen voor elke plaatsing die je wilt controleren.

Waarom dit belangrijker is voor native dan het op het eerste gezicht lijkt#

Native netwerken verkopen continu inventaris door. Een enkele content‑recommendatie‑widget op een uitgeverspagina kan via het netwerk direct, via een regionale reseller, of via een header‑bidding wrapper die meerdere vraag‑bronnen tegelijk bemiddelt, verlopen. Omdat native ads zelden de zichtbare branding van een display‑banner dragen, en omdat de widget er vaak identiek uitziet ongeacht welk netwerk erachter zit, zijn ads.txt en sellers.json soms de enige betrouwbare manier om te bevestigen welk netwerk legitiem een bepaalde uitgeversrelatie bezit, vooral wanneer een uitgeverssite meerdere native widgets naast elkaar van verschillende providers draait. Dit is ook de reden waarom header‑bidding‑opstellingen, waarbij verschillende exchanges in realtime strijden om dezelfde slot, profiteren van dezelfde verificatie: elke deelnemende exchange moet zijn eigen geautoriseerde regel in het ads.txt‑bestand van de uitgever hebben, en zijn eigen bijpassende sellers.json‑vermelding.

Dit op schaal doen versus één keer#

Het handmatig controleren van één uitgeversbestand kost een paar minuten. Het controleren van een watchlist van vijftig uitgevers op regelmatige basis om nieuwe of verdwenen relaties te detecteren, is een ander probleem, en het is het soort taak dat stilletjes stopt zodra de initiële nieuwsgierigheid afneemt, hoewel de waarde juist ligt in herhaaldelijke uitvoering. Als je dit opneemt in een doorlopend onderzoeksproces in plaats van een eenmalige controle, is het de moeite waard om het te koppelen aan de ad supply chain‑monitoring die je al doet voor creatieve en landingspagina‑veranderingen, zodat de supply‑side en creative‑side beelden gelijktijdig updaten in plaats van uit elkaar te drijven.

Een noot over limieten#

Deze bestanden worden zelf‑gedefinieerd door uitgevers en exchanges. Niets dwingt een uitgever om ads.txt actueel te houden, en een verouderd of onvolledig bestand is gebruikelijk, vooral bij kleinere sites. Beschouw een ontbrekende of inconsistente vermelding als een aanleiding om verder te onderzoeken, niet als automatisch bewijs van fraude; veel legitieme kleine uitgevers hebben hun bestand recentelijk simpelweg niet bijgewerkt. De waarde van ads.txt en sellers.json is dat ze de supply‑chain controleerbaar maken, niet dat ze onfeilbaar zijn.