Часть I · Глава 1

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

Статус: reviewed

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

Суть

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

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

Ключевая mental model:

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

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

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

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

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

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

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

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

Supply, demand и advertising inventory

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

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

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

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

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

  1. Placement13 или ad slot — заранее заданное место либо правило появления рекламы: например, полноэкранный блок после завершения уровня в игре.
  2. Ad opportunity14 — конкретная возможность выбрать и показать рекламу, возникшая, когда user дошёл до этого места.
  3. Impression15 — событие доставки или показа выбранной рекламы, зарегистрированное системой по определённому правилу.
placement существует в дизайне приложения
    ↓ user завершил уровень
возникла ad opportunity
    ↓ система выбрала creative
реклама доставлена; зарегистрирован impression по правилу системы

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

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

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

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

Рыночная проблема Нужная функция Типичные категории решений
Много advertisers и publishers Aggregation: собрать спрос или предложение DSP, ad network19, SSP
Для каждой opportunity нужен подходящий buyer и creative Matching и decisioning DSP, ad network, ad server20, стек publisher
Для решения часто остаётся мало времени Автоматизированное выполнение Платформы покупки и продажи, exchange21
Creative должен дойти до нужной среды и формата Ad serving и interoperability Ad server, SDK, интеграции платформ
Стороны видят события из разных точек Measurement и отчётность Ad server, measurement providers; в mobile — MMP (Mobile Measurement Partner)22
Показ может быть неподходящим или некачественным Verification23 и risk controls: verification — независимая оценка условий показа, fraud detection — отдельная функция выявления невалидного трафика (главы 36–37) Verification provider, системы fraud detection и контроля качества
Участникам нужно сверить объёмы и платежи Сверка и расчёты Системы отчётности, биллинга и финансов

Стандарты и общие протоколы уменьшают число попарных интеграций: сторонам проще согласованно описывать inventory, передавать решения и понимать цепочку продавцов; например, ads.txt показывает покупателю, кто уполномочен продавать inventory данного publisher, а sellers.json — кто именно стоит за каждым продавцом и посредником в цепочке (глава 38). Один из примеров — RTB (real-time bidding)24, где отдельная opportunity может выставляться на торги в реальном времени. Но RTB — лишь один механизм внутри programmatic25, то есть автоматизированной покупки и продажи; programmatic — лишь часть AdTech. Direct deals, reserved buying и закрытые экосистемы платформ тоже используют AdTech.

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

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

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

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

Один publisher, два пути продажи. Игровое приложение продаёт полноэкранный блок после уровня напрямую согласованному advertiser: путь короткий, без посреднических fees, но со своей интеграцией, своей отчётностью и reach, ограниченным теми покупателями, с которыми publisher успел договориться. Оставшиеся opportunities того же блока оно открывает через SSP многим buyers: путь длиннее, платформа удерживает fee, но publisher получает aggregation спроса, автоматизированное выполнение и заполнение opportunities, которые иначе остались бы непроданными. Оба пути работают одновременно, и к каждому hop вопрос один: какую функцию он выполнил и оправдала ли она его стоимость?

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

Следующая схема показывает логические роли и возможные пути, а не универсальный порядок 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]
[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 и attribution31
Verification provider Поперёк цепочки Независимо оценивает качество и условия показа
Data / identity provider Поперёк цепочки Поставляет или связывает допустимые data signals для activation32 и measurement

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

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

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

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

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

В типичном случае поток начинается на стороне publisher, потому что именно там возникает opportunity. Решение может прийти из direct campaign33, 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 и click34. Если user установит рекламируемое приложение и оформит подписку, outcome event может попасть в системы measurement — при наличии нужных интеграций и в пределах platform/privacy restrictions.

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

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

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

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

Media spend35 — деньги, выделенные advertiser на покупку рекламы. Часть проходит к продавцам media и в итоге образует publisher revenue36; по пути могут взиматься fees. Но не каждый provider удерживает долю каждого рекламного платежа. Agency часто получает процент от media spend, иногда — fixed fee37; 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 и не заканчивается отрисовкой:

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

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

  1. Бизнес-цель. Advertiser решает привлекать пользователей, которые с приемлемой экономикой оформляют подписку.
  2. Планирование и настройка. Он определяет аудиторию, доступные каналы, бюджет и способ measurement. Здесь формируется demand.
  3. Подготовка. Создаётся campaign и несколько creatives. Системы получают правила доставки и необходимые интеграции.
  4. Доступ к media и выбор рекламы. Publisher предоставляет opportunities напрямую или через sell-side-системы. Системы покупки находят подходящие opportunities и выбирают creative. Конкретная логика bidding, targeting38 и pacing39 появится в следующих главах.
  5. Доставка и отрисовка. Creative доставляется в publisher app и отрисовывается; регистрируются события, соответствующие точкам наблюдения участников.
  6. Реакция и результат. User может проигнорировать рекламу, кликнуть, установить приложение и позже купить подписку. Наличие события ещё не доказывает причинное влияние рекламы.
  7. Measurement и отчётность. Системы агрегируют наблюдаемые impressions, clicks и outcomes. Attribution и mobile measurement требуют отдельных механизмов и будут разобраны позже.
  8. Оптимизация и расчёты. Advertiser перераспределяет будущий спрос на основании доступных сигналов; publisher меняет стратегию монетизации; участники сверяют отчёты и проводят расчёты.

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

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

MarTech40 — технологии для более широкого управления 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, CDP41, email/push platforms
Основной результат Купить, продать, выбрать, доставить и измерить рекламу Управлять customer data и коммуникациями на протяжении lifecycle

Пересечение велико. Measurement, attribution, identity, CDP и activation могут обслуживать одновременно paid media и owned channels. Например, событие покупки подписки живёт в продуктовых и backend-системах, может попасть в 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 строго разделены». Нет. AdTech в первую очередь координирует paid media, MarTech — customer lifecycle и owned channels, но data, identity, measurement и activation часто пересекаются.

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

  1. Digital advertising — рынок координации между advertiser, publisher и user, а не просто доставка баннера.
  2. Advertiser создаёт demand, publisher создаёт supply; стороны рынка нельзя путать с названиями платформ.
  3. Advertising inventory — доступные или прогнозируемые opportunities, не пользователи и не заранее произведённые impressions.
  4. Placement, ad opportunity и impression — разные стадии: правило места, возникшая возможность и зарегистрированное событие.
  5. AdTech существует из-за масштаба, фрагментации, скорости выбора, delivery, interoperability, measurement и расчётов.
  6. Посредники выполняют функции; ни одна категория не обязана присутствовать в каждой сделке.
  7. Поток показа, поток данных и поток денег различаются по направлению, участникам и времени.
  8. Жизненный цикл рекламы образует цикл обратной связи: measurement прошлых событий влияет на будущий выбор и расходы.

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

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

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

  1. IAB Tech Lab — OpenRTB
  2. IAB Tech Lab — Supply Chain & Foundations
  3. IAB Tech Lab — sellers.json and SupplyChain Object
  4. IAB Tech Lab — About ads.txt
  5. Competition and Markets Authority — Intermediation in open display advertising
  6. IAB UK — Demand Side Platform (DSP)

Footnotes

  1. Digital advertising — оплачиваемая коммуникация, с помощью которой advertiser пытается повлиять на знание, отношение или действие аудитории в цифровой среде. Это рынок координации между advertiser (demand), publisher (supply) и user, а не просто доставка баннера: ценности и цели сторон конфликтуют, и значительная часть AdTech существует для управления этими конфликтами. ↩

  2. AdTech (advertising technology) — совокупность технологий, которые координируют покупку, продажу, выбор, доставку, измерение и расчёты за рекламу между advertiser, publisher и посредниками: от ad server и DSP/SSP до measurement- и verification-систем. Programmatic — лишь часть AdTech: direct deals, reserved buying и закрытые платформы тоже работают на AdTech. С MarTech граница проводится по основной задаче: AdTech координирует paid media, MarTech — customer lifecycle. ↩

  3. Creative (креатив) — рекламный материал, который доставляется и показывается user: баннер, видео, нативный формат, playable. Наряду с правилами targeting является объектом доставки и должен соответствовать формату и правилам среды publisher; в кампании обычно готовят несколько creatives. ↩

  4. Measurement (измерение) — функция регистрации и агрегации рекламных событий (impressions, clicks, outcomes) для отчётности и оптимизации. Measurement-провайдеры дают независимую точку наблюдения; у разных участников разные timestamps и правила подсчёта, поэтому отчёты не обязаны совпадать идеально. В mobile выделенная категория — MMP. ↩

  5. Advertiser (рекламодатель) — участник рынка, который финансирует рекламу ради бизнес-результата: установок, покупок подписки, роста узнаваемости. Он покупает не человека, а возможность обратиться к аудитории в определённом контексте; создаёт demand и задаёт цели, бюджет и creative. ↩

  6. Publisher (издатель) — владелец или управляющий media-средой, где возникают рекламные возможности: сайт, мобильное приложение, видеосервис, игра. Монетизирует среду рекламой, создаёт supply и решает, какие placement, форматы и покупателей допускать, балансируя revenue с пользовательским опытом. ↩

  7. Advertising inventory (рекламный инвентарь) — множество доступных или прогнозируемых возможностей показать рекламу, ограниченное средой, местом, форматом, временем, правилами publisher и допустимым контекстом аудитории. Inventory — не список пользователей и не склад заранее произведённых показов: opportunity возникает и исчезает в момент использования продукта. ↩

  8. Revenue (выручка) — сумма, признанная выбранной entity по её правилам учёта на её ledger boundary. Estimated dashboard value, invoiced amount, settled amount и recognized revenue могут быть разными состояниями одной цепочки; для сравнения нужно согласовать period, timezone, currency conversion, taxes/refunds и participant. Сколько из прошедших через платформу денег она признаёт revenue, зависит от её роли principal или agent (gross/net presentation), а не от размера invoice. ↩

  9. Demand (спрос) — бюджеты и намерение advertiser купить подходящие рекламные возможности; сторона рынка, вокруг которой группируются buy side / demand side — люди и системы, помогающие планировать и покупать media (agency, DSP). Demand — это сторона рынка, а не конкретная технология: платформы нельзя путать со сторонами. ↩

  10. Supply (предложение) — доступные рекламные возможности publisher; сторона рынка, вокруг которой группируются sell side / supply side — люди и системы, помогающие описывать, продавать и доставлять рекламу (SSP, publisher ad server). Supply — это совокупность inventory на продажу, а не название платформы. Ad network агрегирует и supply, и demand, поэтому стоит между сторонами, а не внутри одной из них. ↩

  11. DSP (Demand-Side Platform, платформа стороны спроса) — платформа, которая автоматизирует покупку рекламных возможностей для advertiser: агрегирует доступ к нескольким supply-источникам, оценивает каждую opportunity и решает, делать ли ставку и сколько платить. Относится к demand side не потому, что «создаёт demand», а потому, что действует в интересах покупателя. ↩

  12. SSP (Supply-Side Platform, платформа стороны предложения) — платформа, которая помогает publisher управлять продажей inventory: задаёт правила доступа покупателей, подключает programmatic demand (DSP, exchange), проводит или передаёт аукцион. SSP- и exchange-функции часто объединены в одном продукте. ↩

  13. Placement (рекламное место или selectable media scope) — overloaded product term. На publisher side это заранее заданный ad slot или правило появления рекламы, которое порождает ad opportunities по мере использования продукта. На buy side placement может означать явно выбранную среду показа — site, app, channel, video, section или отдельный slot. Уровень сущности нужно уточнять из product contract. ↩

  14. Ad opportunity (рекламная возможность) — конкретная возможность выбрать и показать рекламу, возникшая, когда user дошёл до placement. Короткоживущее событие: в цифровой среде оно может исчезнуть быстрее, чем человек успеет принять решение, поэтому обрабатывается системами за миллисекунды, а в programmatic выставляется на торги как отдельная единица. ↩

  15. Impression (показ) — событие доставки или показа выбранной рекламы, зарегистрированное системой по определённому правилу; единица подсчёта, а не факт восприятия человеком. Served, rendered и viewable — разные состояния доставки, поэтому счётчики разных участников одной сделки могут не совпадать. ↩

  16. Served impression (отданный показ) — impression, засчитанный по факту того, что ad server или selling platform отдала creative (или ссылку на него) в ответ на запрос; доказывает отправку, но не загрузку, не отрисовку и не видимость. Самое раннее и самое крупное число в лестнице served → rendered → viewable. ↩

  17. Rendered impression (отрисованный показ) — impression, засчитанный после того, как creative загрузился и был отрисован на устройстве пользователя (обычно по сигналу от клиентского кода: pixel или SDK-событие после render). Доказывает отрисовку, но не то, что creative попал в видимую область экрана или был замечен; MRC-стандарт для display считает impression именно по факту загрузки/render на стороне клиента. ↩

  18. Viewable impression (видимый показ) — impression, выполнивший применимые geometry/time criteria viewability (классический MRC benchmark: не менее 50% пикселей creative на экране одну continuous second для display и две для video). Viewable означает standardized opportunity to see, а не внимание человека; non-viewable (measurement состоялся, criteria не выполнены) не равно non-measurable (статус определить не удалось). ↩

  19. Ad network (рекламная сеть) — посредник, который агрегирует рекламные возможности (inventory) от многих publisher и продаёт их advertiser как единый упакованный продукт: сеть берёт на себя подбор supply, ценообразование и показ, а покупатель получает одно управляемое предложение вместо десятка отдельных договоров. Цены внутри сети обычно непрозрачны для покупателя. Исторически многие ad network добавили аукционные механики и перестроились в ad exchange, поэтому под одним брендом часто совмещаются обе функции. ↩

  20. Ad server (рекламный сервер) — система, которая выбирает, доставляет и регистрирует рекламу по заданным правилам. Бывает publisher-стороны (сопоставляет прямые кампании, сети и programmatic-спрос, управляет delivery) и advertiser-стороны (хранит creative, считает показы и клики); термин обозначает функцию, а не сторону рынка. ↩

  21. Ad exchange (рекламная биржа) — transaction-слой, который соединяет покупателей и продавцов в автоматизированной сделке, обычно через аукцион в реальном времени (RTB). Отличие от ad network в прозрачности: покупатель видит описание отдельной opportunity и сам решает, сколько за неё платить, а цену определяет аукцион, а не прайс-лист сети. Exchange не обязательно отдельная компания между DSP и SSP: exchange- и SSP-функции часто объединены в одном продукте. ↩

  22. MMP (Mobile Measurement Partner, мобильный измерительный партнёр) — специализированная категория measurement-провайдеров для mobile: измеряет установки и in-app события, проводит attribution и предоставляет независимые данные сторонам сделки. Не синоним любой системы measurement. ↩

  23. Verification (верификация) — независимая оценка качества и условий показа: видимость, окружение, fraud, соответствие правилам. Verification-провайдеры подключаются поперёк цепочки и не участвуют в принятии коммерческого решения о сделке. ↩

  24. RTB (real-time bidding) — механизм programmatic-покупки, при котором отдельная рекламная возможность (opportunity) выставляется на автоматический аукцион и продаётся за доли секунды — пока страница или приложение ещё не показали рекламу. Покупатели отправляют ставки, как правило, через DSP; торги идут на ad exchange или внутри SSP с auction-функцией. RTB — не синоним programmatic и тем более AdTech: это один из механизмов автоматизированной покупки внутри более широкого стека. ↩

  25. Programmatic (программатик) — автоматизированная покупка и продажа рекламы: решение по каждой opportunity принимают системы, а не люди. RTB — лишь один из его механизмов; programmatic также включает автоматизированные reserved- и direct-механики без аукциона. Programmatic — часть AdTech, но не весь AdTech. ↩

  26. Intermediary (посредник) — участник, который соединяет стороны рынка или выполняет специализированную функцию: agency, DSP, ad network, exchange, SSP, ad server, measurement-, verification- и data-провайдеры. Оправдан, когда ценность его функции (reach, aggregation, interoperability, скорость, measurement, контроль риска) выше стоимости и сложности; не обязан присутствовать в каждой сделке и не обязательно удерживает долю media money — часть посредников получает отдельный service или SaaS fee. ↩

  27. Agency — компания-подрядчик, которая планирует и выполняет marketing- и media-работу от имени advertiser: разрабатывает стратегию, готовит creative, выбирает каналы, запускает campaign и ведёт отчётность. Advertiser может держать покупку media in-house, отдать её agency целиком или разделить ответственность. Agency — организация и договорная роль, в отличие от media buyer — операционной функции, которая может работать и внутри advertiser. ↩

  28. Data provider (поставщик данных) — провайдер, который продаёт или предоставляет datasets, attributes или готовые audience segments для targeting, measurement и enrichment. Работает параллельно цепочке покупки, а не «между» двумя обязательными соседями; за third-party segments обычно платит buyer — часто как data CPM, начисляемый через buying platform поверх media cost. Не путать с identity provider: тот не поставляет данные, а устанавливает соответствие identifiers. ↩

  29. Identity provider — провайдер, который связывает или переводит identifiers из разрешённых источников для activation, measurement и смежных use cases: например, сопоставляет customer ID advertiser с platform-specific ID. Не создаёт consent и не доказывает identity реального человека: matching в рамках одного решения не равен legal permission. Отличается от data provider задачей — не поставляет datasets, а устанавливает соответствие identifiers. ↩

  30. Reach (охват) — de-duplicated число unique entities (person, device, household, account или modeled audience), получивших хотя бы одну qualifying exposure за период, либо доля таких entities в явно заданной population: reach rate = reached unique entities / declared universe × 100%. Сравним только при одинаковых entity definition, exposure rule, population, de-dup scope и period. ↩

  31. Attribution (атрибуция) — правила, по которым доступные рекламные touchpoints (impression, click) сопоставляются с outcomes (установка, регистрация, покупка) и получают credit за конверсию. Attribution отвечает на вопрос «какому источнику по выбранным правилам приписано действие», а не «была ли реклама истинной причиной»: credit не доказывает causality. Провайдеры attribution — отдельная поперечная категория; в mobile — MMP. ↩

  32. Activation (активация) — передача данных или audience segment в систему, которая может их использовать для targeting, suppression, personalization или measurement: из CDP/DMP в DSP, из CRM advertiser в walled garden, из identity graph в SSP. До activation данные — запись в хранилище; после — правило, влияющее на реальные показы. Activation требует match identifiers между источником и принимающей платформой и разрешённого правового основания. ↩

  33. Campaign (рекламная кампания) — организованный набор рекламной активности advertiser с целью, бюджетом, правилами доставки и creatives. До показа её условия сообщаются системам покупки; объекты и события связываются identifiers вроде campaign_id. ↩

  34. Click (клик) — qualifying user-initiated interaction с рекламой, зарегистрированная по правилу конкретной системы. Даже одно действие имеет несколько measurement points: initiated, measured (click tracker), received (destination) и resolved (landing page) clicks не обязаны совпадать из-за обрывов соединения, redirect-цепочек и filters. ↩

  35. Media spend (рекламные расходы) — деньги, которые advertiser выделяет и тратит на покупку рекламы. Проходят через продавцов media и в итоге образуют publisher revenue, уменьшаясь по пути на fees; не синоним publisher revenue и не синоним intermediary fee — это разные суммы одной цепочки. ↩

  36. Publisher revenue (выручка publisher) — сумма, которую publisher признаёт выручкой по своим правилам учёта из медиаплатежей за своё inventory; в простом случае равна publisher payout, но признание (accrued / billed / settled) следует policy publisher, а не моменту платежа. Отличается от advertiser spend на сумму всех fees в цепочке; service- и SaaS-fee участников вне media money к ней не относятся. ↩

  37. Fixed fee — заранее согласованная сумма за period, scope или deliverable, не зависящая от объёма media transaction: agency retainer, setup или managed-service fee, minimum monthly commitment, flat sponsorship fee. Обычно это отдельный от media money поток: он не вычитается из media dollar и не становится publisher payout или take rate — если только конкретный договор не объединяет software и media charges в один invoice. Выбирают ради предсказуемости и чтобы снять конфликт «fee растёт вместе со spend»; provider несёт риск, что согласованный scope потребует больше работы. ↩

  38. Targeting (таргетинг) — правила кампании о том, кому и где может быть показана реклама: hard controls (eligibility rules — geo, device, context, audience/keyword criteria, exclusions), которые ограничивают множество допустимых opportunities, и signals/hints, которые в algorithmic products лишь направляют delivery, не сужая eligible set. Targeting отвечает на вопрос «для каких opportunities/users/contexts возможен показ», в отличие от placement («где именно») и optimization («какой из допустимых показов выбрать»); даже если API хранит их в одном объекте, это разные оси. ↩

  39. Pacing (темп расхода) — политика распределения spend во времени внутри budget-ограничений: тратить ли равномерно, ускоряться на дешёвых или качественных opportunities или придерживать бюджет. Pacing распределяет ресурс, но не обещает равномерный расход: доступные opportunities и allocation меняются. ↩

  40. MarTech (marketing technology) — технологии для более широкого управления marketing и customer lifecycle: customer data, коммуникациями и собственными каналами advertiser (CRM, marketing automation, CDP, email/push-платформы). Пересекается с AdTech в measurement, attribution, identity и activation, поэтому границу проводят по основной задаче системы, а не по ярлыку vendor. ↩

  41. CDP (Customer Data Platform) — система, которая собирает first-party события и customer data из product, CRM и других систем в persistent unified customer record и делает profiles, events и segments доступными downstream-системам. Не покупает media и не назначает attribution credit; относится к управлению customer lifecycle, что делает её частью MarTech. ↩