Kui olete rakenduste monetiseerimise valdkonnas tegutsenud natukenegi, olete kuulnud termineid „open bidding“ ja „header bidding“ kasutatavat peaaegu sünonüümidena. Neil on sama eesmärk — luua reaalajas konkurents nõudluse allikate vahel, et tõsta eCPM-e — kuid nende tööpõhimõte on erinev. Nende erinevuste mõistmine on võti õige lähenemise valimiseks teie rakendusele.
Mis on header bidding?
Header bidding sai alguse veebireklaamist, kus väljaandjad lisasid oma veebilehtede päisesse JavaScripti koodi, et küsida samaaegselt pakkumisi mitmelt nõudluspartnerilt enne reklaamikõne tegemist oma peamisele reklaamiserverile. Kõrgeim pakkumine võitis, luues tõelise konkurentsi ja kõrvaldades järjestikuse waterfall probleemi, kus nõudluse allikaid kutsutakse ükshaaval.
Mobiilirakenduste kontekstis töötab header bidding kliendipoolsete SDK-de kaudu. Igal osaleval nõudluspartneril on teie rakendusse integreeritud SDK. Kui tekib reklaamivõimalus, kutsutakse kõiki SDK-sid üheaegselt, igaüks tagastab pakkumise ja kõrgeim pakkumine võidab. Nii AppLovin MAX kui ka Unity LevelPlay toetavad seda mudelit oma in-app bidding funktsioonide kaudu.
Mis on open bidding?
Open bidding (varem Exchange Bidding) on Google'i serveripoolne alternatiiv. Selle asemel, et käivitada oksjonid kasutaja seadmes mitme SDK kaudu, käivitab open bidding oksjoni Google'i serverites. Nõudluspartnerid ühenduvad Google'i infrastruktuuriga ja esitavad pakkumised serverist serverisse, kõrvaldades vajaduse eraldi SDK-integratsioonide järele kliendi poolel.
Open bidding on saadaval Google Ad Manageri kaudu ning pakub juurdepääsu Google'i ulatuslikule nõudluse ökosüsteemile ja programmiga liitunud kolmandate osapoolte börsidele.
Peamised erinevused
Latentsus
See on kõige olulisem praktiline erinevus. Kliendipoolne header bidding nõuab, et iga SDK teeks võrgukõne, töötleks oksjoni ja tagastaks pakkumise — kõik kasutaja seadmes. Rohkem SDK-sid tähendab rohkem töötlemisaega. Open bidding töötab serverist serverisse, mis on tavaliselt kiirem ega tarbi seadme ressursse. Rakenduste jaoks, kus reklaami laadimise kiirus mõjutab otseselt kasutajakogemust, on see oluline.
SDK keerukus
Iga header bidding partner nõuab teie rakenduses SDK-integratsiooni. Rohkem SDK-sid tähendab suuremat rakendusebinaari, rohkem võimalikke SDK-konflikte ja rohkem hooldusvaeva, kui SDK-sid on vaja uuendada. Open bidding vajab ainult Google Mobile Ads SDK-d, kusjuures nõudluspartnerid ühenduvad serveri poolel. See vähendab märgatavalt tehnilist keerukust.
Nõudluse mitmekesisus
Header bidding platvormide nagu AppLovin MAX kaudu saate juurdepääsu laiale reklaamivõrkude valikule, kus igaühel on oma reklaamijate suhted ja nõudlus. Open bidding annab juurdepääsu Google'i nõudlusele pluss osalevatele börsidele, kuid osalevate partnerite hulk on väiksem kui kliendipoolse bidding'u kaudu saadaval. Optimaalne lähenemine hõlmab tihti mõlemat.
Läbipaistvus
Kliendipoolne header bidding annab teile täieliku nähtavuse iga partneri pakkumisse reaalajas. Näete täpselt, mida iga võrk pakkus, kes võitis ja miks. Open bidding pakub aruandlust GAM-i kaudu, kuid oksjon toimub Google'i serverites, andes teile pisut vähem detailset reaalajas nähtavust bidding protsessi.
Millise peaksite valima?
Aus vastus: enamik edukaid väljaandjaid kasutab mõlemat. Siin on praktiline raamistik:
Kasutage oma peamise oksjonimehhanismina open bidding'ut GAM-i kaudu. See pakub tugevat nõudlust minimaalse SDK koormusega ja kiiret reklaamide laadimist. Seejärel täiendage seda kliendipoolse bidding'uga kahelt kuni kolmelt tippvõrgustikult läbi oma mediation platvormi (AppLovin MAX või Unity LevelPlay), et tagada maksimaalne nõudluse mitmekesisus.
Kõrgeimat reklaamitulu teenivad väljaandjad ei vali open bidding'u ja header bidding'u vahel — nad kombineerivad mõlemat hübriidses lähenemises, mis maksimeerib konkurentsi, hoides samal ajal tehnilise keerukuse hallatavana.
Hübriidne lähenemine praktikas
Tüüpilises hübriidses seadistuses näeb teie waterfall välja selline: open bidding GAM-i kaudu konkureerib kõrvuti kahe või kolme in-app bidding võrgustikuga. Selle all on traditsioonilised waterfall kirjed võrgustikele, mis reaalajas bidding'ut ei toeta. Hallatud nõudluspartner võib asuda selle virna igal tasemel, pakkudes täiendavat konkurentsi, mis toob kasu teie üldisele tootlusele, sõltumata sellest, millist oksjonimehhanismi kasutatakse.
Võti on mitte seda üle keerukaks teha. Alustage open bidding'uga GAM-i kaudu, lisage oma mediation platvormi parimad bidding partnerid ning tehke koostööd hallatud partneriga, et täita lüngad. Seejärel optimeerige selle põhjal, mida andmed teile ütlevad.