Az ads.txt és sellers.json használata hirdetési felderítéshez (Gyakorlati útmutató)

Az ads.txt és a sellers.json két kis, nyilvánosan elérhető szövegfájl, amelyek együtt olvasva elárulják, ki jogosult egy kiadó hirdetési leltárának értékesítésére és ki tulajdonosa egy adott eladói azonosítónak a láncban. Verseny- és ellátási lánc kutatás szempontjából ők az egyik kevés valóban tényalapú, ellenőrizhető adatforrás egy olyan iparágban, ahol a legtöbb állítás (költségvetés, elérés, "prémium leltár") nem ellenőrizhető. Íme, hogyan kell őket ténylegesen használni.

Mit tartalmaz gyakorlatban minden fájl#

Az ads.txt a domain.com/ads.txt útvonalon található bármely kiadó gyökérdomainjén, és ez egy egyszerű szöveges lista minden olyan cégről, amely jogosult a kiadó leltárának értékesítésére, egy sor kapcsolatonként. Egy tipikus sor így néz ki:

google.com, pub-1234567890123456, DIRECT, f08c47fec0942fa0

Ez a tőzsde vagy SSP domainje, a kiadó fiókazonosítója az adott tőzsdénél, hogy a kapcsolat DIRECT (a kiadó közvetlenül velük áll kapcsolatban) vagy RESELLER (közvetítő érintett), és egy opcionális tanúsító hatósági azonosító. A sellers.json a tükörképe, amelyet a tőzsde vagy SSP tesz közzé az exchange.com/sellers.json útvonalon, felsorolva minden olyan eladói fiókot, amellyel a tőzsde dolgozik, a nevüket (néha), és hogy ők PUBLISHER, INTERMEDIARY vagy BOTH. Hasonlítsd össze a kettőt, és megerősítheted, hogy egy adott hirdetési hely állítólagos eladójának valóban van-e engedélyezett kapcsolata, vagy valami nem stimmel.

Miért fontos ez verseny- és márkabiztonsági kutatás szempontjából#

A hirdetési ellátási lánc a hirdető költségvetése és a kiadó oldala között ritkán egyetlen ugrás. A hirdetések gyakran egy vagy több továbbértékesített leltár kapcsolaton keresztül haladnak, mielőtt megjelennek, és minden ugrás lehetőséget ad a félremagyarázásra, domain hamisításra vagy egyszerűen a félreértésre, hogy ki valójában futtat egy hirdetést. Az ads.txt és sellers.json kifejezetten azért létezik, hogy ezt a láncot auditálhatóvá tegye:

• Egy hálózat állításának ellenőrzése. Ha egy natív hálózat vagy DSP közvetlen hozzáférést állít egy kiadó leltárához, akkor az a kiadó ads.txt fájlja DIRECT-ként fogja felsorolni őket. Ha csak több ugrással eltávolodva jelennek meg mint továbbértékesítő, vagy egyáltalán nem jelennek meg, az hasznos információ a vásárlás előtt.
• Domain hamisítás felismerése. A csaló műveletek néha állítják, hogy prémium kiadó leltárát képviselik engedély nélkül. Az ads.txt ellenőrzése a tényleges ajánlatkérési domain ellen egy szabványos, ingyenes módja ennek elkapására.
• Megértés, hogy egy hirdetés miért néz ki úgy, ahogy. Amikor követed, hogyan rögzítik a hirdetés-kém eszközök a natív hirdetéseket, az ads.txt/sellers.json párosítás gyakran a leggyorsabb módja annak megerősítésére, hogy melyik hálózat szolgáltatta ki egy adott elhelyezést, ahelyett, hogy csak a widget vizuális stílusából találgatnál.
• Saját ellátási útvonalaid auditálása. Ha kiadó vagy, a saját ads.txt fájloddal is a leggyorsabb módja annak ellenőrzésére, hogy egy partner, akit megszüntettél (vagy soha nem engedélyeztél), még mindig felsorolva van-e, vagy egy integráció hozzáadott-e olyan sorokat, amiket nem vártál.

Egy gyakorlati ötlépéses munkafolyamat#

1. Lekérdezed a kiadó ads.txt fájlját. Kérdezd le a https://[publisher-domain]/ads.txt címet közvetlenül egy böngészőben vagy egy egyszerű szkripttel. Egyszerű szöveg, nincs hitelesítés szükséges.
2. Megkeresed a vizsgált tőzsde vagy hálózat sorát. Keresd a domainet (pl. taboola.com, outbrain.com vagy a releváns SSP) és vedd fel a kiadó fiókazonosítóját és hogy DIRECT vagy RESELLER jelöléssel szerepel-e.
3. Lekérdezed annak a tőzsdének a sellers.json fájlját. Kérdezd le a https://[exchange-domain]/sellers.json címet és keresd meg a 2. lépésben talált eladói azonosítót.
4. Összehasonlítod az eladó nevét és típusát. A sellers.json bejegyzés megegyezik azzal a kiadóval, amivel kezdtél? PUBLISHER-ként van felsorolva (ahogy egy közvetlen kapcsolatnál várható) vagy INTERMEDIARY-ként (ahogy egy továbbértékesítő láncnál várható)?
5. Követed a láncot, ha RESELLER kapcsolat. Egy RESELLER sor azt jelenti, hogy egy másik entitás áll a kiadó és a tőzsde között. Ideális esetben ennek a közvetítőnek saját SupplyChain objektummal (schain) kell rendelkeznie az ajánlatkérési adatokban, amely rögzíti minden ugrást a teljes auditálhatóság érdekében, bár a schain adatok nem láthatók az ads.txt/sellers.json fájlokból egyedül; ehhez hozzáférés szükséges a tényleges ajánlatkérési adatfolyamhoz vagy egy olyan eszközhöz, amely rögzíti azt.

Gyakori megállapítások és jelentésük#

Hogyan illeszkedik ez a hirdetési hálózat azonosításához tágabb értelemben#

Az ads.txt és sellers.json a legerősebbek az ellátási oldali kapcsolatok ellenőrzésében, nem abban, hogy melyik hálózat szolgáltatta ki egy adott hirdetést, amit hirdetőként nézel. Ehhez általában a kreatív átirányítási láncából, a widget vizuális aláírásából és az érintett követési pixel domainjeiből dolgozol, ami a hogyan azonosítsd a hirdetési hálózatot bármely hirdetés mögött cikkben ismertetett megközelítés. Gondolj az ads.txt-re és sellers.json-re mint az ellátási kapcsolatok audit nyomára, és a kreatív/átirányítás elemzésre mint arra, amit egy hirdető ténylegesen futtat.

Eszközökre vonatkozó megjegyzések#

Mindkét fájlformátumot az IAB Tech Lab specifikációi szabályozzák, és a forrásspecifikációk a döntő referencia, ha olyan szélsőséges esettel találkozol, amit ezek a fájlok nem fednek le tisztán, mint a többfiókos beállítások vagy OWNERDOMAIN mezők. Kézi helyszíni ellenőrzésekhez egy böngésző és egy szöveges keresés valóban elég; nem kell fizetett eszköz alkalmi ellenőrzéshez. Amikor unalmassá válik, az a nagy léptékű alkalmazás, amikor ezt tucatnyi kiadón át kell elvégezni, vagy változásokat kell követni időben, és itt spórol meg egy platform a monoton lekérdezési és összehasonlítási munkával, amely már indexeli az ellátási láncot hálózatok között. Az OpenAdLibrary hirdetési felderítő indexe párosítja az ilyen ellátási útvonal kontextust a tényleges élő kreatívval és követett céloldallal, így nem kell három külön forrást kézzel keresgélned minden egyes ellenőrizni kívánt elhelyezésnél.

Miért fontosabb ez a natív hirdetéseknél, mint elsőre tűnik#

A natív hálózatok folyamatosan továbbértékesítenek leltárt. Egyetlen tartalomajánló widget hely egy kiadó oldalán közvetlenül a hálózaton keresztül, egy regionális továbbértékesítőn keresztül vagy egy header-bidding burkolón keresztül irányulhat, amely egyszerre több keresleti forrást közvetít. Mivel a natív hirdetések ritkán hordozzák a látható márkajelzést, mint egy display banner, és mert maga a widget gyakran ugyanúgy néz ki, függetlenül attól, hogy melyik hálózat áll mögötte, az ads.txt és sellers.json néha az egyetlen megbízható módja annak megerősítésére, hogy melyik hálózat birtokolja legitim módon egy adott kiadói kapcsolatot, különösen amikor egy kiadó oldala több, különböző szolgáltatótól származó natív widgetet futtat egymás mellett. Ezért is részesülnek előnyben a header-bidding beállítások, ahol több tőzsde verseng ugyanazért a helyért valós időben, ugyanazzal az ellenőrzéssel: minden résztvevő tőzsdének saját engedélyezett sorral kell rendelkeznie a kiadó ads.txt fájljában, és saját megfelelő sellers.json bejegyzéssel.

Nagy léptékben végezni versus egyszer elvégezni#

Egy kiadó fájljának kézi ellenőrzése néhány percet vesz igénybe. Ötven kiadó figyelőlistáján át ellenőrizni, ismétlődő alapon, hogy elkapd az új vagy megszűnt kapcsolatokat, egy másik probléma, és ez az a fajta dolog, amely csendben megszűnik, amint az első kíváncsiság elmúlik, annak ellenére, hogy az érték az ismétlésből származik. Ha ezt egy állandó kutatási folyamatba építed be, nem pedig egy alkalmi ellenőrzésbe, érdemes párosítani bármilyen meglévő hirdetési ellátási lánc monitorozással, amit a kreatív és céloldal változásokra már végzel, hogy az ellátási oldali és kreatív oldali kép együtt frissüljön, ahelyett, hogy szinkronból kicsúszna.

Megjegyzés a korlátokról#

Ezek a fájlok a kiadók és tőzsdék önkéntes nyilatkoztatásai. Semmi sem kényszeríti egy kiadót, hogy naprakészen tartsa az ads.txt-t, és egy elavult vagy hiányos fájl gyakori, különösen kisebb oldalakon. Kezeld a hiányzó vagy inkonzisztens bejegyzést további vizsgálat indíttatásaként, nem automatikus csalásbizonyítékként; sok legitim kis kiadó egyszerűen nem frissítette a fájlját mostanában. Az ads.txt és sellers.json értéke az, hogy egyáltalán ellenőrizhetővé teszik az ellátási láncot, nem az, hogy tévedhetetlenné tennék.