Ha egy kis ideje már az alkalmazás-monetizáció területén dolgozik, hallotta az „open bidding“ és a „header bidding“ kifejezéseket szinte felcserélhetően használni. Ugyanaz a céljuk — valós idejű versenyt teremteni a demand források között az eCPM emelése érdekében — de a motorháztető alatt eltérően működnek. E különbségek megértése kulcsfontosságú ahhoz, hogy a megfelelő megközelítést válassza alkalmazásához.
Mi az a header bidding?
A header bidding a webes hirdetésből eredeztethető, ahol a kiadók JavaScript kódot adtak weboldalaik „fejlécéhez“ annak érdekében, hogy egyidejűleg kérjenek ajánlatokat több demand partnertől, még mielőtt hirdetési hívást intéztek volna elsődleges hirdetésszerverükhöz. A legmagasabb ajánlat nyert, ami valódi versenyt teremtett és megszüntette a szekvenciális waterfall problémáját, ahol a demand forrásokat egyenként hívják meg.
Mobilalkalmazás kontextusban a header bidding kliensoldali SDK-kon keresztül működik. Minden részt vevő demand partnernek van egy SDK-ja, amely be van integrálva az alkalmazásába. Amikor hirdetési lehetőség adódik, az összes SDK-t egyszerre hívják meg, mindegyik visszaad egy ajánlatot, és a legmagasabb ajánlat nyer. Az AppLovin MAX és az Unity LevelPlay egyaránt támogatja ezt a modellt az in-app bidding funkcióikon keresztül.
Mi az az open bidding?
Az open bidding (korábban Exchange Bidding) a Google szerveroldali alternatívája. Ahelyett, hogy az aukciókat a felhasználó eszközén több SDK-n keresztül futtatná, az open bidding az aukciót a Google szerverein futtatja. A demand partnerek a Google infrastruktúrájához csatlakoznak, és szerverről szerverre nyújtják be ajánlataikat, ezzel kiküszöbölve az egyéni kliensoldali SDK-integrációk szükségességét.
Az open bidding a Google Ad Manageren keresztül érhető el, és hozzáférést biztosít a Google kiterjedt demand ökoszisztémájához, valamint a programhoz csatlakozott harmadik fél tőzsdékhez.
Fő különbségek
Késleltetés
Ez a legjelentősebb gyakorlati különbség. A kliensoldali header bidding megköveteli, hogy minden SDK hálózati hívást hajtson végre, feldolgozza az aukciót és visszaadjon egy ajánlatot — mindez a felhasználó eszközén. Több SDK több feldolgozási időt jelent. Az open bidding szerverről szerverre fut, ami jellemzően gyorsabb és nem fogyaszt eszközerőforrásokat. Azoknál az alkalmazásoknál, ahol a hirdetés betöltési sebessége közvetlenül befolyásolja a felhasználói élményt, ez számít.
SDK bonyolultság
Minden header bidding partner SDK-integrációt igényel az alkalmazásában. Több SDK nagyobb alkalmazásbinárist, több lehetséges SDK-ütközést és több karbantartási többletterhet jelent, amikor az SDK-kat frissíteni kell. Az open bidding csak a Google Mobile Ads SDK-t igényli, miközben a demand partnerek szerveroldalon csatlakoznak. Ez jelentősen csökkenti a technikai bonyolultságot.
Demand sokszínűség
A header bidding olyan platformokon keresztül, mint az AppLovin MAX, hozzáférést biztosít a hirdetési hálózatok széles skálájához, amelyek mindegyike saját hirdetői kapcsolatokkal és demanddal rendelkezik. Az open bidding hozzáférést ad a Google demandjához és a részt vevő tőzsdékhez, de a részt vevő partnerek köre kisebb, mint ami a kliensoldali bidding-en keresztül elérhető. Az optimális megközelítés gyakran mindkettőt magában foglalja.
Átláthatóság
A kliensoldali header bidding teljes valós idejű rálátást biztosít minden partner ajánlatára. Pontosan látja, melyik hálózat mit ajánlott, ki nyert és miért. Az open bidding jelentéseket biztosít a GAM-en keresztül, de az aukció a Google szerverein zajlik, így kissé kevésbé részletes valós idejű rálátást kap a bidding folyamatra.
Melyiket válassza?
Az őszinte válasz: a legtöbb sikeres kiadó mindkettőt használja. Íme egy gyakorlati keretrendszer:
Használja az open bidding-et a GAM-en keresztül elsődleges aukciós mechanizmusként. Erős demandot biztosít minimális SDK többletterheléssel és gyors hirdetésbetöltéssel. Majd egészítse ki kliensoldali bidding-gel két-három legjobban teljesítő hálózattól a mediation platformján (AppLovin MAX vagy Unity LevelPlay) keresztül, hogy biztosítsa a maximális demand sokszínűséget.
A legmagasabb hirdetési bevételt generáló kiadók nem választanak az open bidding és a header bidding között — a kettőt egy hibrid megközelítésben kombinálják, amely maximalizálja a versenyt, miközben a technikai bonyolultságot kezelhető szinten tartja.
A hibrid megközelítés a gyakorlatban
Egy tipikus hibrid beállításban a waterfall-ja így néz ki: az open bidding a GAM-en keresztül két vagy három in-app bidding hálózat mellett verseng. Alatta hagyományos waterfall bejegyzések találhatók azon hálózatokhoz, amelyek nem támogatják a valós idejű bidding-et. Egy menedzselt demand partner a verem bármely szintjén elhelyezkedhet, további versenyt biztosítva, ami az összhozamának javára válik, függetlenül attól, hogy melyik aukciós mechanizmus van használatban.
A kulcs az, hogy ne bonyolítsa túl. Kezdje az open bidding-gel a GAM-en keresztül, adja hozzá a mediation platformja legjobb bidding partnereit, és dolgozzon együtt egy menedzselt partnerrel a hézagok kitöltésére. Aztán optimalizáljon az alapján, amit az adatok mondanak.