Jei jau kurį laiką dirbate programų monetizavimo srityje, turbūt girdėjote terminus "open bidding" ir "header bidding" vartojamus beveik kaip sinonimus. Abu jie turi tą patį tikslą — sukurti realaus laiko konkurenciją tarp demand šaltinių, kad pakeltų eCPM — tačiau po gaubtu jie veikia skirtingai. Šių skirtumų supratimas yra raktas į tinkamo požiūrio pasirinkimą jūsų programai ir jūsų verslo modeliui.
Kas yra header bidding?
Header bidding atsirado internetinėje reklamoje, kur leidėjai pridėdavo JavaScript kodą savo tinklalapių "header" dalyje, kad vienu metu galėtų prašyti pasiūlymų iš kelių demand partnerių prieš iškvietimą pagrindiniam ad server. Aukščiausias pasiūlymas laimėdavo, sukuriant tikrą konkurenciją ir pašalinant nuoseklios waterfall problemą, kai demand šaltiniai iškviečiami po vieną.
Mobiliųjų programų kontekste header bidding veikia per kliento pusės SDK. Kiekvienas dalyvaujantis demand partneris turi į jūsų programą integruotą SDK. Kai atsiranda reklamos galimybė, visi SDK iškviečiami vienu metu, kiekvienas grąžina pasiūlymą, o aukščiausias pasiūlymas laimi. AppLovin MAX ir Unity LevelPlay abu palaiko šį modelį per savo in-app bidding funkcijas.
Kas yra open bidding?
Open bidding (anksčiau Exchange Bidding) yra Google serverio pusės alternatyva. Vietoj to, kad aukcionai būtų vykdomi vartotojo įrenginyje per kelis SDK, open bidding aukcioną vykdo Google serveriuose. Demand partneriai prisijungia prie Google infrastruktūros ir pateikia pasiūlymus server-to-server, taip pašalindami individualių SDK integracijų poreikį kliento pusėje.
Open bidding yra prieinamas per Google Ad Manager ir suteikia prieigą prie plačios Google demand ekosistemos bei trečiųjų šalių exchange, kurie prisijungė prie programos ir dalyvauja aukcionuose.
Pagrindiniai skirtumai
Vėlinimas
Tai pats svarbiausias praktinis skirtumas. Kliento pusės header bidding reikalauja, kad kiekvienas SDK atliktų tinklo iškvietimą, apdorotų aukcioną ir grąžintų pasiūlymą — viskas vartotojo įrenginyje. Daugiau SDK reiškia daugiau apdorojimo laiko. Open bidding veikia server-to-server, o tai paprastai yra greičiau ir nenaudoja įrenginio išteklių. Programoms, kuriose reklamos įkėlimo greitis tiesiogiai veikia vartotojo patirtį, tai yra labai svarbu.
SDK sudėtingumas
Kiekvienas header bidding partneris reikalauja SDK integracijos jūsų programoje. Daugiau SDK reiškia didesnį programos binary, daugiau galimybių konfliktams tarp SDK ir daugiau priežiūros sąnaudų, kai SDK reikia atnaujinti. Open bidding reikalauja tik Google Mobile Ads SDK, o demand partneriai prisijungia serverio pusėje. Tai žymiai sumažina techninį sudėtingumą ir palengvina išleidimo procesą.
Demand įvairovė
Header bidding per tokias platformas kaip AppLovin MAX suteikia jums prieigą prie plataus reklamos tinklų asortimento, kiekvienas su savo reklamuotojų ryšiais ir demand. Open bidding suteikia prieigą prie Google demand bei dalyvaujančių exchange, tačiau dalyvaujančių partnerių skaičius yra mažesnis nei tas, kuris prieinamas per kliento pusės bidding. Optimalus požiūris dažnai apima abu metodus.
Skaidrumas
Kliento pusės header bidding suteikia jums pilną kiekvieno partnerio pasiūlymo matomumą realiu laiku. Galite tiksliai matyti, ką pasiūlė kiekvienas tinklas, kas laimėjo ir kodėl. Open bidding teikia ataskaitas per GAM, tačiau aukcionas vyksta Google serveriuose, todėl realaus laiko matomumas bidding procese yra šiek tiek mažiau detalus nei kliento pusės sprendimuose.
Ką turėtumėte pasirinkti?
Sąžiningas atsakymas: dauguma sėkmingų leidėjų naudoja abu variantus. Štai praktinė sistema:
Naudokite open bidding per GAM kaip pagrindinį aukciono mechanizmą. Jis suteikia stiprų demand su minimaliomis SDK papildomomis sąnaudomis ir greitu reklamos įkėlimu. Tada papildykite kliento pusės bidding iš dviejų ar trijų geriausiai veikiančių tinklų per savo mediation platformą (AppLovin MAX arba Unity LevelPlay), kad užtikrintumėte maksimalią demand įvairovę.
Leidėjai, generuojantys didžiausias reklamos pajamas, nesirenka tarp open bidding ir header bidding — jie sujungia abu hibridiniame požiūryje, kuris maksimaliai padidina konkurenciją, išlaikant techninį sudėtingumą valdomą.
Hibridinis požiūris praktikoje
Tipiniame hibridiniame nustatyme jūsų waterfall atrodo taip: open bidding per GAM konkuruoja kartu su dviem ar trimis in-app bidding tinklais. Žemiau turite tradicinius waterfall įrašus tinklams, kurie nepalaiko realaus laiko bidding. Valdomas demand partneris gali būti bet kokiame šio stack lygyje, teikdamas papildomą konkurenciją, kuri naudinga jūsų bendram yield, nepriklausomai nuo to, koks aukciono mechanizmas yra naudojamas.
Svarbiausia yra per daug neapsunkinti. Pradėkite nuo open bidding per GAM, pridėkite geriausius savo mediation platformos bidding partnerius ir dirbkite su valdomu partneriu, kad užpildytumėte spragas. Tada optimizuokite pagal tai, ką sako duomenys.