Если вы занимаетесь монетизацией приложений хотя бы какое-то время, вы наверняка слышали, как термины "open bidding" и "header bidding" используют почти как синонимы. У них общая цель — создать конкуренцию в реальном времени между источниками demand, чтобы повысить eCPM, — но технически они работают по-разному. Понимание этих различий — ключ к выбору правильного подхода для вашего приложения.
Что такое header bidding?
Header bidding появился в веб-рекламе: издатели добавляли JavaScript-код в "header" своих веб-страниц, чтобы одновременно запрашивать ставки у нескольких партнёров по 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 и передают ставки по схеме server-to-server, что исключает необходимость в отдельных интеграциях SDK на стороне клиента.
Open bidding доступен через Google Ad Manager и предоставляет доступ к обширной экосистеме demand Google, а также к сторонним биржам, подключённым к программе.
Ключевые различия
Задержка
Это самое значимое практическое различие. Клиентский header bidding требует, чтобы каждый SDK сделал сетевой вызов, обработал аукцион и вернул ставку — всё это на устройстве пользователя. Чем больше SDK, тем больше времени на обработку. Open bidding работает по схеме server-to-server, что обычно быстрее и не расходует ресурсы устройства. Для приложений, где скорость загрузки рекламы напрямую влияет на пользовательский опыт, это имеет значение.
Сложность SDK
Каждый партнёр header bidding требует интеграции SDK в ваше приложение. Больше SDK — это больший размер бинарного файла приложения, больше риск конфликтов между SDK и больше работы по поддержке при обновлении SDK. Open bidding требует только Google Mobile Ads SDK, при этом партнёры по demand подключаются на стороне сервера. Это значительно снижает техническую сложность.
Разнообразие demand
Header bidding через платформы вроде AppLovin MAX даёт вам доступ к широкому набору рекламных сетей, у каждой из которых свои отношения с рекламодателями и свой demand. Open bidding предоставляет доступ к demand Google плюс к участвующим биржам, но пул участвующих партнёров меньше того, что доступно через клиентский bidding. Оптимальный подход часто сочетает оба варианта.
Прозрачность
Клиентский header bidding даёт вам полную видимость ставки каждого партнёра в реальном времени. Вы можете точно видеть, сколько предложила каждая сеть, кто победил и почему. Open bidding предоставляет отчётность через GAM, но аукцион проходит на серверах Google, что делает детализацию в реальном времени немного менее подробной.
Что выбрать?
Честный ответ: большинство успешных издателей используют оба подхода. Вот практическая схема:
Используйте 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 может находиться на любом уровне этого стека, обеспечивая дополнительную конкуренцию, которая увеличивает общий yield независимо от используемого аукционного механизма.
Главное — не усложнять. Начните с open bidding через GAM, добавьте лучших партнёров bidding из вашей платформы mediation и работайте с управляемым партнёром, чтобы закрыть пробелы. Затем оптимизируйте на основе того, что говорят данные.