Bruk av ads.txt & sellers.json for annonseinnsikt (praktisk veiledning)

ads.txt og sellers.json er to små, offentlig tilgjengelige tekstfiler som, lest sammen, forteller deg hvem som er autorisert til å selge en utgivers annonseinventar og hvem som faktisk eier en gitt selger-ID i kjeden. For konkurranse- og forsyningskjederesearch er de en av de få genuint faktiske, verifiserbare datakildene i en bransje hvor de fleste påstander (budsjett, rekkevidde, "premium-inventar") ikke kan sjekkes. Slik bruker du dem i praksis.

Hva hver fil inneholder, i praksis#

ads.txt finnes på domain.com/ads.txt på ethvert utgivers rotdomene, og det er en ren tekstliste over hvert selskap som er autorisert til å selge den utgiverens inventar, én linje per relasjon. En typisk linje ser slik ut:

google.com, pub-1234567890123456, DIRECT, f08c47fec0942fa0

Det er børsens eller SSP-domene, utgiverens kontoid hos den børsen, om relasjonen er DIRECT (utgiveren forhandler direkte med dem) eller RESELLER (en mellommann er involvert), og en valgfri sertifiseringsmyndighets-ID. sellers.json er speilbildet, hostet av børsen eller SSP på exchange.com/sellers.json, og lister opp hver selgerkonto den børsen samarbeider med, deres navn (noen ganger), og om de er en PUBLISHER, en INTERMEDIARY, eller BOTH. Kryssreferer de to, og du kan bekrefte om en spesifikk annonseplass' påståtte selger faktisk har en autorisert relasjon, eller om noe ikke stemmer.

Hvorfor dette betyr noe for konkurranse- og merkesikkerhetsresearch#

Annonseforsyningskjeden mellom en annonsørs budsjett og en utgivers side er sjelden et enkelt hopp. Annonser flyter ofte gjennom en eller flere videreførte inventarrelasjoner før de lander, og hvert hopp er en mulighet for feilrepresentasjon, domene-forfalskning, eller enkel forvirring om hvem som egentlig kjører en annonse. ads.txt og sellers.json eksisterer spesifikt for å gjøre den kjeden gjennomsiktig:

• Verifisering av et nettverks påstand. Hvis et native nettverk eller DSP hevder direkte tilgang til en utgivers inventar, vil den utgiverens ads.txt-fil liste dem som DIRECT. Hvis de bare dukker opp som en viderefører flere hopp unna, eller ikke dukker opp i det hele tatt, er det nyttig informasjon før du kjøper.
• Oppdagelse av domene-forfalskning. Uærlige operasjoner hevder noen ganger å representere et premium-utgivers inventar uten autorisasjon. Å sjekke ads.txt mot det faktiske budforespørselsdomenet er en standard, gratis måte å fange dette på.
• Forståelse av hvorfor en annonse ser ut som den gjør. Når du sporer hvordan annonsespionverktøy fanger native annonser, er ads.txt/sellers.json-paringen ofte den raskeste måten å bekrefte hvilket nettverk som faktisk leverte en gitt plassering, i stedet for å gjette ut fra widgetens visuelle stil alene.
• Revisjon av dine egne forsyningsveier. Hvis du er en utgiver, er din egen ads.txt-fil også den raskeste måten å sjekke om en partner du avsluttet (eller aldri autoriserte) fortsatt er listet, eller om en integrasjon la til linjer du ikke forventet.

En praktisk fem-trinns arbeidsflyt#

1. Hent utgiverens ads.txt. Hent https://[publisher-domain]/ads.txt direkte i en nettleser eller med et enkelt skript. Det er ren tekst, ingen autentisering nødvendig.
2. Finn linjen for børsen eller nettverket du undersøker. Søk etter domenet (f.eks. taboola.com, outbrain.com, eller den relevante SSP-en) og noter utgiverens kontoid og om den er merket DIRECT eller RESELLER.
3. Hent den børsens sellers.json. Hent https://[exchange-domain]/sellers.json og søk etter selger-ID-en du fant i trinn 2.
4. Sammenlign selgernavnet og typen. Stemmer sellers.json-oppføringen med utgiveren du startet med? Er den listet som PUBLISHER (som forventet for en direkte relasjon) eller INTERMEDIARY (forventet for en videreførerkjede)?
5. Følg kjeden hvis det er en RESELLER-relasjon. En RESELLER-linje betyr at en annen enhet sitter mellom utgiveren og børsen. Ideelt sett bør den mellommannen bære sine egne SupplyChain-objektdata (schain) i budforespørselen, som registrerer hvert hopp for full gjennomsiktighet, selv om schain-data ikke er synlig fra ads.txt/sellers.json-filene alene; det krever tilgang til den faktiske budstrømmen eller et verktøy som fanger den.

Vanlige funn, og hva de betyr#

Hvor dette passer inn med annonsenettverksidentifikasjon mer bredt#

ads.txt og sellers.json er sterkest for å verifisere forsyningssiderelasjoner, ikke for å identifisere hvilket nettverk som faktisk leverte en spesifikk annonse du ser på som kjøper. For det jobber du vanligvis fra kreativets omdirigeringskjede, widgetens visuelle signatur, og de involverte sporingspikseldomenene, som er tilnærmingen dekket i hvordan identifisere annonsenettverket bak enhver annonse. Tenk på ads.txt og sellers.json som revisjonssporet for forsyningsrelasjoner, og kreativ-/omdirigeringsanalyse som revisjonssporet for hva en annonsør faktisk kjører.

Verktøymerknader#

Begge filformatene styres av IAB Tech Lab-spesifikasjoner, og kildespesifikasjonene er den endelige referansen hvis du treffer et grensetilfelle disse filene ikke dekker rent, som flerkontooppsett eller OWNERDOMAIN-felt. For manuelle stikkprøver er en nettleser og en tekstsøkning genuint nok; du trenger ikke betalte verktøy for tilfeldig verifisering. Der det blir kjedelig er å gjøre dette i skala på tvers av dusinvis av utgiverne eller spore endringer over tid, som er der en plattform som allerede indekserer forsyningskjeden på tvers av nettverk sparer det repetitive hente-og-diff-arbeidet. OpenAdLibrarys annonseinnsiktsindeks parer denne typen forsyningsveikontekst med den faktiske live-kreativen og sporet landingsside, slik at du ikke kryssrefererer tre separate kilder manuelt for hver plassering du vil sjekke.

Hvorfor dette betyr mer for native enn det ser ut til ved første øyekast#

Native nettverk viderefører inventar konstant. En enkelt innholdsanbefalingswidget-plass på en utgivers side kan rute gjennom nettverket direkte, gjennom en regional viderefører, eller gjennom en header-bidding-wrapper som megler flere etterspørselskilder samtidig. Fordi native annonser sjelden bærer den typen synlig merkevarebygging en displaybanner gjør, og fordi widgeten i seg selv ofte ser identisk ut uavhengig av hvilket nettverk som faktisk står bak, er ads.txt og sellers.json noen ganger den eneste pålitelige måten å bekrefte hvilket nettverk som legitimt har en gitt utgiverrelasjon, spesielt når en utgivers nettsted kjører flere native widgets side om side fra forskjellige leverandører. Dette er også grunnen til at header-bidding-oppsett, hvor flere børser konkurrerer om samme plass i sanntid, drar nytte av samme verifisering: hver deltakende børse bør ha sin egen autoriserte linje i utgiverens ads.txt, og sin egen samsvarende sellers.json-oppføring.

Å gjøre dette i skala versus å gjøre det én gang#

Å sjekke én utgivers fil for hånd tar et par minutter. Å sjekke den på tvers av en overvåkingsliste på femti utgiverne, på en tilbakevendende basis, for å fange nye eller droppede relasjoner, er et annet problem, og det er den typen ting som stille stopper å skje når den første nysgjerrigheten slites av, selv om verdien kommer fra å gjøre det gjentatte ganger. Hvis du bygger dette inn i en stående forskningsprosess i stedet for en engangssjekk, er det verdt å pare det med hvilken som helst annonseforsyningskjedemonitorering du allerede gjør for kreative og landingssideendringer, slik at forsyningssiden og kreativsiden-bildene oppdateres sammen i stedet for å drive ut av synk.

En merknad om begrensninger#

Disse filene er selvdeklarert av utgiverne og børsene. Ingenting tvinger en utgiver til å holde ads.txt oppdatert, og en utdatert eller ufullstendig fil er vanlig, spesielt på mindre nettsteder. Behandle en manglende eller inkonsistent oppføring som et signal for å undersøke videre, ikke automatisk bevis på svindel; mange legitime små utgiverne har rett og slett ikke oppdatert filen sin nylig. Verdien av ads.txt og sellers.json er at de gjør forsyningskjeden sjekkbar i det hele tatt, ikke at de gjør den ufeilbarlig.