Чим відрізняється SDK і не-SDK трафік: розбір механіки рекламного запиту

TL;DR

• SDK – це технологічний шар, який власник застосунку інтегрує у продукт, щоб підключати рекламну інфраструктуру: demand-джерела, формати, монетизацію, події, вимірювання та технічну взаємодію з рекламною платформою.
• SDK і не-SDK трафік відрізняються не лише способом формування рекламного запиту, а й логікою підключення реклами, demand-джерел, форматів, вимірювання та монетизації.
• У web/browser-середовищі рекламний запит зазвичай формують код сторінки, теги або серверні інтеграції, а ідентифікація може спиратися на cookies, first-party data, контекстні та інші browser-based сигнали.
• У застосунку запит формує інтегрований SDK, який передає app-сигнали, події та (за наявності дозволу) advertising identifiers.
• В adtech SDK найчастіше пов’язують із in-app трафіком, бо він інтегрується всередину мобільних застосунків. Але цінність тут не в mobile-середовищі, а в стандартизації рекламної інфраструктури.
• Використання SDK не гарантує більшого обсягу даних, адже набір сигналів  визначає власник застосунку.

За даними DataReportal, на браузери припадає менш ніж 6% усього часу, який людина проводить зі смартфоном. Оскільки решта часу припадає на застосунки, відтепер саме вони стають каналами для цифрової реклами.

Натомість web- та in-app реклама відрізняються не лише місцем показу, а й способом підключення до рекламної інфраструктури. У вебі ця логіка частіше будується навколо сторінки, тегів і browser-based механік. У застосунках ключову роль відіграє SDK — інструмент, що стандартизує технічну взаємодію між застосунком і рекламною платформою. Власне про це ми сьогодні і поговоримо.

Що таке SDK у програматику

У сфері programmatic під SDK мають на увазі універсальний технологічний шар, який власник застосунку інтегрує у свій продукт, щоб підключити рекламну інфраструктуру всередині застосунку. Цей модуль дозволяє системі взаємодіяти з рекламною платформою за єдиними технічними правилами. Стандарт чітко визначає формат надсилання запитів на показ, регулює передачу даних про кліки чи перегляди, а також повністю описує механіку взаємодії між усіма учасниками процесу.

Як можна описати шлях рекламного запиту в програматику

У відкритому програматику запити зазвичай формуються за стандартом OpenRTB. Варто додати, що великі платформи мають власні розширення або ж зовсім окремі протоколи. У відеорекламі ще додатково працюють VAST і VPAID. Та в більшості випадків саме навколо OpenRTB побудована більшість аукціонів.

Різниця між сценаріями виникає саме на етапі аукціону. У вебі його зазвичай формує рекламний тег у коді сторінки, а у застосунку – SDK. Через різний рівень доступу до даних, ці запити містять різний набір сигналів.

Чому SDK найчастіше пов’язують із in-app

Насправді ж SDK існує як у застосунках, так і в вебі.

У programmatic SDK найчастіше асоціюють із мобільними застосунками, але сама логіка SDK ширша. Наприклад, рекламний код Google Ad Manager, який паблішер ставить на сайт, виконує ті ж самі функції. 

Web і mobile-реклама розвивалися по-різному

Причина такої різниці криється в еволюції окремих технологій. Веб продає рекламу з 1994 року, і перші п'ятнадцять років у нього взагалі не було єдиного протоколу. Паблішер і кожна окрема мережа домовлялись про інтеграцію власноруч, прописуючи код під кожен сайт індивідуально. Галузевий стандарт OpenRTB з'явився лише у 2010 році.

Оскільки готових автоматизованих правил довго не існувало, веб-реклама розвивалася за логікою класичної преси. На ринках на зразок України чи Туреччини все роками трималося на прямих контактах. Сайти продавали банери напряму брендам пакетами на тиждень чи місяць, бо технічно це було простіше, ніж налаштовувати складні зовнішні зв'язки.

З in-app сектором історія вийшла іншою. Коли mobile/in-app інвентар почав швидко зростати, власникам застосунків знадобився більш універсальний спосіб монетизації. Їм було важливо не будувати окремі прямі продажі під кожен ринок, а технологічно підключатися до ширшого пулу demand-джерел і масштабувати дохід. І, звісно, варто брати до уваги, що розвиток технологій на той час був зовсім інший, ніж на початку 2000-х. Саме тому мобільний ринок прийшов до SDK.

Як працюють аукціони у вебі та застосунках

Загальну схему ми вже прояснили, тепер розглянемо два способи окремо.

Як влаштований не-SDK трафік

Не-SDK трафік це рекламний трафік, який формується поза мобільним SDK, web/browser-середовищі. Сюди входить реклама на звичайних сайтах, у мобільному вебі та у відеоплеєрах на сторінках, тобто всюди, де запит збирає код самої сторінки. 

У вебі рекламний запит збирається прямо в браузері користувача, поки завантажується сторінка. Виходить, що частина роботи рекламної системи виконується на чужому пристрої, який паблішер не контролює, і результат залежить від того, який це браузер і які в ньому налаштування приватності.

Через обмеження браузерів веб середовище має менше стабільних сигналів для ідентифікації користувачів. Cookies залишаються одним із таких сигналів, але вони прив’язані до конкретного браузера й можуть блокуватися політиками приватності або навіть самими користувачами у випадку iOS. Більш детально як це працює ми розбирали в окремій статті про рекламні ідентифікатори.

Як влаштований SDK трафік

Шлях запиту починається всередині застосунку, як тільки звільняється рекламне місце. SDK ловить цю подію і розуміє, що настав час показати рекламу. Далі він звертається до рекламної платформи через стандартний набір функцій, кожна з яких відповідає за свою дію:

• запит креативу під конкретне рекламне місце,
• сповіщення про показ,
• сповіщення про клік,
• сигнал, що відео додивилися до кінця.

Розробнику не треба програмувати ці дії вручну: він викликає готову функцію і отримує передбачуваний результат. У більшості великих застосунків паблішер працює одночасно з десятком рекламних мереж, тому між SDK і покупцями стоїть проміжний шар, який називають медіацією. Він збирає пропозиції від різних мереж на кожен показ і віддає його тому, хто платить найбільше.

Окремо варто говорити про ідентифікацію. У застосунках можуть використовуватися advertising identifiers, зокрема IDFA (Identifier for Advertisers) на iOS або GAID (Google Advertising ID) на Android, але SDK сам по собі не гарантує доступ до цих ID. Коли SDK формує рекламний запит, доступність ідентифікатора залежить від операційної системи, consent-механік, privacy-політик, налаштувань користувача та конкретної реалізації SDK. Технічні деталі роботи бібліотеки описані в документації Google Mobile Ads SDK.

SDK та не-SDK трафік: ключові відмінності

Чому SDK не означає більше даних

SDK уміє передати дані, але не створює їх. Те, що реально піде в запит, залежить від двох речей: 

1. Які дані він взагалі має, бо невеликий застосунок знає про користувача куди менше, ніж велика платформа з мільйонами активних людей. 
2. Скільки з цих даних він погодиться віддати рекламним системам. Адже чимало видавців свідомо притримують частину, щоб не ділитися своєю  конкурентною перевагою.

Що буде передаватися через SDK, кожен власник вирішує окремо:

• рекламний ідентифікатор пристрою або відмова його віддавати,
• точна геолокація чи лише приблизний регіон,
• дані про поведінку в застосунку, наприклад які екрани відкривав користувач,
• технічні параметри пристрою і версія застосунку,
• сигнали про сесію, тобто як давно і як часто людина заходить.

Саме тому два застосунки з однаковим SDK можуть надсилати різний обсяг інформації. Один віддає майже все зі списку, інший обмежується ідентифікатором і парою технічних полів.

На що варто звернути увагу рекламодавцям

Уся технічна різниця в механіці залишається теорією до моменту запуску конкретної кампанії. У реальних кампаніях ці технічні відмінності найбільше впливають на три конкретні напрями роботи.

Ідентифікація користувача

У web/browser-середовищі ідентифікація часто спирається на cookies та інші browser-based сигнали, які можуть бути обмежені налаштуваннями браузера, очищенням даних або privacy-політиками. Через це виникають похибки навіть у простих завданнях, як-от обмеження повторних показів реклами одній людині. У застосунках можуть використовуватися app-сигнали та advertising identifiers, але їх доступність залежить від дозволів користувача, політик платформи й конкретної реалізації SDK. За наявності достатніх дозволених сигналів це може допомагати точніше контролювати частоту показів і якість контакту з аудиторією.

Геотаргетинг

Точність визначення локації повністю залежить від типу даних у конкретному середовищі.

• У вебі геотаргетинг зазвичай спирається на IP-адресу, тому точність може обмежуватися рівнем міста або регіону
• У застосунках за наявності дозволу від користувача можна отримати точніші координати пристрою, що особливо критично для локальних рекламних кампаній.

Фрод

Типові ризики відрізняються залежно від середовища: у вебі ахіллесова пʼята — це бот-мережі та підроблені домени, а в застосунках — фейкові інсталяції, емулятори пристроїв та маніпуляції із сигналами SDK.

Саме для цього й потрібна DSP на боці рекламодавця. Система Fusify щодня оцінює якість трафіку у вебі та мобільних застосунках. Дозволяє нам визначити особливості кожного джерела й допомогти брендам вигідно розподілити рекламний бюджет.

Які рекламні формати тяжіють до застосунків і чому

Кілька рекламних форматів традиційно вважаються орієнтованими саме на мобільні застосунки. Технічно більшість із них існує і у вебі, проте функціонують там значно гірше з кількох причин.

Такі формати органічно інтегровані в користувацький досвід та з'являються, коли користувач вже максимально сконцентрований на екрані пристрою.

Висновок

Жоден із типів трафіку не має абсолютної переваги, оскільки канали з підтримкою SDK та без неї ведуть до одного й того самого аукціону різними шляхами.

Головна цінність SDK полягає у прозорості та простоті взаємодії. Паблішеру він дає легкий спосіб підключити внутрішню рекламну інфраструктуру, а для DSP відкриває стандартизований доступ до тисяч застосунків через одне з'єднання. 

При цьому занурюватись у всю цю механіку самостійно вам не обовʼязково. Розібратися, який тип трафіку підходить під конкретну мету, налаштувати кампанію й проконтролювати якість розміщення це робота партнера, який працює з цим щодня. І саме таким партнером є ми. Fusify бере технічну частину на себе, щоб ви могли зосередитися на своєму бізнесі.

Якщо ви плануєте майбутнє розміщення та хочете визначити оптимальний тип трафіку для своїх цілей, пропонуємо обговорити деталі разом із нашою командою.