EasySSP kiszolgálás
Szerző: Adverticum Zrt. on 2017 May 8. 17:16
|
|
Ez a szolgáltatás csak Hoppex tagoknak érhető el. Kérjük, vegye fel a kapcsolatot a szolgáltatóval! Tartalomjegyzék
EasySSP az Adverticum rendszerébenAz Adverticum rendszerében elérhetővé vált az EasySSP funkció, amely megkönnyíti az automatizált értékesítési folyamatot, hiszen az ügyfelek egy felületen kezelhetik hagyományos és programmatic kampányaikat. Az EasySSP funkció használatához két dologra van szükség: egyrészről az Adverticum rendszerével API szinten kapcsolatban álló ad exchange platformra, amely jelenleg a Rubicon Project RTB rendszere, másrészről pedig arra, hogy az Adverticum rendszerében elérhető EasySSP funkcióval rendelkezzen a felhasználó. Ennek engedélyezése ügyfélszinten történik, amelyet megrendelés után munkatársaink tudnak bekapcsolni a megrendelő részére. Az EasySSP használata előtt létre kell hozni a Rubicon rendszerében a saját profilt, site adatokat és a zónákat is, amelyeket az ad exchange platformra szánnak. Az itt létrehozott egységek ID-jait kell felhasználni az Adverticum EasySSP rendszerében az RTB-s kampányok futtatásához. Ezen adatok lekéréséhez javasoljuk, hogy használják a Rubicon felületén az Inventory Setup menün belül, a TAGS listában megjelenített beépítési kódokat, itt minden ID egy helyen megtalálható. Site adatokA Rubicon specifikus beállításokat az Adverticum adminfelületén, az EasySSP fül alatt található felületen kell megadni.
FONTOS! A Page URL és Domain esetében is az url-ben lévő domain-nek szerepelnie kell a Rubiconban megadott site-hoz tartozó url-ek között! Figyelem! A nem kötelezően megadható opciók üresen hagyása esetén a rendszer a Rubiconban megadott értékeket veszi figyelembe!
Kampánybeállítások az EasySSP-s kiszolgáláshoz Annak érdekében, hogy a rendszer képes legyen egy zónában EasySSP-s hirdetések kiszolgálására is, az AdServer kampányok beállításainak lehetőségeit bővítettük további RTB specifikus funkciókkal. A tényleges Rubicon zónát az Adverticum rendszerében RTB Bannerként kell felvenni, azonban bizonyos elemeket/paramétereket megadhatunk zónaszinten is. FONTOS! Csak olyan kampány alá lehet RTB bannert felvenni, aminél hirdetőnek a "Saját szereplő" van beállítva. Ez kampány- és bannermásolás esetén is érvényes. EasySSP terv létrehozásaA hibalehetőségek csökkentése és a további funkcionalitás érdekében a tervek felvétele során, az Ár megadásakor rendelkezni kell arról, hogy a tervhez milyen típusú ár tartozik. Itt dönthet a felhasználó arról, hogy nem ad meg árat (Nem), ár alapú priorizációt használ-e (Igen) vagy RTB-s tervet szeretne létrehozni (RTB). Figyelem! A „Nem” opció kiválasztásával a korábban megadott kampányár automatikusan öröklődik. Ennek módosítására mentés után van lehetőség. Abban az esetben, ha az RTB opciót választjuk, megjelennek a terv RTB specifikus beállításai.
FONTOS! A bannernél megadott Bidfloor lesz az érvényes, ha azt külön a banner részleteinél beállították. Ugyanitt lehetőség van még a „Bidfloor figyelmen kívül hagyása” opcióra is, amellyel a rendszer nem figyeli az AdServer-ben beállított minimum licit árat, csak a Rubiconban beállított értékek a mérvadók. (Ha bepipálásra kerül, akkor az Adverticumban beállított licitár figyelmen kívül marad, legyen az az adott banneren, vagy a hozzá tartozó terven megadva.)
Figyelem! A nem kötelezően megadható opciók üresen hagyása esetén a rendszer, a Rubiconban megadott értékeket veszi figyelembe! Figyelem! Abban az esetben, ha RTB tervet használunk, akkor az ár mezőt (tehát a hagyományos ár alapú priorizációs beállításokat) a terv-zóna oldalról a rendszer nem veszi figyelembe. FONTOS!
RTB banner felvételeFigyelem! Csak saját hirdetővel felvett kampány alá lehet RTB bannert felvenni, vagy másolni.
Az RTB banner megadható paraméterei a következők:
FONTOS! Amennyiben nem megfelelő Site-ot választ ki az RTB bannerhez, abban az esetben nem fog választ küldeni az SSP rendszere, mert a megfelelő adatok kerülnek továbbításra.
FONTOS! A bannernél megadott Bidfloor lesz az érvényes, ha azt külön a banner részleteinél beállították. Ugyanez vonatkozik a „Bidfloor figyelmen kívül hagyása” opcióra is!
Az RTB banner aktuális Bidorder és Bidfloor értéke tervenként a Terv/Banner listázásban érhető el. Az RTB terven megadott Bidordert örökli a banner is, azonban a listázásban lehetőség van ennek módosítására! A beállítások véglegesítéséhez azonban szükség van a Terv/Banner listázás menüsorban lévő Változások mentése gomb megnyomására is. FONTOS! A bannerhez tartozó Bidfloor értéket csak a terv részleteinél, vagy a tervhez tartozó bannereken részleteinél lehet megadni, a listázásokban azonban nem! FONTOS! A Terv/Banner listázásban lévő Bidfloor értéket használja a rendszer a licitek megadásakor! ZónabeállításokAhhoz, hogy egy adott zónában RTB-s kampány futhasson, zónaszinten is engedélyezni kell az RTB funkciót (Igen/Nem). Az „RTB” funkció engedélyezésével tehető egy adott zóna RTB kompatibilissé, vagyis itt adhatjuk meg, hogy az adott zóna részt vegyen-e az EasySSP kiszolgálásban. A zóna objektum esetében tehát az alábbi RTB specifikus adatokat adhatjuk meg:
Figyelem! RTB-s zónákban nem csak RTB-s tervek és bannerek futtathatók! RTB zóna kompatibilitások:Méret:
Display:
Az AdServerbe felvett egyéb ár alapú priorizációs tervek versenyeztetése az SSP rendszerből érkező hirdetésekkel, jutalék levonás figyelembevételével, esetleges árfolyam átszámítássalAz EasySSP használatával lehetőséget biztosítunk felhasználóinknak a Rubicon SSP rendszeréből érkező kampányok kiszolgálására, az Adverticumban felvett egyéb fizetős kampányokkal együttműködve, a legmagasabb bevételre törekedve. A tartalomszolgáltatók érdeke, hogy az SSP szolgáltató jutalékának levonása után is jobban járjanak, mintha egyéb az AdServer-be felvett tervet szolgált volna ki a rendszer. Ehhez mindenképpen szükséges, hogy az adott price értékénél ne csak az adott zónában futó legdrágább megjeleníthető terv árát vegye figyelembe kiszolgáláskor a rendszer, hanem az SSP szolgáltató jutalékát is, amit le fognak vonni a kiszolgált hirdetés árából. Tehát, ha a Rubicon 18%-ot von le a kiszolgált hirdetések árából jutaléknak, akkor a price-t 1,219512-vel beszorozva kell elküldenünk (1/0.82) az SSP szolgáltatónak, így annál drágább RTB hirdetés megjelenítése esetén többet keresnek (a jutalék levonásával együtt is). Egy példával szemléltetve: Az adott zónában futó legdrágább Adserverben felvett megjeleníthető hirdetés ára 99 Ft. Ilyenkor az Adverticum AdServer-e kérést küld az SSP szolgáltató felé, hogy van-e ennél drágábban megjeleníthető hirdetése. Azonban ilyenkor nem 99 Ft-nál drágábbat kér, hanem 99x1,219512, azaz 120,7316 Ft-nál. Amennyiben csak 99 Ft-ot mondott volna, akkor az SSP szolgáltató adhat pl. 100 Ft-os hirdetést, ami viszont a jutalék levonása után a tartalomszolgáltatónak csak 82 Ft bevételt jelentene. Mindemellett a rendszerbe új funkcióként bekerült egy árfolyam számoló komponens, amelynek feladata az aktuális napi árfolyam szerinti árszámítás. A Rubicon rendszerében az alap valuta dollárban értendő, ezért szükséges volt valuta konverziót alkalmaznunk, hogy a felhasználóinknak lehetősége legyen az ár alapú priorizáció esetében versenyeztetni az impression-ök értékét a Rubicon rendszeréével. Funkcionálisan ez azt jelenti, hogy az ár alapú priorizáció esetében lehetőség van már az árat forintban (HUF), euróban (EUR), és dollárban (USD) is megadni, amely összeget aztán a rendszer a napi aktuális árfolyam szerint tovább konvertálja dollárba, és úgy számol vele a továbbiakban.
További információt az ár alapú priorizáció használatáról Tudásbázisunk ezen bejegyzésében olvashat. RTB Statisztika:Statisztika hozzáférés esetében külön-külön beállítható az Easy SSP statisztika elérhetősége az egyes felhasználóknak. A fiókban a felhasználó nevére kattintva lehet jogosultságot adni vagy módosítani azt, az „Összes mérőszám” mellett lévő checkbox kipipálásával. Minden profilhoz tartozó user esetén külön szabályozni lehet a hozzáféréseket (ezt bárki megteheti, akinek teljes hozzáférése van az adott fiók használatához). FONTOS! Az elszámolás alapját a Rubicon saját statisztikája határozza meg, a pontos és részletes adatokat az SSP rendszer szolgáltatja. Az Adverticum AdServerében is lekérhetők statisztikai adatok az RTB kampányok teljesítéséről A statisztika nem változik lényegesen a megszokott formához képest, a rendszerben három új mérőpontot vezettünk be, amellyel a felhasználó nyomon tudja követni az eladott impressönök darabszámát, összegét és átlagos bevételét.
A kiszolgálás folyamataA gyorsabb és hatékonyabb működés érdekében az Adverticum kiszolgálókódja, a Goa3 külön kérésként kezeli az RTB-s zónákat. Ez azért lényeges, hogy az adott oldal betöltődését ne befolyásolja ez a másfajta kiszolgálási mód. Az ügyfél részéről eldönthető, hogy a Goa3 az RTB-s és nem RTB-s zónákat egy vagy külön kérésben kezelje. Az alapértelmezett működés használatával a beépítés szempontjából nem teszünk különbséget a zónák között, illetve a beépítési kódokon sem változtattunk. Amennyiben az alapértelmezett működést használjuk doc.write-os beépítés mellett, úgy az RTB-s válaszokat a <head>-ben kérjük és kapjuk meg. Ezeket a böngészők mindenképp megvárják az oldalbetöltés során, így nagyban nőhet az oldalak töltési ideje. Szeparált kérésekFIGYELEM! RTB-s zónák alatt az RTB tulajdonságokkal ellátott zónák értendőek!Amennyiben azt szeretnénk, hogy az RTB-s zónákat külön kérésben kezeljük, az alábbi meta tag-et szükséges a weboldal <head> részébe építeni.
Fontos, hogy a beépítési kódokat a már ismert módszerrel, változatlanul kell használni! Abban az esetben, ha a fenti meta tag szerepel az oldalban, maga az invokáció a következőképpen módosul. A zónák lekérésénél először csak a nem RTB-s zónákat kapja meg a Goa3 a szerverektől. Ezeket változatlan módon kezeli és beépíti. Miután az összes kért zóna kiszolgálódott, az RTB-seket egy új kérésben megkapja és kiszolgálja az RTB-s zónákat is. Ezt a lehetőséget használva gyorsabbá tehetjük a bannerek megjelenését, mivel nem fog az összes zóna „üresen” várakozni a Rubicon válaszára, illetve az oldalak betöltődésére sincs hatással. Ennek következménye, hogy a nem RTB-s hirdetések kizárhatják az RTB-seket, melynek oka, hogy az RTB-s invokáció akkor indul, mikor már szerepelhetnek bannerek az oldalban. Document.write -os invokáció változásaiEbben az esetben nincs más dolgunk, csak a fent említett meta tag-et elhelyezni az oldalban, amelynek következtében a doc.write-os invokáció a következőképpen módosul. A loadZones() metódust a már megszokott módon kell meghívni minden előtölteni kívánt zónára, majd ezek közül a rendszerünk automatikusan kiválasztja és kezeli az RTB-s zónákat. Magát a beépítést a hagyományos insertBanner() hívással tehetjük meg. Ez a hívás a nem RTB-s zónákat a hagyományos módon az oldalba építi, míg az RTB-s zónák esetében egy „sima” Goa3-as beépítési kódot ír az oldalba, így lényegében a doc.write-os RTB-s zónák Goa3-mas invokációval szolgálódnak majd ki. Mivel az RTB-s bannereket minden dom.ready utáni esetben iFrame-ben jelenítjük meg, nem okoznak gondot a doc.write-ot tartalmazó függvényhívások sem. Előnyei:
Hátrányai:
Kiértékelés folyamataEgy zónában, egy waterfall szinten több zónamérethez tartozó Rubicon kérések párhuzamosíthatók! Ha az RTB kérések timeout-ja (időtúllépése) esetén nem kapunk adott időben választ a Rubicontól, a bannerek kiválasztása úgy folytatódik, mintha a Rubicon nem tudott volna a kérésre választ adni. A Rubicon rendszere felé csak azokat a lekérdezéseket tudjuk párhuzamosan elküldeni, amelyek azonos zónában futnak, és a prioritásaik megegyeznek. A Rubicon felé párhuzamosan kiküldhető kérések sorrendje a Bidorder mezővel határozható meg, azonban az egyszerre kiküldött kérésekre visszaérkező válaszok közül a legértékesebbet szolgáljuk ki. Fontos, hogy a maximálisan egyszerre küldhető párhuzamos kérések száma három (jelenlegi megállapodás szerint, azonban ezt a Rubicon egyoldalúan módosíthatja)! Egy oldalbetöltés esetén az RTB kérések a waterfall modell minden szintjére és minden zónájára szekvenciálisan történnek (feltételezve, hogy a waterfall modellt úgy valósítjuk meg, hogy különböző prioritási szinteken futó RTB-s terveket veszünk fel). Fontos, hogy a Rubicon rendszerből érkező kiszolgálás a megszokottnál akár több időt is igénybe vehet! Abban az esetben, ha a Rubicon rendszerében esetlegesen akadozna a kiszolgálás, az EasySSP rendszerében egy „Rubicon kérésenként” történő timeout jön létre. Mivel több kérés küldése történik a Rubicon rendszer felé, egy „Rubicon összes kérés” esetén történő timeout is létrejön. Ezek értéke jelenleg:
A fenti idők rendszerszinten konfigurálhatóak és kérés esetén módosíthatóak! FONTOS! Amíg az Adverticum kiszolgáló rendszere a Rubicon válaszára várakozik, addig a nem RTB-s kiszolgálás sem történik meg, ha nem szeparált kérésként kezelik az RTB-s zónákat!
| |
|