Az IAB ads.txt ajánlásáról

2018. január 3.

Bizonyára sokan emlékeznek még a tavaly tavasszal történt Youtube bojkottra, ami – több egyéb brand safety fiaskóval együtt – felrázta a médiapiac vásárlói és kínálati oldalát, és központi témává tette a hirdetési környezetre való odafigyelést. A hirtelen kialakult, és a hirdetési csalásoknak köszönhetően csak egyre zavarosabbá váló piaci helyzetben az IAB is állásfoglalást tett, méghozzá egy új piaci standard ajánlásában, ami az ads.txt file implementálását jelenti.

Miért szükséges foglalkozni az ads.txt-el, és miért elengedhetetlen az implementálása?

Az egyik legfontosabb szempont egy – az ads.txt-hez hasonló –, brand safety típusú piaci sztenderd kialakításában, a hirdetési csalások visszaszorítása. Nemrég számoltunk be Facebook oldalunkon szakmai és technológiai partnerünk, az Adform sikeréről, akik az eddigi egyik legnagyobb, Hyphbot névre keresztelt, ún. botnet hálózatot derítették fel. Az eljárást, amellyel a hálózat működött, domain spoofing-nak nevezik, és meglehetősen kiterjedt online irodalommal rendelkezik (egy rövid, a lényegre szorítkozó leírás itt olvasható a jelenségről).

Röviden összefoglalva, a domain spoofing lényege, hogy az ártalmas szándékkal eljáró domain tulajdonosok megtévesztik az automatizált hirdetéskiszolgálási rendszereket, úgy, hogy az általuk üzemeltetett, alacsony minőségű oldalt olyannak állítják be, mintha az egy magas márkaértékű domain lenne. Az ads.txt azt a feladatot hivatott megoldani, hogy a valódi tartalomszolgáltatók általa előre kijelenthessék, hogy a megadott oldal valójában az Ő tulajdonuk, és hogy a vásáróli oldal számára egyértelművé tegyék, hogy pontosan mely rendszereken, és milyen kapcsolaton keresztül vásárolható az oldal hirdetési készlete.

2017 második felére egyre több, elsősorban a vásárlói oldalon szereplő rendszer jelentette ki, hogy nem hajlandó olyan inventory-t vásárolni, amelyen nem lelhető fel a megfelelő ads.txt file (a Digitas programmatic vezetőjének nyílt levele a témában itt olvasható). Az igazi előretörést a Google hozta el, ugyanis amíg az IAB májusi kiajánlását követő 100 napig a legnépszerűbb 10000 domain közül mindössze 13%-ban volt fellelhető a file, addig szeptember-október hónapokra ez az arány már 44%-ra ugrott. Ez az időszak pedig egybevág a Google azon állásfoglalásával, hogy mikortól kezdik el megfigyelni a file megfelelő implementálását az értékesíteni kívánt oldalakon (itt és itt olvasható több információ a Google lépéseiről).

Kettős oka van tehát az implementáció fontosságának. A vásárlói oldal számára elengedhetetlen minőségbiztosítási szempont a file megléte, másfelől pedig, a kínálati oldal számára fontos megfelelési irányelv, hiszen ha a szereplő nem akar bevételkiesés szenvedni a fenti okokból adódóan, mindenképp meg kell felelnie az IAB ajánlásainak.

Rendben, de hogyan kell elképzelni az ads.txt felépítését?

Az ads.txt (a sokak által ismert robots.txt-hez hasonlóan) egy olyan egyszerű szövegfile, amelyet a rendszergazdák az oldalaik gyökérkönyvtárában tesznek közzé ún. crawler-ek számára, amelyek a fileok meglétét, és tartalmát ellenőrzik. Ezek alapján az egyes DSP-k, vagyis a programmatic rendszerek vásárlói szereplői, képesek megbizonyosodni, hogy az oldalon van-e, és amennyiben igen, milyen tartalmú ads.txt file. A rendszer ezt az információt időközönként ellenőrzi, és megfelelteti a vásárlói oldalon tett beállításoknak, ellenőrizve, hogy valóban megfelelő inventory-t vegyen meg a hirdető a DSP-n keresztül.

A hirdetési bevételek biztosítása érdekében az ads.txt-nek minden olyan szereplő információját tartalmaznia kell, amelyeknek jogosultsága van rá, hogy hirdetésmegjelenítést végezzen az adott weboldalon, vagy egyéb digitális környezetben.

Összesen 4 változóérték tartozhat egy szereplőhöz, amelyből 3 kötelezően megadandó, és 1 opcionális feltétel. Ezek sorra: a hirdetéskiszolgáló egység neve, a rendszerben a hirdetéskiszolgálást végző fiók egyedi azonosítószáma, az értékesítés formájára vonatkozó kétértékű változó (direkt, vagy újraértékesítési) és egy opcionális kódsor, amely az első pontban megjelölt rendszer tanúsítványkibocsátó azonosítója (amennyiben elérhető).

Vegyük például, a Google és a Rubicon rendszereit. Az alábbi módon kerülnek majd bele az oldal ads.txt file-jába az azonosítók:

google.com, pub-XXXX, DIRECT, f08c47fec0942fa0
rubiconproject.com, XXXX, RESELLER, 0bfd66d529a55807

Az első érték a hirdetéskiszolgáló rendszer neve, a második a rendszer fiókazonosítója, a harmadik a kapcsolat formája, amely DIRECT, abban az esetben, ha a második pontban megjelölt fiók a tartalomszolgáltató tulajdona, RESELLER, azaz újraértékesítési, amennyiben egyéb szereplőé, a negyedik pedig a rendszerek egyedi tanúsítványkibocsátó azonosítói.

A fenti sorok megfelelő paraméterezésével és az ads.txt file feltöltésével a hirdetési felület megfelelő elérési pontjára minden szereplő egyértelműen jelezheti a rendszerek felé, hogy pontosan mely szolgáltatók, és milyen jelleggel működnek a weboldalán, ezzel elősegítve a hirdetési csalások visszaszorítását és a bevételek biztosítását.

Az Infinety természetesen minden általa értékesített weboldal esetében az ajánlás szerint jár el, vagyis az idei év során teljeskörű implementációt fogunk végezni az IAB által ajánlottaknak megfelelően.

Az ads.txt file megfelelő implementálásának ellenőrzésére is van lehetőség, ehhez érdemes ellátogatni az Appnexus validátor oldalára, amelyen domancímek ellenőrzésére valamint az elkészített ads.txt file-ok feltöltésére és felülvizsgálatára is van lehetőség.