Калі вы займаецеся манетызацыяй дадаткаў пэўны час, вы чулі тэрміны „Open Bidding" і „header bidding" ужытыя амаль як сінонімы. Яны падзяляюць адну мэту — ствараць канкурэнцыю ў рэальным часе паміж крыніцамі demand, каб павышаць eCPM — але пад капотам працуюць па-рознаму. Разуменне гэтых адрозненняў — ключ да выбару правільнага падыходу для вашага дадатку.
Што такое Header Bidding?
Header bidding з'явіўся ў вэб-рэкламе, дзе выдаўцы дадавалі JavaScript код у „хедэр" сваіх вэб-старонак, каб адначасова запытваць стаўкі ад некалькіх demand партнёраў перад выклікам рэкламы да свайго асноўнага рэкламнага сервера. Найвышэйшая стаўка перамагала, ствараючы сапраўдную канкурэнцыю і ліквідуючы праблему паслядоўнага waterfall, дзе крыніцы demand выклікаюцца па адной.
У кантэксце мабільных дадаткаў 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 і падаюць стаўкі сервер-да-сервера, ліквідуючы неабходнасць індывідуальных інтэграцый SDK на баку кліента.
Open Bidding даступны праз Google Ad Manager і забяспечвае доступ да шырокай экасістэмы demand Google плюс exchanges трэціх бакоў, якія далучыліся да праграмы.
Ключавыя адрозненні
Затрымка
Гэта найбольш значнае практычнае адрозненне. Кліенцкі header bidding патрабуе, каб кожны SDK зрабіў сеткавы выклік, апрацаваў аўкцыён і вярнуў стаўку — усё гэта на прыладзе карыстальніка. Больш SDK азначае больш часу апрацоўкі. Open Bidding працуе сервер-да-сервера, што звычайна хутчэй і не спажывае рэсурсы прылады. Для дадаткаў, дзе хуткасць загрузкі рэкламы наўпрост уплывае на карыстальніцкі вопыт, гэта важна.
Складанасць SDK
Кожны партнёр header bidding патрабуе інтэграцыі SDK у вашым дадатку. Больш SDK азначае большы бінарны файл дадатку, больш патэнцыялу для канфліктаў SDK і больш выдаткаў на абслугоўванне, калі SDK трэба абнаўляць. Open Bidding патрабуе толькі Google Mobile Ads SDK, прычым demand партнёры падлучаюцца на баку сервера. Гэта значна зніжае тэхнічную складанасць.
Разнастайнасць demand
Header bidding праз платформы кшталту AppLovin MAX дае вам доступ да шырокага набору рэкламных сетак, кожная са сваімі адносінамі з рэкламадаўцамі і сваім demand. Open Bidding дае вам доступ да demand Google плюс удзельнічаючых exchanges, але пул удзельнічаючых партнёраў меншы за тое, што даступна праз кліенцкі bidding. Аптымальны падыход часта ўключае абодва.
Празрыстасць
Кліенцкі header bidding дае вам поўную бачнасць стаўкі кожнага партнёра ў рэальным часе. Вы можаце дакладна ўбачыць, што прапаноўвала кожная сетка, хто перамог і чаму. Open Bidding прадастаўляе справаздачы праз GAM, але аўкцыён адбываецца на серверах Google, што дае вам крыху менш дэталізаваную бачнасць працэсу bidding у рэальным часе.
Што вам выбраць?
Сумленны адказ: большасць паспяховых выдаўцоў выкарыстоўваюць абодва. Вось практычная схема:
Выкарыстоўвайце Open Bidding праз GAM як асноўны механізм аўкцыёну. Ён забяспечвае моцны demand з мінімальнымі выдаткамі SDK і хуткай загрузкай рэкламы. Затым дапоўніце кліенцкім bidding ад двух-трох найлепшых сетак праз вашу mediation платформу (AppLovin MAX або Unity LevelPlay), каб забяспечыць максімальную разнастайнасць demand.
Выдаўцы, якія генеруюць найвышэйшыя рэкламныя даходы, не выбіраюць паміж Open Bidding і header bidding — яны спалучаюць абодва ў гібрыдным падыходзе, які максімізуе канкурэнцыю і захоўвае тэхнічную складанасць кіраванай.
Гібрыдны падыход на практыцы
У тыповай гібрыднай канфігурацыі ваш waterfall выглядае так: Open Bidding праз GAM канкуруе побач з дзвюма-трыма сеткамі in-app bidding. Ніжэй за іх у вас традыцыйныя запісы waterfall для сетак, якія не падтрымліваюць bidding у рэальным часе. Кіраваны demand партнёр можа знаходзіцца на любым узроўні гэтага стэка, забяспечваючы дадатковую канкурэнцыю, якая спрыяе вашай агульнай прыбытковасці незалежна ад выкарыстоўванага механізму аўкцыёну.
Ключ у тым, каб не перагружаць гэта складанасцю. Пачніце з Open Bidding праз GAM, дадайце найлепшых партнёраў bidding вашай mediation платформы і працуйце з кіраваным партнёрам, каб запоўніць прабелы. Затым аптымізуйце на аснове таго, што кажуць вам дадзеныя.