Header bidding (попередній аукціон, або торги за заголовком) вже довів, що є успішним варіантом монетизації для реклами в настільних і мобільних браузерах. З 2015 року ця технологія зміцнила індустрію programmatic, дозволивши паблішерам отримувати більше прибутку.
Ідея попереднього аукціону досить проста: усі біржі оголошень і джерела попиту змагаються за рекламні ресурси паблішера на аукціоні. Щоб реалізувати header bidding, паблішеру достатньо просто вставити код JavaScript у тег заголовка на будь-якій сторінці, звідки й походить назва методу.
Але як це працює в застосунках, і як цим можуть скористатися паблішери мобільних застосунків? У цій статті ми детально розкажемо про тонкощі header bidding в застосунках і пояснимо, як ця технологія трансформує ринок мобільної реклами.
Що таке header bidding в застосунках?
In-app header bidding, або торги за заголовком у застосунках — алгоритмічна рекламна технологія, яка використовується в мобільних застосунках. Попри назву, вона ніяк не стосується заголовків. Заголовки — термін, що стосується вебпереглядачів, і саме тому нам довелося так довго чекати, перш ніж з'явився якісний варіант header bidding для мобільних застосунків.
Оскільки в застосунках немає заголовка, в який можна вставити код JavaScript, у них використовуються комплекти для розробки ПЗ (software development kits, SDKs), щоб додати плагіни, необхідні для обміну інформацією з серверами. Такі комплекти — ключовий елемент алгоритмічної реклами, оскільки для header bidding потрібна комунікація з рекламними мережами.
Попри те, що механізми аукціону плюс-мінус такі самі, різниця полягає в тому, як саме технологія in-app header bidding організує процес аукціону. Технологія header bidding позбавляє необхідності використовувати в застосунку зайві SDK.
In-app header bidding проводить аукціон на стороні клієнта, тобто він проходить у застосунку на пристрої користувача. Це дозволяє проводити паралельні торги, коли кілька партнерів можуть одночасно робити ставки на рекламні ресурси в режимі реального часу.
Посилення конкуренції серед видавців сприяє вищим цінам ставок, що приносить користь паблішеру. Завдяки вищим рекламним ставкам паблішери отримують можливість більше заробити на своєму рекламному ресурсі.
Як працює in-app header bidding?
Технологія in-app header bidding працює за певною послідовністю дій, які уможливлюють ставки від кількох джерел попиту на рекламні ресурси в застосунку одночасно. Ось детальне пояснення цієї послідовності:
- Відкриття застосунку. Користувач відкриває мобільний застосунок на своєму пристрої.
- Запит на рекламне розміщення. Застосунок визначає доступні рекламні розміщення, де можуть відображатися оголошення (наприклад, банери, міжсторінкові оголошення, блоки нативної реклами).
- Інтеграція header bidding: Застосунок використовує пакет SDK (комплект для розробки ПЗ) для header bidding. Цей SDK полегшує процес торгів.
- Запит на аукціон на рекламні розміщення. Заміст того, щоб відправляти запит на рекламний простір на єдину рекламну мержу чи біржу, комплект SDK одночасно надсилає її різним партнерам (рекламним біржам, мережам, SSP).
- Аукціон у реальному часі. Партнери за попитом отримують запит на рекламний простір і починають брати участь в аукціоні в реальному часі.
- Визначення ставок і ціни. Кожен партнер оцінює доступний рекламний простір на основі таких чинників, як дані користувача, параметри таргетування, історія результативності і ціна ставки. Вони подають свої ставки до SDK.
- Вибір виграшної ставки. SDK збирає всі ставки та вибирає переможцем аукціону учасника, який запропонував найвищу ставку.
- Доставка рекламного матеріалу. Партнер-переможець доставляє рекламний матеріал до SDK.
- Рендеринг реклами. SDK візуалізує та відображає оголошення-переможець у призначеному рекламному розміщенні в застосунку.
- Взаємодія з користувачем. Користувач взаємодіє з показаним оголошенням (наприклад, натискає на нього).
- Звітування та відстеження: SDK відстежує та повідомляє дані про взаємодію користувача з рекламою (наприклад, кліки, перегляди) як власнику додатка, так і партнеру-переможцю.
- Розподіл доходу. Паблішер отримує дохід від переможної ставки, частина якого зазвичай також надходить рекламній мережі чи біржі.
Як бачимо, in-app header bidding забезпечує більш конкурентний і прозорий процес аукціону в порівнянні з традиційним методом «водоспаду» (waterfalling). Це дає змогу кільком джерелам попиту одночасно конкурувати за рекламні ресурси, що потенційно може призвести до підвищення CPM і збільшення доходу для паблішерів застосунків.
Переваги in-app header bidding
Ви вже знаєте, що таке торги за заголовком у застосунку, тож тепер ми можемо розібратися, які переваги використання цього підходу.
Технологія in-app header bidding працює на основі аукціонів першої ціни, тобто покупці розміщують ставки, які точно показують, наскільки цінним для них є кожен користувач. Аукціони першої ціни мають низку переваг:
- більше прозорості та стабільності роботи в процесі;
- можливість гнучкою та простої інтеграції нових партнерів зі сторони попиту;
- вищі ставки на інвентар паблішера;
- змагання в реальному часі.
Однак найбільша перевага — це усунення пріоритизації рекламних мереж, яке діє в методі «водоспаду». У випадку «водоспаду» ви надаєте перевагу рекламним мережам самостійно, або ж дозволяєте, щоб цей процес відбувався на основі історичних даних.
Завдяки in-app header bidding аукціон відбувається одночасно чи паралельно (об'єднаний аукціон). У всіх рекламних мереж (а не лише в пріоритетних) є шанс виграти розміщення, і ціна при цьому виходить цілком гідна.
Варто зазначити, що замінивши посередництво SDK на технологію in-app header bidding, ви значно зменшуєте кількість SDK, які вам потрібно встановити. Своєю чергою, це покращує взаємодію з користувачем, зменшує проблеми з затримкою і знижує потреби в обслуговуванні ПЗ.
Отже, підсумуймо переваги:
- Збільшення конкуренції. In-app header bidding дозволяє робити ставку на рекламний інвентар різним партнерам зі сторони попиту. Це посилює конкуренцію, що може підвищити CPM і збільшити доходи паблішерів.
- Вищий дохід. Завдяки активнішій конкуренції та заохоченню вищих ставок, паблішери часто спостерігають вищий дохід від реклами, порівняно з традиційним методом «водоспаду».
- Прийняття рішень у режимі реального часу. In-app header bidding відбувається в реальному часі, що дає паблішерам змогу відразу ж приймати рішення про те, яку рекламу показувати залежно від найвищої ставки.
- Прозорий процес аукціону. In-app header bidding забезпечує прозорість, оскільки всі партнери мають однакову видимість у процесі аукціону, формуючи чесну та відкриту конкуренцію за рекламний ресурс.
- Зменшена затримка. In-app header bidding зазвичай має нижчу затримку завантаження порівняно з традиційним «водоспадом». Це покращує взаємодію з користувачем, оскільки реклама завантажується швидше.
- Доступ до преміум-попит. Паблішери можуть налагодити зв'язок з широким колом преміум-партнерів, включаючи рекламні біржі, мережі та SSP, що дає їм доступ до високоякісної реклами та рекламодавців.
- Гнучка монетизація реклами. Паблішери мають можливість гнучко керувати рекламними ресурсами й оптимізувати їх відповідно до своїх конкретних цілей і стратегій монетизації.
Загалом in-app header bidding дає змогу паблішерам максимізувати дохід від реклами за допомогою створення конкурентного, прозорого аукціонного середовища, що зрештою приносить користь як паблішерам, так і рекламодавцям.
Торги у заголовку: застосунки vs. веб
У сфері алгоритмічної реклами header bidding і в застосунках, і в браузерах відіграють величезну роль в оптимізації доходу від реклами. Однак вони діють у різних середовищах, кожне зі своїми особливостями. Пропонуємо дослідити ключові відмінності між цими потужними методами проведення рекламних аукціонів.
| Аспект | In-app header bidding | Web header bidding |
|---|---|---|
| Середовище | Мобільні застосунки | Вебсайти |
| Аукціон у реальному часі | Так, на пристрої користувача | Так, у браузері |
| Розподіл ресурсів | Звільняє місцеві ресурси | Споживає місцеві ресурси |
| Досвід користувача | Швидше завантаження оголошень | Потенційно може вплинути на завантаження сторінки |
| Технічне виконання | Потрібна інтеграція SDK | Включає використання wrappers, або тегів |
| Оптимізація | Збільшує дохід від реклами для паблішерів мобільних застосунків | Оптимізує дохід від реклами для паблішерів вебсайтів |
| Складність інтеграції | Інтеграція SDK у програму може потребувати ресурсів розробників | Для інтеграції header bidding потрібні wrappers або теги в заголовку вебсайту |
Сам по собі процес попереднього аукціону досить подібний і для середовища в браузері, і для мобільних застосунків. Ключова відмінність полягає в технічній реалізації та конкретних використовуваних інструментах.
Під час торгів у вебзаголовках паблішер інтегрує код JavaScript (wrapper) у розділ заголовка вебсторінки. Цей код надсилає запити ставок партнерам зі сторони попиту, а процес аукціону відбувається у вебпереглядачі користувача. Такі wrappers керують кількома партнерами за попитом та спрощують процес реалізації.
А ось мобільний застосунок, як ми вже знаємо, використовує для комунікації з партнерами комплект SDK. За допомогою SDK надсилаються запити на ставки різним партнерам зі сторони попиту, і процес аукціону відбувається в межах застосунку на пристрої користувача.
Висновок. Хоча header bidding має ту саму мету і в браузерах, і в застосунках, ці технології працюють в різних середовищах, кожне зі своїми технічними особливостями. Вибір на користь того чи іншого залежить від платформи (мобільний застосунок чи сайт) і конкретних цілей паблішерів щодо оптимізації. Розуміючи відмінності між цими технологіями, паблішери можуть користуватися перевагами кожного з цих підходів, щоб посилити свої стратегії алгоритмічної реклами та максимально збільшити дохід від реклами.
Поточна ситуація з використанням технології
Спершу запровадження технології header bidding у мобільних застосунках просувалося повільно і дуже відставало від настільних і мобільних браузерів. Насамперед це було пов'язано з дещо складнішим процесом використання, оскільки для призначення ставок у мобільному застосунку потрібно скористатися SDK, а не просто вставити код JavaScript у заголовок сайту.
Проте до третього кварталу 2019 року популярність технології зросла, а витрати на header bidding у мобільних застосунках подвоїлися.
Хоча наведені вище статистичні дані враховують лише Північну Америку та Західну Європу, в Азійсько-Тихоокеанському регіоні витрати на header bidding у застосунках також зросли на 50%. Крім того, у всіх регіонах витрати на рекламу зросли до рекордних рівнів.
Згідно з прогнозами, витрати на алгоритмічну рекламу у США до 2024 року зростуть до 168 мільярдів доларів, можна впевнено очікувати, що й поширеність цієї технології в найближчому майбутньому зростатиме.
Параметри налаштування header bidding у мобільних застосунках
Щоб реалізувати header bidding у мобільному застосунку, можна скористатися двома варіантами:
- створити власне рішення з використанням відкритого коду;
- знайти партнера, який уже створив власне рішення.
Перший варіант передбачає розробку спеціального рішення для header bidding у вашому застосунку з використанням відкритого коду. Для цього потрібен високий рівень технічної експертизи та ресурсів, оскільки ви самі будете відповідати за розробку та підтримку функціонування цього рішення в межах власної компанії.
В іншому випадку паблішери можуть обрати співпрацю зі стороннім постачальником, який вже розробив власне рішення для header bidding у мобільному застосунку. Завдяки цьому варіанту паблішери можуть скористатися експертизою та технологіями досвідченого партнера.
Рішення про те, який обрати шлях, значною мірою залежить від технічного рівня вашої команди. Якщо насамперед ваша увага зосереджена на рекламі, а в команді наявні технічні ресурси, необхідні для розробки власної системи header bidding, може бути корисно витратити час і зусилля на розробку власного рішення.
Однак не в кожного паблішера є ресурси для розробки цілого середовища рекламних аукціонів. У такому разі паблішери можуть попрацювати з паблішером з готовим рішенням для header bidding у мобільному застосунку. Найкраще, якщо це рішення з відкритим кодом — наприклад, Prebid.org — оскільки такий варіант забезпечує найбільшу гнучкість і сумісність.
Такий партнер зможе надати всі функції header bidding у мобільних застосунках, на які є високий попит — динамічну оптимізацію мінімальних значень, кампанії з різною ефективністю та інтеграцію всіх ключових рекламних мереж.
| Критерії | Створення власного рішення | Партнер із наявним рішенням |
|---|---|---|
| Технічна експертиза | Необхідний високий рівень технічної експертизи | Для інтеграції необхідний середній технічний досвід |
| Час розробки | Розробка займає довший час | Скорочення терміну впровадження |
| Контроль налаштувань | Повний контроль над налаштуваннями та функціями | Обмежене налаштування на основі рішення партнера |
| Вкладення ресурсів | Вимагає значних внутрішніх ресурсів | Використання ресурсів зовнішнього партнера |
| Відповідальність за технічне обслуговування | За технічне обслуговування відповідає власна команда | Обслуговуванням та оновленнями займається партнер / постачальник |
| Витрати | Потенційно вищі початкові витрати на розробку | Може передбачати оплату за партнерство або виплату частини доходу |
| Ризик | Підвищений ризик технічних проблем і невдач | Нижчий ризик, оскільки рішення партнера перевірене |
| Час виходу на ринок | Довший час виходу на ринок через тривалість процесу розробки | Швидший час виходу на ринок при використанні існуючого рішення |
| Здатність до масштабування | Можна розробити відповідно до індивідуальних потреб масштабування | Залежить від того, яке масштабування передбачене в рішення партнера |
| Гнучкість в партнерах | Не прив’язаний до конкретного стороннього постачальника | Обмежено доступними партнерами та їхніми рішеннями |
| Внутрішня експертиза | Потрібна спеціальна команда з відповідними знаннями | Для інтеграції не потрібен настільки ж великий досвід у команди |
Бонус: Header bidding vs. об'єднаний аукціон
Що цікаво, саме технологія header bidding проклала шлях для використання об'єднаних (уніфікованих) аукціонів. Уніфіковані аукціони включають як прямі продажі розміщень, так і алгоритмічні запити, які змагаються в одному аукціоні за отримання показів.
На відміну від традиційних торгів у заголовках, керівництво уніфікованими аукціонами відбувається на стороні сервера, через що час завантаження виходить швидшим. За один показ відбувається лише один сеанс торгів, тобто ефективність максимальна. Google Exchange Bidding, тепер відомий як Open Bidding — приклад системи уніфікованих аукціонів, що працює на Google AdX.
Поширені запитання
Чи підходить in-app header bidding для всіх типів мобільних застосунків?
Так, in-app header bidding підходить для широкого спектру мобільних застосунків, зокрема ігрових, новинних, соцмереж та інших. Паблішери можуть реалізувати цю технологію в різних категоріях, якщо у їхнього застосунку є значна кількість користувачів і достатній обсяг показів реклами.
Чи є якісь потенційні недоліки або проблеми, пов’язані із застосуванням in-app header bidding?
Так, ця технологія дійсно може викликати певні труднощі. Її реалізація може включати потребу в технічній експертизі, довший термін розробки та інтеграцію кількох SDK. Крім того, паблішерам варто добре поміркувати, їм варто розробити власне рішення для використання in-app header bidding чи скористатися наявним постачальником, оскільки в обох варіантів є свої переваги й недоліки.
Як in-app header bidding сприяє підвищенню конкуренції та збільшенню CPM для паблішерів?
In-app header bidding підвищує конкуренцію та збільшує CPM для паблішерів, оскільки дозволяє різним джерелам попиту одночасно подавати ставки за рекламу. Це збільшує ефективність аукціону, підвищує попит і зрештою забезпечує паблішерам кращий CPM. Крім того, прозорість і режим реального часу, в якому проходять торги, створює більш конкурентне середовище, що спонукає більше попиту від рекламодавців, які прагнуть ефективно себе показати цільовій аудиторії.
Чи можуть паблішери використовувати in-app header bidding у поєднанні з іншими стратегіями монетизації реклами?
Так, цю технологію можна використовувати в поєднанні з іншими стратегіями монетизації реклами. Він може доповнювати такі методи, як рекламна медіація або «водоспад». Включивши до переліку стратегій in-app header bidding, паблішери можуть урізноманітнити потоки доходу та потенційно досягти вищої окупності свого рекламного ресурсу. Така гнучкість дозволяє паблішерам оптимізувати підхід до монетизації відповідно до конкретного застосунку та його аудиторії.
Які найкращі способи оптимізації налаштувань in-app header bidding?
Оптимізація налаштувань in-app header bidding включає такі найкращі практики:
- Запровадьте перевірку якості реклами перед поданням ставки. Переконайтеся, що реклама відповідає стандартам якості, перш ніж її відправити на аукціон, щоб користувачу було і далі приємно користуватися вашим застосунком.
- Використовуйте належні тайм-аути. Встановіть відповідні значення тайм-ауту, щоб запобігти затримкам доставки реклами, але при цьому надавати достатньо часу для обробки ставок.
- Призначте пріоритетність партнерів зі сторони попиту. Пріоритизуйте партнерів на основі ефективності в попередніх аукціонах та ставок, щоб максимізувати прибуток.
- Сегментуйте аудиторії. Налаштуйте параметри для різних сегментів користувачів, щоб показувати доречніше рекламу та підвищувати рівень активності користувачів.
- Регулярно відстежуйте та аналізуйте дані. Уважно стежте за показниками ефективності та відповідно змінюйте налаштування, щоб оптимізувати дохід.
- Перевіряйте та експериментуйте. Постійно тестуйте різні налаштування та конфігурації, щоб знайти варіанти, які найкраще працюють для певного застосунку та аудиторії.
Дотримуючись цих практик, паблішери можуть підвищувати ефективність реалізації торгів за заголовком у застосунку та максимально збільшити потенціал доходу.
Як паблішерам виміряти ефективність і вплив технології in-app header bidding на свій дохід від реклами?
Паблішери можуть виміряти ефективність цієї технології, аналізуючи ключові показники ефективності (KPI), зокрема:
- eCPM (ефективна ціна за тисячу показів): порівняйте ефективну ціну за тисячу показів, отриману за допомогою in-app header bidding, з іншими методами монетизації, щоб оцінити її вплив на дохід.
- Рівень заповнення. Оцініть відсоток запитів на рекламу, які заповнюються платними рекламними оголошеннями — це показує, наскільки ефективним є header bidding для монетизації доступного рекламного ресурсу.
- Час надання ставки. Відстежуйте, скільки часу потрібно партнерам зі сторони попиту, щоб подати на аукціон свої ставки, і перевірте, щоб цей час відповідав стандартам взаємодії з користувачем.
- Затримка реклами. Оцініть час, потрібний для завантаження реклами, оскільки тривалі затримки можуть негативно вплинути на взаємодію з користувачем і видимість реклами.
- Загальний дохід від реклами. Порівняйте загальний дохід, отриманий через header bidding, з доходом від інших методів монетизації, щоб оцінити його відносний внесок.
- A/B-тестування. Проводьте експерименти, порівнюючи ефективність header bidding з іншими налаштуваннями, щоб зрозуміти конкретний вплив цієї технології у вашому застосунку.
Аналізуючи ці показники, паблішери можуть отримати уявлення про те, як in-app header bidding впливає на їхні доходи від реклами, і приймати зважені рішення щодо подальшої оптимізації своєї стратегії заробітку.
Висновок
In-app header bidding являє собою значний прогрес у сфері реклами в мобільних застосунках. Хоча реалізація цієї технології вимагає технічної експертизи, її переваги не можна недооцінювати.
Як і у випадку з header bidding у заголовку браузера, in-app bidding створює більш відкриту та ефективну екосистему, яка приносить користь усім залученим сторонам. Обидва технічні рішення зменшують затримку реклами та дозволяють усім партнерам з мереж і бірж рівномірно призначати ставки на рекламні запити, забезпечуючи збільшення прибутку паблішера. Зважаючи на весь прогрес і покращення в алгоритмічній рекламі, причин відмовлятися від її впровадження в середовищі застосунків просто не залишилось.
