Егер сіз қолданба монетизациясы саласында біраз уақыт жұмыс істеген болсаңыз, "open bidding" және "header bidding" терминдерін дерлік бір мағынада қолданылғанын естіген боларсыз. Олар бір мақсатты бөліседі — eCPM-ды жоғарылату үшін demand көздерінің арасында нақты уақыттағы бәсекелестікті құру — бірақ ішкі жұмыс істеу принципі әртүрлі. Осы айырмашылықтарды түсіну сіздің қолданбаңызға сәйкес тәсілді таңдаудың кілті болып табылады.
Header bidding дегеніміз не?
Header bidding веб-жарнамадан бастау алды, онда баспагерлер веб-беттерінің "header" бөлігіне JavaScript кодын қосып, негізгі ad server-ге жарнамалық шақыру жасамас бұрын бірнеше demand серіктестерден бір мезгілде ұсыныстар сұрайтын. Ең жоғары ұсыныс жеңіп шығатын, нақты бәсекелестік құрылатын және demand көздері бірінен соң бірі шақырылатын кезекті waterfall мәселесі жойылатын.
Мобильді қолданбалар контекстінде, header bidding клиенттік SDK арқылы жұмыс істейді. Әр қатысушы demand серіктестің қолданбаңызға интеграцияланған SDK-сы бар. Жарнамалық мүмкіндік туындағанда, барлық SDK бір мезгілде шақырылады, әрқайсысы ұсыныс қайтарады және ең жоғары ұсыныс жеңеді. AppLovin MAX және Unity LevelPlay екеуі де осы модельді in-app bidding функциялары арқылы қолдайды.
Open bidding дегеніміз не?
Open bidding (бұрынғы Exchange Bidding) — Google-дың сервер жағындағы балама нұсқасы. Пайдаланушы құрылғысында бірнеше SDK арқылы аукциондарды өткізудің орнына, open bidding аукционды Google серверлерінде өткізеді. Demand серіктестер Google инфрақұрылымына қосылып, ұсыныстарды server-to-server жібереді, бұл клиент жағында жеке SDK интеграциясының қажеттілігін жояды.
Open bidding Google Ad Manager арқылы қолжетімді және Google-дың кең demand экожүйесіне қоса, бағдарламаға қосылған үшінші тарап exchange-дерінің барлығына қол жеткізуді қамтамасыз етеді.
Негізгі айырмашылықтар
Кідіріс
Бұл ең маңызды практикалық айырмашылық. Клиенттік header bidding әр SDK-ға желілік шақыру жасауды, аукционды өңдеуді және ұсынысты қайтаруды талап етеді — барлығы пайдаланушы құрылғысында. SDK саны көп болған сайын өңдеу уақыты ұзарады. Open bidding server-to-server жұмыс істейді, бұл әдетте жылдамырақ және құрылғы ресурстарын тұтынбайды. Жарнаманың жүктелу жылдамдығы пайдаланушы тәжірибесіне тікелей әсер ететін қолданбалар үшін бұл маңызды.
SDK күрделілігі
Әрбір header bidding серіктес қолданбаңызға SDK интеграциясын талап етеді. SDK көп болған сайын қолданбаның binary-сы үлкейеді, SDK арасындағы қақтығыстар ықтималдығы артады және SDK жаңартуды қажет еткенде қызмет көрсету шығындары өседі. Open bidding тек Google Mobile Ads SDK-сын талап етеді, ал demand серіктестер сервер жағында қосылады. Бұл техникалық күрделілікті айтарлықтай азайтады.
Demand әртүрлілігі
AppLovin MAX сияқты платформалар арқылы header bidding сізге әрқайсысының өзіндік жарнама беруші қарым-қатынастары мен demand-ы бар кең ауқымды жарнама желілеріне қол жеткізеді. Open bidding Google-дың demand-ына қоса қатысушы exchange-дерге қол жеткізеді, бірақ қатысушы серіктестер саны клиенттік bidding арқылы қолжетімді санынан аз. Оңтайлы тәсіл көбінесе екеуін де қамтиды.
Мөлдірлік
Клиенттік header bidding сізге әр серіктестің ұсынысын нақты уақытта толық көруге мүмкіндік береді. Әр желінің қанша ұсынғанын, кім жеңгенін және неліктен жеңгенін нақты көре аласыз. Open bidding GAM арқылы есеп береді, бірақ аукцион Google серверлерінде өтеді, бұл bidding процесіне нақты уақыттағы көріністі аздап аз егжей-тегжейлі береді.
Қайсысын таңдау керек?
Шынайы жауап: ең табысты баспагерлердің көпшілігі екеуін де пайдаланады. Міне практикалық негіз:
Open bidding-ді GAM арқылы негізгі аукцион механизмі ретінде пайдаланыңыз. Ол ең аз SDK қосымша жүктемесімен және жарнаманың жылдам жүктелуімен күшті demand қамтамасыз етеді. Содан кейін mediation платформасы (AppLovin MAX немесе Unity LevelPlay) арқылы екі-үш ең жоғары көрсеткішті желілерден клиенттік bidding-пен толықтырыңыз, бұл demand-тың максималды әртүрлілігін қамтамасыз етеді.
Ең жоғары жарнамалық табыс жасайтын баспагерлер open bidding мен header bidding арасында таңдамайды — олар техникалық күрделілікті басқарылатын деңгейде ұстай отырып, бәсекелестікті барынша арттыратын гибридті тәсілде екеуін біріктіреді.
Іс жүзіндегі гибридті тәсіл
Әдеттегі гибридті конфигурацияда, сіздің waterfall-ыңыз былай көрінеді: GAM арқылы open bidding екі-үш in-app bidding желілерімен қатар бәсекеге түседі. Оның астында нақты уақыттағы bidding-ті қолдамайтын желілер үшін дәстүрлі waterfall жазбалары бар. Басқарылатын demand серіктес осы stack-тың кез келген деңгейінде орналасуы мүмкін, бұл қосымша бәсекелестік беріп, жалпы yield-ге пайда әкеледі.
Негізгісі — шамадан тыс күрделі етпеу. GAM арқылы open bidding-пен бастаңыз, mediation платформасының ең жақсы bidding серіктестерін қосыңыз және басқарылатын серіктеспен жұмыс істеп, олқылықтарды толтырыңыз. Содан кейін деректер не айтса, соған сүйеніп оңтайландырыңыз.