Använd ads.txt & sellers.json för annonsintelligens (praktisk guide)

ads.txt och sellers.json är två små, offentligt hostade textfiler som, när de läses tillsammans, visar vem som är auktoriserad att sälja en utgivares annonsinventering och vem som faktiskt äger ett givet säljare‑ID i kedjan. För konkurrens‑ och leverantörskedjeforskning är de en av de få genuint faktabaserade, verifierbara datakällorna i en bransch där de flesta påståenden (utgifter, räckvidd, "premium‑inventering") inte kan kontrolleras. Så här använder du dem i praktiken.

Vad varje fil innehåller, i praktiken#

ads.txt finns på domain.com/ads.txt på någon utgivares rotdomän, och det är en vanlig textlista över varje företag som är auktoriserat att sälja den utgivarens inventering, en rad per relation. En typisk rad ser ut så här:

google.com, pub-1234567890123456, DIRECT, f08c47fec0942fa0

Det är utbytet eller SSP‑domänen, utgivarens kontoid för det utbytet, om relationen är DIRECT (utgivaren har ett direktavtal) eller RESELLER (en mellanhand är inblandad), samt ett valfritt certifierings‑auktoritets‑ID. sellers.json är spegelbilden, hostad av utbytet eller SSP på exchange.com/sellers.json, och listar varje säljarkonto som utbytet arbetar med, deras namn (ibland), och om de är en PUBLISHER, en INTERMEDIARY eller BOTH. Korsreferera de två så kan du bekräfta om en specifik annonsplats påstådda säljare faktiskt har en auktoriserad relation, eller om något inte stämmer.

Varför detta är viktigt för konkurrens‑ och varumärkessäkerhetsforskning#

Annonsleverantörskedjan mellan en annonsörs budget och en utgivares sida är sällan en enda hop. Annonser flödar ofta genom en eller flera återförsäljnings‑inventeringar innan de landar, och varje hop är en möjlighet för felrepresentation, domänförfalskning eller enkel förvirring kring vem som faktiskt driver annonsen. ads.txt och sellers.json finns specifikt för att göra den kedjan granskbar:

• Verifiera ett nätverks påstående. Om ett native‑nätverk eller DSP påstår direktåtkomst till en utgivares inventering, kommer den utgivarens ads.txt‑fil att lista dem som DIRECT. Om de bara visas som en reseller flera hopp bort, eller inte visas alls, är det värdefull information innan du köper.
• Upptäcka domänförfalskning. Bedrägliga aktörer kan ibland påstå att de representerar en premium‑utgivares inventering utan någon auktorisation. Att jämföra ads.txt med den faktiska bud‑förfrågningsdomänen är ett standard, gratis sätt att fånga detta.
• Förstå varför en annons ser ut som den gör. När du spårar hur annonsspionverktyg fångar native‑annonser, är ads.txt/sellers.json‑kopplingen ofta det snabbaste sättet att bekräfta vilket nätverk som faktiskt levererade en viss placering, snarare än att gissa utifrån widgetens visuella stil.
• Granska dina egna leverantörsvägar. Om du är en utgivare är din egen ads.txt‑fil också det snabbaste sättet att kontrollera om en partner du har cutt off (eller aldrig auktoriserat) fortfarande listas, eller om en integration har lagt till rader du inte förväntade dig.

Ett praktiskt femsteg‑arbetsflöde#

1. Hämta utgivarens ads.txt. Hämta https://[publisher-domain]/ads.txt direkt i en webbläsare eller med ett enkelt skript. Det är vanlig text, ingen autentisering behövs.
2. Hitta raden för det utbyte eller nätverk du undersöker. Sök efter domänen (t.ex. taboola.com, outbrain.com eller den relevanta SSP) och notera utgivarens kontoid samt om den är markerad som DIRECT eller RESELLER.
3. Hämta det utbytet sellers.json. Hämta https://[exchange-domain]/sellers.json och sök efter det säljare‑ID du hittade i steg 2.
4. Jämför säljarens namn och typ. Matchar sellers.json‑posten den utgivare du började med? Är den listad som PUBLISHER (som förväntat för en direktrelation) eller INTERMEDIARY (förväntat för en reseller‑kedja)?
5. Följ kedjan om det är en RESELLER‑relation. En RESELLER‑rad betyder att en annan enhet sitter mellan utgivaren och utbytet. Idealt bör den mellanhanden ha sitt eget SupplyChain‑objekt (schain) i bud‑förfrågan, vilket registrerar varje hop för full granskning, även om schain‑data inte syns i ads.txt/sellers.json‑filerna själva; det kräver åtkomst till den faktiska bud‑strömmen eller ett verktyg som fångar den.

Vanliga fynd och vad de betyder#

Var detta passar in i identifiering av annonsnätverk mer i allmänhet#

ads.txt och sellers.json är starkast för att verifiera leverantörssidorelationer, inte för att identifiera vilket nätverk som faktiskt levererade en specifik annons du ser som köpare. För det arbetar du vanligtvis med den kreativas omdirigeringskedja, widgetens visuella signatur och de spårnings‑pixel‑domäner som är inblandade, vilket är tillvägagångssättet som behandlas i hur du identifierar annonsnätverket bakom en annons. Tänk på ads.txt och sellers.json som revisionsspåret för leverantörsrelationer, och kreativ‑/omdirigeringsanalys som revisionsspåret för vad en annonsör faktiskt kör.

Verktygsanteckningar#

Båda filformaten styrs av IAB Tech Lab‑specifikationer, och källspecifikationerna är den definitiva referensen om du stöter på ett kantfall som dessa filer inte täcker rent, som multi‑konto‑uppsättningar eller OWNERDOMAIN‑fält. För manuella spot‑checks räcker en webbläsare och en textsökning; du behöver inte betalda verktyg för sporadisk verifiering. Det blir tidskrävande när du gör detta i skala över dussintals utgivare eller spårar förändringar över tid, vilket är där en plattform som redan indexerar leverantörskedjan över nätverk sparar det repetitiva hämta‑och‑jämför‑arbetet. OpenAdLibrarys annonsintelligens‑index parar den här typen av leverantörskedjekontext med den faktiska levande kreativen och spårad landningssida, så du inte behöver korsreferera tre separata källor manuellt för varje placering du vill kontrollera.

Varför detta är viktigare för native än det först verkar#

Native‑nätverk återförsäljer inventering konstant. En enda innehållsrekommendations‑widget på en utgivares sida kan gå via nätverket direkt, via en regional reseller, eller via en header‑bidding‑wrapper som förmedlar flera efterfråge‑källor samtidigt. Eftersom native‑annonser sällan bär den synliga varumärkesidentiteten som en display‑banner gör, och eftersom widgeten ofta ser identisk ut oavsett vilket nätverk som faktiskt ligger bakom, är ads.txt och sellers.json ibland det enda pålitliga sättet att bekräfta vilket nätverk som legitimt har en viss utgivarrelation, särskilt när en utgivares webbplats kör flera native‑widgets sida‑vid‑sida från olika leverantörer. Detta är också anledningen till att header‑bidding‑uppsättningar, där flera utbyten tävlar om samma slot i realtid, drar nytta av samma verifiering: varje deltagande utbyte bör ha sin egen auktoriserade rad i utgivarens ads.txt, och sin egen matchande sellers.json‑post.

Att göra detta i skala kontra en engångsgång#

Att manuellt kontrollera en utgivares fil tar ett par minuter. Att göra det över en bevakningslista på femtio utgivare, regelbundet, för att fånga nya eller borttagna relationer, är ett annat problem, och det är den typ av sak som tyst slutar ske när den initiala nyfikenheten avtar, även om värdet kommer från att göra det återkommande. Om du bygger in detta i en stående forskningsprocess snarare än en engångskontroll, är det värt att para det med den annonsleverantörskedja‑övervakning du redan gör för kreativa och landningssidans förändringar, så att leverantörssidan och den kreativa sidan uppdateras tillsammans istället för att drifta ur synk.

En notering om begränsningar#

Dessa filer är självdeklarerade av utgivare och utbyten. Ingenting tvingar en utgivare att hålla ads.txt aktuellt, och en föråldrad eller ofullständig fil är vanligt, särskilt på mindre webbplatser. Behandla en saknad eller inkonsekvent post som en signal att undersöka vidare, inte som ett automatiskt bevis på bedrägeri; många legitima små utgivare har helt enkelt inte uppdaterat sin fil på sistone. Värdet med ads.txt och sellers.json är att de gör leverantörskedjan kontrollerbar, inte att de gör den ofelbar.