Brug af ads.txt og sellers.json til annonceintelligens (Praktisk guide)

ads.txt og sellers.json er to små, offentligt hostede tekstfiler, der, læst sammen, fortæller dig, hvem der er autoriseret til at sælge en udgivers annoncelager, og hvem der faktisk ejer en given sælger-ID i kæden. Til konkurrence- og forsyningskædeforskning er de en af de få virkelig faktuelle, verificerbare datakilder i en branche, hvor de fleste påstande (forbrug, rækkevidde, "premium-lager") ikke kan kontrolleres. Her er, hvordan du rent faktisk bruger dem.

Hvad hver fil indeholder i praksis#

ads.txt findes på domain.com/ads.txt på enhver udgivers root-domæne, og det er en almindelig tekstliste over alle virksomheder, der er autoriseret til at sælge den pågældende udgivers lager, en linje pr. relation. En typisk linje ser sådan ud:

google.com, pub-1234567890123456, DIRECT, f08c47fec0942fa0

Det er børsens eller SSP'ens domæne, udgiverens konto-ID hos den pågældende børs, om relationen er DIRECT (udgiveren handler direkte med dem) eller RESELLER (en mellemmand er involveret), og en valgfri certificeringsautoritets-ID. sellers.json er spejlbilledet, hostet af børsen eller SSP'en på exchange.com/sellers.json, og viser alle sælgerkonti, som den børs arbejder med, deres navn (nogle gange), og om de er en PUBLISHER, en INTERMEDIARY eller BOTH. Krydsreferer de to, og du kan bekræfte, om en bestemt annoncepladss påståede sælger faktisk har en autoriseret relation, eller om noget ikke stemmer.

Hvorfor dette er vigtigt for konkurrence- og brand-sikkerhedsforskning#

Annonceforsyningskæden mellem en annoncørs budget og en udgivers side er sjældent et enkelt hop. Annoncer flyder ofte gennem en eller flere genvurdne lagerrelationer før landing, og hvert hop er en mulighed for fejlrepræsentation, domænespoofing eller simpel forvirring om, hvem der rent faktisk kører en annonce. ads.txt og sellers.json findes specifikt for at gøre den kæde reviderbar:

• Verificering af et netværks påstand. Hvis et native netværk eller DSP påstår direkte adgang til en udgivers lager, vil den pågældende udgivers ads.txt-fil liste dem som DIRECT. Hvis de kun vises som en reseller flere hop væk, eller slet ikke vises, er det nyttig information, før du køber.
• Spotning af domænespoofing. Svigagtige operationer påstår nogle gange at repræsentere en premium-udgivers lager uden autorisation. At kontrollere ads.txt mod det faktiske budanmodningsdomæne er en standard, gratis måde at fange dette på.
• Forståelse af, hvorfor en annonce ser ud, som den gør. Når du sporer, hvordan annoncespy-værktøjer fanger native annoncer, er ads.txt/sellers.json-parringen ofte den hurtigste måde at bekræfte, hvilket netværk der faktisk leverede en given placering, i stedet for at gætte ud fra widget'ens visuelle stil alene.
• Revision af dine egne forsyningsveje. Hvis du er udgiver, er din egen ads.txt-fil også den hurtigste måde at kontrollere, om en partner, du har afbrudt (eller aldrig autoriseret), stadig er listet, eller om en integration har tilføjet linjer, du ikke forventede.

En praktisk fem-trins arbejdsgang#

1. Hent udgiverens ads.txt. Hent https://[publisher-domain]/ads.txt direkte i en browser eller med et simpelt script. Det er almindelig tekst, ingen godkendelse nødvendig.
2. Find linjen for den børs eller det netværk, du undersøger. Søg efter domænet (f.eks. taboola.com, outbrain.com eller den relevante SSP) og noter udgiverens konto-ID og om det er markeret som DIRECT eller RESELLER.
3. Hent den pågældende børs' sellers.json. Hent https://[exchange-domain]/sellers.json og søg efter det sælger-ID, du fandt i trin 2.
4. Sammenlign sælgerens navn og type. Stemmer sellers.json-posten overens med den udgiver, du startede med? Er den listet som PUBLISHER (som forventet for en direkte relation) eller INTERMEDIARY (forventet for en videresalgskæde)?
5. Følg kæden, hvis det er en RESELLER-relation. En RESELLER-linje betyder, at en anden enhed sidder mellem udgiveren og børsen. Ideelt set bør den mellemmand bære sine egne SupplyChain-objekt (schain) data i budanmodningen, som registrerer hvert hop for fuld revisionsmulighed, selvom schain-data ikke er synlige fra ads.txt/sellers.json-filerne alene; det kræver adgang til den faktiske budstrøm eller et værktøj, der fanger det.

Almindelige fund, og hvad de betyder#

Hvor dette passer ind i annoncenetværksidentifikation mere bredt#

ads.txt og sellers.json er stærkest til at verificere supply-side-relationer, ikke til at identificere, hvilket netværk der faktisk leverede en specifik annonce, du ser som køber. Til det arbejder du normalt ud fra kreativets omdirigeringskæde, widget'ens visuelle signatur og de tracking-pixel domæner, der er involveret, hvilket er den tilgang, der dækkes i hvordan man identificerer annoncenetværket bag enhver annonce. Tænk på ads.txt og sellers.json som revisionssporet for supply-relationer, og kreativ-/omdirigeringsanalyse som revisionssporet for, hvad en annoncør rent faktisk kører.

Værktøjsnoter#

Begge filformater styres af IAB Tech Lab-specifikationer, og kildespecifikationerne er den definitive reference, hvis du støder på et edge-case, som disse filer ikke dækker rent, som f.eks. multi-kontoopsætninger eller OWNERDOMAIN-felter. Til manuelle stikprøver er en browser og en tekstsøgning virkelig nok; du har ikke brug for betalt værktøj til lejlighedsvis verifikation. Hvor det bliver kedeligt, er at gøre dette i skala på tværs af snesevis af udgivere eller spore ændringer over tid, hvilket er, hvor en platform, der allerede indekserer forsyningskæden på tværs af netværk, sparer det gentagne fetch-and-diff-arbejde. OpenAdLibrary's annonceintelligens indeks parrer denne form for supply-path-kontekst med det faktiske live kreative og spores landingsside, så du ikke manuelt krydsrefererer tre separate kilder for hver placering, du vil kontrollere.

Hvorfor dette betyder mere for native end det ser ud ved første øjekast#

Native netværk videresælger lager konstant. En enkelt content recommendation widget-slot på en udgivers side kan rute gennem netværket direkte, gennem en regional videresælger eller gennem en header-bidding-wrapper, der mægler flere demand-kilder på én gang. Fordi native annoncer sjældent bærer den slags synlig branding, som en display-banner gør, og fordi widget'en ofte ser identisk ud uanset hvilket netværk der faktisk er bagved, er ads.txt og sellers.json nogle gange den eneste pålidelige måde at bekræfte, hvilket netværk der legitimt har en given udgiverrelation, især når en udgivers side kører flere native widgets side om side fra forskellige udbydere. Dette er også grunden til, at header-bidding-opsætninger, hvor flere børser konkurrerer om den samme slot i realtid, drager fordel af den samme verifikation: hver deltagende børs bør have sin egen autoriserede linje i udgiverens ads.txt og sin egen matchende sellers.json-post.

Gør dette i skala versus gør det én gang#

At kontrollere én udgivers fil manuelt tager et par minutter. At kontrollere det på tværs af en overvågningsliste med halvtreds udgivere på regelmæssig basis for at fange nye eller tabte relationer er et andet problem, og det er den slags, der stille og roligt holder op med at ske, når den indledende nysgerrighed aftager, selvom værdien kommer fra at gøre det gentagne gange. Hvis du bygger dette ind i en løbende forskningsproces i stedet for en engangskontrol, er det værd at parre det med den annonceforsyningskædeovervågning, du allerede gør for kreative og landingssideændringer, så supply-side- og creative-side-billederne opdateres sammen i stedet for at drive ud af synkronisering.

En bemærkning om begrænsninger#

Disse filer er selvdeklarerede af udgivere og børser. Intet tvinger en udgiver til at holde ads.txt opdateret, og en forældet eller ufuldstændig fil er almindelig, især på mindre sider. Behandl en manglende eller inkonsistent post som en opfordring til at undersøge nærmere, ikke som automatisk bevis på svig; mange legitime små udgivere har simpelthen ikke opdateret deres fil for nylig. Værdien af ads.txt og sellers.json er, at de gør forsyningskæden kontrollerbar overhovedet, ikke at de gør den ufejlbarlig.