Hirdetés
WTF is RTB 3.0?
Ez egy új protokoll, amely megváltoztathatja a hirdetések automatizált adás-vételét – ha a tőzsdék elfogadják. Az RTB 3.0 struktúrája csökkenti a duplikált kódot, ami gyorsabb licitálást tesz lehetővé. Emellett az ellátási láncban mindenkitől megköveteli, hogy hitelesített aláírást adjon az általa érintett megjelenésekhez, ami nagyobb rálátást biztosít a hirdetések vásárlóinak arra, hogy honnan származik az általuk megvásárolt készlet.
Mi a különbség a többi RTB-irányelvhez képest?
A 2012-ben megjelent RTB 2.0 a mobil programozott vásárlásra vonatkozó irányelveket határozta meg. De nem jósolta meg a header bidding – amely lehetővé teszi a kiadók számára, hogy egyszerre több tőzsdének is felajánlják a készletet, mielőtt a hirdetési kiszolgálókhoz fordulnának – vagy a mai ellátási lánc összetettségét, mondta Ian Trider, a DSP szolgáltató Centro RTB platform műveleti igazgatója. Az RTB 3.0 megpróbálja kezelni az ezen trendek által okozott problémákat.
Hogyan teszi ezt?
A header bidding a licitkérelmek robbanásszerű növekedéséhez vezetett, ami megterheli a programmatic platformokat, mivel fel kell dolgozniuk ezeket a kéréseket. A jelenlegi RTB protokollnál különböző specifikációk vannak a nyílt cserére, az over-the-top videóra és a programozott garantált készletre. Ha tehát egy kiadó ugyanazon a tőzsdén keresztül nyílt piacú és programozással garantált ajánlatokat kínálna, a tőzsdének több specifikációt kellene futtatnia az adott kiadó számára.
De ezekben a specifikációkban sok változó, például a kiadó azonosítója és a tartalom kategóriája, átfedésben van. Az RTB 3.0-val a specifikációkat úgy alakítják át, hogy ezek a változók ne ismétlődjenek a csereprogram kódjában.
“Ez csökkenti a forgalom feldolgozásához szükséges számítási terhelést, így az ajánlatok gyorsabban futnak, és kevesebb szerverre van szükség a feldolgozásukhoz” – mondta Bill Simmons, a DataXu DSP szolgáltató CTO-ja.
OK, de hogyan kezeli az RTB 3.0 a komplex ellátási láncot?
Az ellátási lánc minden egyes láncszemének alá kell írnia minden egyes hirdetést, amelyet érint. A technikai részletek kidolgozása még folyamatban van, de az elképzelés az, hogy a kiadók és a szolgáltatók titkosított azonosítójukat rábélyegzik a megjelenésekre, hogy a vevők megbizonyosodhassanak a kínálat valódi forrásáról – mondta Curt Larson, a Sharethrough natív hirdetési cég termékért felelős alelnöke. A remény az, hogy ez visszaszorítja az olyan kétes gyakorlatokat, mint a domain hamisítás.
Az ads.txt nem ezt teszi?
Félig-meddig. Az ads.txt sokkal egyszerűbb megvalósítás, mivel a vállalatoknak csak szöveges fájlokat kell feltölteniük és frissíteniük. Az RTB 3.0 nagyobb átalakítást jelent, mivel a tőzsdéknek át kell alakítaniuk a mögöttes kódjukat, hogy titkosított aláírásokat biztosítsanak. Ideális esetben a kettő együtt fog működni, hogy nagyobb átláthatóságot teremtsen az átláthatatlan ellátási lánc körül.
Milyennek tűnik az RTB 3.0 ütemterve?
Nem jelentettek be semmi hivatalosat, mivel a technikai részleteket még mindig vitatják az IAB Tech Lab munkacsoportjában. Larson gyanítja, hogy a protokollt a következő egy-két hónapban megnyitják a nyilvános véleményezésre, és egy béta verziója január környékén debütálhat.
Ez nagyszerűen hangzik. Vannak hátrányai?
Minden vállalatnak, amelyik be akarja vezetni a protokollt, mérnököket és fejlesztőket kell fordítania a platformjai átalakítására. És az ads.txt-hez hasonlóan az RTB 3.0 sikere is a hálózati hatásoktól függ.
“Elképesztő előnyei lehetnek” – mondta Larson. “De ez egy olyan változás, amelyet az embereknek el kellene fogadniuk, és ebben az iparágban nagy a lendület.”