Что такое AdTech и зачем он существует

Суть

Digital advertising — оплачиваемая коммуникация, с помощью которой организация пытается повлиять на знание, отношение или действие аудитории в цифровой среде. Компания с приложением по подписке хочет найти потенциальных клиентов; владелец другого приложения хочет зарабатывать на своей аудитории; пользователь хочет получать контент или сервис и при этом сталкивается с рекламой.

AdTech — технологии, которые координируют этот обмен: помогают покупать и продавать рекламные возможности, выбирать подходящую рекламу, доставлять creative, измерять события, строить отчётность и проводить расчёты.

Ключевая mental model:

advertiser приносит demand: бюджет и намерение купить доступ к аудитории
publisher приносит supply: рекламные возможности в своей media-среде
AdTech координирует выбор, доставку, данные и расчёты между сторонами
user получает опыт использования продукта и сталкивается с рекламой

Это не один обязательный технический конвейер. Сделка может быть прямой, проходить через несколько платформ или целиком происходить внутри закрытой экосистемы. Один provider может совмещать несколько ролей, а некоторые специализированные системы подключаются только для measurement или контроля качества.

Реклама как рынок координации

У рынка есть три базовых участника.

Advertiser финансирует рекламу ради бизнес-результата (business outcome): например, установки приложения, покупки подписки или роста узнаваемости. Он покупает не человека, а возможность обратиться к аудитории в определённом контексте.
Publisher владеет или управляет средой, где возникает рекламная возможность: сайтом, мобильным приложением, видеосервисом, игрой. Реклама позволяет монетизировать эту среду.
User использует сайт, приложение или другой media-продукт. Его внимание делает рекламу осмысленной, но сам user не является inventory, обычно не продаёт рекламу и не участвует в оплате media.

На примере двух мобильных приложений:

Участник	Что вносит	Что хочет получить	Основное ограничение
Приложение с платной подпиской — advertiser	Бюджет, цель, `creative`	Привлечь пользователей, которые оформят подписку	Не тратить бюджет на неподходящие возможности
Контентное или игровое приложение — publisher	Media-среду и рекламные возможности	Получить revenue, не разрушив пользовательский опыт	Баланс монетизации, качества и нагрузки рекламы
Человек — user	Внимание, контекст использования и возможную реакцию	Контент или функцию приложения на приемлемых условиях	Релевантность, приватность, безопасность, отсутствие чрезмерной рекламы

Обмен ценностями не симметричен. Advertiser платит за media access; publisher получает рекламную выручку; user получает продукт и рекламный опыт, но одновременно несёт стоимость в виде времени, внимания и возможного использования данных. Поэтому эффективность для advertiser, revenue для publisher и качество опыта для user могут конфликтовать. Значительная часть AdTech нужна именно для управления этими конфликтующими целями в масштабе.

Supply, demand и advertising inventory

Demand — бюджеты и намерение advertiser купить подходящие рекламные возможности. Вокруг него находятся buy side или demand side: люди и системы, помогающие планировать и покупать media.

Supply — доступные рекламные возможности publisher. Вокруг него находятся sell side или supply side: люди и системы, помогающие описывать, продавать и доставлять рекламу.

Эти слова обозначают стороны рынка, а не конкретные технологии. DSP (Demand-Side Platform) относится к demand side не потому, что «создаёт demand», а потому, что действует в интересах покупателя. SSP (Supply-Side Platform) относится к supply side, потому что помогает publisher управлять продажей возможностей.

Предмет сделки — advertising inventory: множество доступных или прогнозируемых возможностей показать рекламу. Inventory ограничено средой, местом, форматом, временем, правилами publisher и допустимым контекстом аудитории. Оно не является списком пользователей и не означает, что будущие показы уже существуют на складе.

Полезно различать три уровня:

Placement или ad slot — заранее заданное место либо правило появления рекламы: например, полноэкранный блок после завершения уровня в игре.
Ad opportunity — конкретная возможность выбрать и показать рекламу, возникшая, когда user дошёл до этого места.
Impression — событие доставки или показа выбранной рекламы, зарегистрированное системой по определённому правилу.

placement существует в дизайне приложения
    ↓ user завершил уровень
возникла ad opportunity
    ↓ система выбрала creative
реклама доставлена и отображена; зарегистрирован impression

Даже последнее утверждение требует аккуратности. Served, rendered и viewable impression — разные состояния: отправка рекламы ещё не доказывает, что она отрисовалась и действительно попала в поле зрения человека. Точные определения и метрики появятся в главе 3.

От рыночной проблемы к технологиям

Без технологий advertiser пришлось бы отдельно договариваться с каждым publisher, вручную передавать материалы, согласовывать форматы и сводить несовместимые отчёты. Publisher пришлось бы искать покупателей для огромного числа короткоживущих возможностей. В цифровой среде одна opportunity может возникнуть и исчезнуть быстрее, чем человек успеет принять решение.

AdTech появляется там, где рынок требует повторяемого технического выполнения:

Рыночная проблема	Нужная функция	Типичные категории решений
Много advertisers и publishers	`Aggregation`: собрать спрос или предложение	DSP, ad network, SSP
Для каждой opportunity нужен подходящий buyer и creative	`Matching` и decisioning	DSP, ad network, ad server, publisher stack
Для решения часто остаётся мало времени	Автоматизированное выполнение	Buying/selling platforms, exchange
Creative должен дойти до нужной среды и формата	`Ad serving` и interoperability	Ad server, SDK, platform integrations
Стороны видят события из разных точек	Measurement и отчётность	Ad server, measurement providers; в mobile — MMP (Mobile Measurement Partner)
Показ может быть неподходящим или некачественным	Verification и risk controls	Verification provider, fraud/quality systems
Участникам нужно сверить объёмы и платежи	Сверка и расчёты	Reporting, billing и finance systems

MMP — специализированная категория providers для mobile measurement и attribution, а не синоним любой системы measurement.

Стандарты и общие протоколы уменьшают число попарных интеграций: сторонам проще согласованно описывать inventory, передавать решения и понимать цепочку продавцов. Один из примеров — RTB, где отдельная opportunity может выставляться на торги в реальном времени. Но RTB — лишь один механизм внутри programmatic, то есть автоматизированной покупки и продажи; programmatic — лишь часть AdTech. Direct deals, reserved buying и закрытые platform ecosystems тоже используют AdTech.

Зачем нужны посредники

Intermediary — участник, который соединяет стороны рынка или выполняет специализированную функцию. Посредники возникают не из-за потребности добавить больше компаний в цепочку, а из-за разделения задач:

agency управляет media-покупкой от имени advertiser;
demand-side provider агрегирует доступ к supply и выполняет выбор для advertiser;
sell-side provider агрегирует покупателей и помогает publisher продавать inventory;
связующий слой передаёт opportunities и решения между сторонами;
ad server управляет выбором и доставкой creative;
measurement и verification providers дают отдельную точку наблюдения;
data/identity providers помогают системам интерпретировать разрешённые сигналы и связывать данные.

Посредник оправдан, когда ценность от reach, aggregation, interoperability, скорости, measurement или контроля риска выше его стоимости и сложности. Но не каждый посредник нужен в каждой сделке. Publisher может продать часть inventory напрямую согласованному advertiser, а другую часть — сделать доступной многим buyers через платформы. Короткий путь не всегда лучше функционально, длинный — не всегда эффективнее. Оценивать нужно выполненную функцию, её стоимость, прозрачность и конфликт интересов.

Карта рекламной экосистемы

Следующая схема показывает логические роли и возможные пути, а не универсальный порядок HTTP-вызовов:

ПОКУПАЮЩАЯ СТОРОНА            СВЯЗУЮЩИЙ СЛОЙ               СТОРОНА PUBLISHER

Advertiser
   ├─ [Agency], [Advertiser ad server] — могут поддерживать любой путь покупки
   ├─ [Direct buying] ───────────────────────────────────────────────┐
   ├─ [Ad network] ─────────────────────────────────────────────────┤
   └─ [DSP] ⇄ [Ad exchange / связующий слой] ⇄ [SSP] ──────────────┤
                                                                    ├→ [Publisher ad server] → Publisher → User
                                                                    └→ Publisher → User (путь без publisher ad server)

Поперечные функции, подключённые к нескольким участникам:
[Measurement providers, включая mobile-категорию MMP]
[Verification]   [Data / identity providers]

Ветви показывают возможные пути, которые могут комбинироваться; квадратные скобки — логические роли, а не обязательно отдельные компании. В реальности:

одна компания может совмещать DSP, ad network, exchange, SSP или ad server;
SSP и publisher ad server могут участвовать в одном flow: SSP даёт доступ к programmatic demand, а publisher ad server сопоставляет этот и другие источники и управляет delivery; существуют и пути без одного из этих звеньев;
direct buying может миновать часть связующего слоя;
закрытая платформа может скрывать несколько ролей за одним API и одним коммерческим договором;
measurement, verification и identity обычно работают поперёк цепочки, а не «между» двумя обязательными соседями.

Категории на карте нужны пока только как навигация:

Категория	Где находится	Одна основная функция
Agency	Сторона advertiser (`buy side`)	Планирует и выполняет покупку media для advertiser
DSP	Сторона advertiser (`buy side`)	Автоматизирует покупку opportunities из нескольких supply sources
Ad network	Между buyers и publishers	Агрегирует и упаковывает supply/demand как управляемое предложение
Ad exchange	Связующий слой	Соединяет покупателей и продавцов для автоматизированной сделки
SSP	Сторона publisher (`sell side`)	Помогает publisher управлять доступом покупателей к inventory
Ad server	Сторона advertiser или publisher	Выбирает, доставляет и регистрирует рекламу по заданным правилам
Measurement provider; специализированная mobile-категория — MMP	Поперёк цепочки	Измеряет рекламные события и outcomes; MMP специализируется на mobile acquisition и attribution
Verification provider	Поперёк цепочки	Независимо оценивает качество и условия показа
Data / identity provider	Поперёк цепочки	Поставляет или связывает допустимые data signals для активации и measurement

Полные определения, разновидности и совмещение этих ролей — тема главы 2.

Три потока одной рекламной сделки

Главная ошибка при чтении карты экосистемы — представить, что creative, данные и деньги движутся по одной стрелке. Рассмотрим одну рекламу приложения с подпиской в контентном приложении publisher.

1. Поток показа и доставки

user открывает экран publisher app
    → publisher создаёт ad opportunity
    → доступные системы выбирают рекламу
    → выбранный creative или инструкция его загрузки возвращается в app
    → app загружает и render-ит creative
    → при выполнении отдельных условий показ может быть признан viewable;
      сам render этого не доказывает
    → user может заметить рекламу и взаимодействовать с ней

Поток начинается на стороне publisher, потому что именно там возникает opportunity. Решение может прийти из direct campaign, ad network, DSP/SSP path или закрытой платформы. Creative при этом может доставляться не тем же сервисом, который принял коммерческое решение: ad server или CDN часто участвует в delivery отдельно.

2. Поток данных

сторона advertiser:
цель + правила campaign + metadata creative
                         ↓
контекст publisher → системы выбора → выбранная реклама + metadata доставки
                         ↓
impression / click / outcome events → measurement + отчётность → оптимизация

Campaign — организованный набор рекламной активности с целью, бюджетом и creatives. До показа сторона advertiser сообщает системам условия этой активности. Когда возникает opportunity, сторона publisher может передать описание приложения или сайта, placement, формат, время и разрешённые правилами платформы сигналы контекста, устройства или аудитории. Системы выбора сопоставляют supply с demand и возвращают результат.

Системы связывают объекты и события identifiers вроде request_id, campaign_id и creative_id; конкретные поля и правила зависят от интеграции. После доставки разные участники могут отдельно зарегистрировать impression и click. Если user установит рекламируемое приложение и оформит подписку, outcome event может попасть в measurement systems — при наличии нужных интеграций и в пределах platform/privacy restrictions.

Этот обратный поток обычно асинхронен и не обязан идти по тому же network path, что запрос рекламы. У advertiser, publisher и посредников могут быть разные точки наблюдения, timestamps и правила подсчёта, поэтому их отчёты не обязаны совпадать идеально.

3. Поток денег

Media spend advertiser
    → канал покупки / продавец или продавцы media
    → revenue publisher

Отдельно, в зависимости от договоров:
advertiser или publisher → service / SaaS fee → technology provider

Media spend — деньги, выделенные advertiser на покупку рекламы. Часть проходит к продавцам media и в итоге образует publisher revenue; по пути могут взиматься fees. Но не каждый provider удерживает долю каждого рекламного платежа. Agency, ad server, MMP, verification или data provider могут получать отдельный service fee, SaaS fee либо иную договорную оплату. Некоторые участники только передают или измеряют события и вообще не принимают media money.

Поэтому три суммы нельзя считать синонимами:

advertiser spend — затраты покупателя;
intermediary fee — оплата конкретной посреднической или технологической функции;
publisher revenue — выручка продавца inventory.

Точные pricing models, margin и путь условных $100 разбираются в главе 4. Здесь важно направление: реклама и данные двигаются в обе стороны, а деньги в основном идут от advertiser к владельцам supply и поставщикам услуг.

Жизненный цикл рекламы: не линия, а цикл обратной связи

Рекламная работа начинается до первого impression и не заканчивается render-ом:

бизнес-цель
  → планирование и настройка
  → подготовка campaign и creative
  → доступ к media и выбор рекламы
  → доставка и render
  → реакция user и бизнес-результат
  → measurement и отчётность
  → оптимизация, сверка и расчёты
  ↺ следующая итерация планирования

Пройдём цикл для приложения с подпиской.

Бизнес-цель. Advertiser решает привлекать пользователей, которые с приемлемой экономикой оформляют подписку.
Планирование и настройка. Он определяет аудиторию, доступные каналы, бюджет и способ measurement. Здесь формируется demand.
Подготовка. Создаётся campaign и несколько creatives. Системы получают правила доставки и необходимые integrations.
Доступ к media и выбор рекламы. Publisher предоставляет opportunities напрямую или через sell-side systems. Buying systems находят подходящие opportunities и выбирают creative. Конкретная логика bidding, targeting и pacing появится в следующих главах.
Доставка и render. Creative доставляется в publisher app. Регистрируются события, соответствующие точкам наблюдения участников; render сам по себе не означает viewability или фактического внимания user.
Реакция и результат. User может проигнорировать рекламу, кликнуть, установить приложение и позже купить подписку. Наличие события ещё не доказывает причинное влияние рекламы.
Measurement и отчётность. Системы агрегируют наблюдаемые impressions, clicks и outcomes. Attribution и mobile measurement требуют отдельных механизмов и будут разобраны позже.
Оптимизация и расчёты. Advertiser перераспределяет будущий спрос на основании доступных сигналов; publisher меняет стратегию монетизации; участники сверяют отчёты и проводят расчёты.

Цикл обратной связи — причина, по которой AdTech является не только delivery infrastructure. Ценность возникает, когда наблюдения о прошлом меняют будущий выбор, но качество этого выбора ограничено полнотой данных, корректностью measurement и несовпадающими incentives сторон.

AdTech и MarTech: рабочая граница

MarTech — технологии для более широкого управления marketing и customer lifecycle: customer data, коммуникациями и собственными каналами advertiser. Граница не стандартизована, поэтому полезнее классифицировать систему по основной задаче, а не по ярлыку на сайте vendor.

Вопрос	AdTech	MarTech
Основной объект	Paid media и рекламная opportunity	Отношения с клиентом и маркетинговые операции
Главная координация	Между buying side и selling side	Внутри advertiser и его owned channels
Типичные каналы	Сайты и приложения publisher, ad platforms, media marketplaces	Email, CRM, push, собственный сайт или app, customer journeys
Типичные системы	DSP, SSP, ad network, exchange, ad server	CRM, marketing automation, CDP, email/push platforms
Основной результат	Купить, продать, выбрать, доставить и измерить рекламу	Управлять customer data и коммуникациями на протяжении lifecycle

Пересечение велико. Measurement, attribution, identity, CDP и activation могут обслуживать одновременно paid media и owned channels. Например, событие покупки подписки живёт в product/backend systems, может попасть в MarTech-процесс удержания клиента и одновременно стать outcome signal для AdTech measurement. Поэтому AdTech vs MarTech — рабочее правило, а не непроницаемая граница.

С чем это часто путают

«User и есть inventory». Нет. Inventory — рекламные opportunities в media-среде. User создаёт контекст и внимание, но остаётся отдельным участником со своими интересами и правами.
«Impression означает, что человек увидел рекламу». Не обязательно. Served, rendered и viewable описывают разные точки процесса, а viewability сама по себе не доказывает внимания человека.
«Каждый посредник перепродаёт media и удерживает долю spend». Нет. Некоторые получают отдельный service/SaaS fee, а некоторые вообще не участвуют в media money flow.
«Чем больше посредников, тем хуже». Дополнительные hops несут fees, latency и риск непрозрачности, но могут давать reach, aggregation, interoperability, measurement и quality controls. Вопрос — какую функцию выполняет каждый hop и сколько она стоит.
«AdTech = programmatic = RTB». Нет. RTB — один механизм programmatic; programmatic — часть AdTech; AdTech также поддерживает direct и closed-platform advertising.
«AdTech и MarTech строго разделены». Нет. Их основные задачи различаются, но data, identity, measurement и activation часто пересекаются.

Что важно запомнить

Digital advertising — рынок координации между advertiser, publisher и user, а не просто доставка баннера.
Advertiser создаёт demand, publisher создаёт supply; стороны рынка нельзя путать с названиями платформ.
Advertising inventory — доступные или прогнозируемые opportunities, не пользователи и не заранее произведённые impressions.
Placement, ad opportunity и impression — разные стадии: правило места, возникшая возможность и зарегистрированное событие.
AdTech существует из-за масштаба, фрагментации, скорости выбора, delivery, interoperability, measurement и расчётов.
Посредники выполняют функции; ни одна категория не обязана присутствовать в каждой сделке.
Поток показа, поток данных и поток денег различаются по направлению, участникам и времени.
Жизненный цикл рекламы образует цикл обратной связи: measurement прошлых событий влияет на будущий выбор и расходы.
AdTech в первую очередь координирует paid media, MarTech — customer lifecycle и owned channels, но между ними есть overlap.

Проверьте себя

Почему user — участник рекламного рынка, но не advertising inventory?
Чем placement отличается от ad opportunity и impression?
Для рекламы приложения по подписке нарисуйте отдельно поток creative, поток событий и поток денег. Какие стрелки не совпадут?
Какая функция посредника может оправдать дополнительный hop, и в каком случае этот hop окажется лишним?

Что такое AdTech и зачем он существует

Что такое AdTech и зачем он существует

Суть

Реклама как рынок координации

Supply, demand и advertising inventory

От рыночной проблемы к технологиям

Зачем нужны посредники

Карта рекламной экосистемы

Три потока одной рекламной сделки

1. Поток показа и доставки

2. Поток данных

3. Поток денег

Жизненный цикл рекламы: не линия, а цикл обратной связи

AdTech и MarTech: рабочая граница

С чем это часто путают

Что важно запомнить

Проверьте себя

Источники и дополнительное чтение