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

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

Статус: reviewed · Пререквизиты: Что такое AdTech и зачем он существует

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

Суть: роли, а не коробки

В первой главе мы увидели две экономические стороны рынка: advertiser1 создаёт demand2, а publisher3 — supply4. Между ними может быть много систем, но карта AdTech5 становится понятной, если смотреть не на названия компаний, а на роли — логические функции в рекламной сделке.

Role, company и product — разные уровни:

  • role — функция, которую здесь выполняют;
  • company — организация, с которой заключают договор; она может выполнять несколько ролей;
  • product — конкретное предложение компании: UI, API, managed service или набор инструментов.

Поэтому логотип нельзя навсегда поставить в одну клетку карты: один product suite может покупать media, продавать доступ к inventory6, доставлять рекламу и строить отчётность, а одну роль advertiser может распределить между собственной командой и несколькими providers.

Для разбора любой роли используйте одну карточку (role card):

Вопрос Что он проясняет
Какую проблему решает роль? Причина её существования
Кто customer? Кто использует продукт или услугу
Кто beneficiary? Кто получает экономическую пользу
Кто payer?7 Кто оплачивает media или сервис по договору
Какие данные входят и выходят? Технические границы функции
Какое решение принимается или исполняется? Реальная работа, а не marketing label
Как движутся деньги? Media money, отдельная fee или отсутствие платежа в этом flow

Customer, beneficiary и payer могут не совпадать: media buyer8 работает в UI платформы, пользу получает advertiser, а invoice оплачивает agency9. Без этого различия трудно читать договоры, data flows и отчёты.

Заполним карточку для главного экономического участника. Advertiser хочет изменить знание или поведение аудитории, финансирует campaign10, передаёт цель, бюджет и creative11 — сам рекламный материал: изображение, видео или текст — и получает outcomes и отчётность. Advertiser обычно является beneficiary и источником денег, но операционную работу и оплату конкретных счетов может делегировать agency. В конкретной campaign некоторых ролей не будет, а другие скроются за одним договором — поэтому карточка полезнее линейной схемы из семнадцати обязательных коробок.

Кто ставит цель и кто выполняет покупку

Advertiser — организация, которая финансирует рекламу ради business outcome. Для приложения с платной подпиской outcome может быть немедленным — trial или оплаченная подписка — либо более отложенным: знание продукта и готовность рассмотреть его позже. Advertiser определяет цель, допустимый spend, аудиторию и критерии успеха; сам или через подрядчиков решает, где покупать media.

Отсюда появляются две рекламные ориентации:

  • brand advertising12 в первую очередь меняет awareness, consideration или perception — знание, рассмотрение и отношение к продукту;
  • performance advertising13 управляется вокруг измеримого действия или outcome и стоимости его получения: регистрации, trial, установки или покупки.

Это не два взаимоисключающих вида компаний. Один subscription app может одновременно показывать video campaign для знакомства с брендом и acquisition campaign, оптимизированную на trial. Более того, один пользователь может сначала познакомиться с продуктом через brand-рекламу, а позже отреагировать на performance-рекламу. Различаются прежде всего цель, горизонт оценки и ожидаемые доказательства результата.

Publisher — организация, которая владеет или управляет media-средой, где возникают рекламные opportunities14: сайтом, приложением, игрой или видеосервисом. Publisher задаёт placements15 и правила показа, предоставляет контекст и доступ к inventory, получает сведения о delivery и зарабатывает publisher revenue16. Его интерес — продать opportunities достаточно выгодно, сохранив качество продукта и опыт user.

Между бизнес-целью advertiser и технической покупкой часто стоят люди и сервисные организации:

  • agency — компания-подрядчик, которая планирует или выполняет marketing- и media-работу от имени advertiser. Она может разрабатывать стратегию, готовить creatives, выбирать каналы, запускать campaigns, вести отчётность и иногда управлять платежами;
  • media buyer — человек, команда или функция, которая выбирает media, platforms и условия покупки, распределяет spend и настраивает campaigns. Media buyer может работать внутри advertiser, внутри agency или другой buying organization.

Agency и media buyer — не синонимы: первая является организацией и contractual role, второй — операционной функцией. Media buyer также не является DSP17: человек формулирует и настраивает решения, а DSP исполняет часть buying workflow в масштабе.

Роль Проблема и beneficiary Типичный payer Входные данные Решение или результат
Advertiser Достичь business outcome; пользу получает сам advertiser Источник media spend18 и многих service fees Бизнес-цель, ограничения, customer data Цель campaign, бюджет, критерии успеха
Publisher Монетизировать media environment; пользу получает publisher Обычно не payer в media sale; может платить technology providers Placements, контекст, inventory rules Доступные opportunities, delivery rules, publisher revenue
Agency Выполнить работу, для которой advertiser не строит команду или экспертизу Advertiser; иногда agency выступает плательщиком по downstream invoices Brief, бюджет, creatives, результаты План, настройки, execution и отчётность
Media buyer Превратить цель и бюджет в конкретные покупки Не отдельный payer как функция; оплачивается employer/client Campaign goals, доступные каналы, reports Выбор media и platforms, allocation и настройки

Advertiser может покупать media собственной командой (in-house), полностью передать покупку agency или разделить ответственность. От этого зависит граница контроля: кто имеет доступ к account, raw data и договору, кто отвечает за ошибки настройки и кто может перераспределить spend.

Кто соединяет demand и supply

Ни advertiser, ни publisher не могут вручную договариваться о каждом короткоживущем показе у тысяч контрагентов. Следующая группа ролей решает проблему масштаба, но делает это с разных сторон:

advertiser ───────────── direct buying ─────────────→ publisher
advertiser ───────────── ad network ────────────────→ publisher
advertiser / buyer → DSP ⇄ exchange / SSP functions → publisher

advertiser ad server и publisher ad server могут поддерживать разные ветви;
ни одна строка не является обязательным универсальным pipeline.

Ad network19 агрегирует supply и/или demand и продаёт управляемое media offering. Покупатель обычно выбирает доступное предложение, цель и ограничения, а network берёт на себя заметную часть распределения трафика и отношений с publishers. Ценовая ось принадлежит network: обычно она сама назначает цену покупателю и сама решает, у какого publisher и по какой цене взять показ, поэтому цена закупки для покупателя непрозрачна. Network обычно принимает media money и рассчитывается с supply partners; конкретная коммерческая модель зависит от договора.

DSP (Demand-Side Platform) — buying platform, которая помогает media buyer оценивать и покупать opportunities из нескольких supply sources по правилам campaigns. Customer — advertiser, agency или другой buyer. Ключевой признак: решение принимается по каждой поступающей opportunity отдельно и в реальном времени — в programmatic20 это ставка (bid21) в auction22; глубокое сравнение с network — глава 16, механика аукциона — глава 18.

SSP (Supply-Side Platform)23 — sell-side platform для publisher. Она описывает доступные opportunities, предоставляет demand sources доступ к inventory и помогает управлять его продажей. Publisher — основной customer и beneficiary, хотя SSP нередко получает свою оплату в рамках settlement24 media — фактического расчёта деньгами между участниками, в отличие от invoice как выставленного требования.

Ad exchange25 — transaction layer или функция, которая соединяет buyers и sellers и выполняет matching либо auction. Exchange не обязательно является отдельной компанией между DSP и SSP: exchange- и SSP-функции часто объединены в одном продукте. Полезное различие такое: SSP представляет sell-side workflow publisher, а exchange выполняет саму функцию автоматизированной сделки между сторонами.

Ad server26 выбирает, доставляет и регистрирует рекламу по заданным campaign- или inventory-правилам. Это не просто CDN с файлами: CDN может отдать bytes creative, а ad server применяет правила и создаёт наблюдаемую точку delivery.

  • Advertiser ad server помогает стороне buyer управлять creatives, их доставкой и регистрацией событий независимо от конкретного места покупки.
  • Publisher ad server сопоставляет доступные demand sources и управляет delivery на inventory publisher.

Подробные order, line item, приоритеты и serving mechanics появятся в главе 11.

Роль Основной customer Входные данные Решение или результат Денежная связь
Ad network Advertiser/agency; также нужны supply partners Campaign constraints, creatives, агрегированный supply Managed distribution и reporting Обычно principal27: назначает покупателю свою цену, принимает media money и сама рассчитывается с publishers по непрозрачной для покупателя цене
DSP Advertiser, agency, media buyer Campaign settings, creatives, opportunity signals Buying decision, доступ к supply, reports Платит buyer: media cost плюс platform fee, обычно процент от spend
SSP Publisher Inventory rules, opportunity и context signals Доступ к demand, sale decision metadata, reports Платит seller side: обычно удерживает долю (revenue share28) из clearing price (итоговой цены аукциона) до выплаты publisher
Ad exchange Buyers и sellers или их platforms Описания opportunities и buying responses Matching/transaction result Обычно доля из clearing price на sell side; если exchange объединён с SSP, это одно удержание, а не два
Ad server Advertiser или publisher Campaign/inventory rules, creatives, delivery signals Выбор, delivery и event registration Обычно отдельная license или usage fee от своего customer; media money через ad server обычно не проходит

Кто измеряет и проверяет

Платформа, продавшая или купившая media, видит только собственные measurement29 points и одновременно заинтересована в результате сделки. Поэтому advertiser и publisher могут подключать поперечные providers. Они не являются обязательным звеном коммерческой цепочки, хотя их код может исполняться внутри доставки creative: integrations получают события и возвращают отдельные выводы.

Attribution provider30 сопоставляет доступные рекламные touchpoints — например, impression31 или click32 — с outcomes вроде регистрации или покупки и применяет правила назначения credit. Результат отвечает на вопрос «какому источнику по выбранным правилам приписана эта conversion33?», а не «была ли реклама истинной причиной действия?» Attribution не доказывает causality.

MMP (Mobile Measurement Partner)34 — mobile-specialized категория measurement и attribution providers для app acquisition, installs и in-app outcomes. Основная роль — сопоставлять доступные acquisition signals с событиями приложения и давать advertiser согласованную картину по всем media sources. Мотив понятен: без независимой стороны каждая сеть сама приписывает себе установку по собственным правилам, и сумма self-reported installs как правило превышает реальное число; MMP применяет единые правила ко всем источникам. MMP не является синонимом product analytics: product analytics прежде всего изучает поведение внутри продукта, тогда как MMP связывает acquisition с рекламными источниками. Технические детали SDK, install matching, postbacks и platform privacy restrictions относятся к главам 27–29.

Verification provider35 создаёт отдельную точку оценки условий и качества доставки рекламы. В зависимости от интеграции он может анализировать доступные delivery, render, placement, context и quality signals и возвращать verification results рекламодателю, publisher или platform. Verification шире одной fraud detection — вопросы могут относиться и к среде показа, — но не абсолютная истина: полнота вывода зависит от среды, доступных signals и методологии.

Для одной рекламы приложения системы могут получить частично пересекающиеся события:

impression / click signals ─┬→ buying и selling platform reports
                            ├→ attribution provider / MMP
delivery / context signals ─┴→ verification provider

install / subscription events → MMP и systems advertiser, если интеграции это позволяют

Расхождения между отчётами — не обязательно ошибка. Platform reporting отвечает, что наблюдала сама platform; MMP применяет свои attribution rules к acquisition и app events; verification provider оценивает доступные ему условия delivery. Это разные вопросы и разные границы измерения.

Кто поставляет, организует и связывает данные

Слово data скрывает несколько разных задач. Поставка внешнего набора, управление audience segment36, хранение customer record и сопоставление identifiers не являются одной ролью. Отдельная операция — activation37: передача данных или сегмента в систему, которая применит их к реальным показам, например в buying platform для targeting38; до activation сегмент остаётся записью в хранилище.

Роль Customer и входные данные Хранимое состояние Результат и activation Чего роль сама по себе не делает
Data provider39 Advertiser, publisher или platform; собственные либо собранные datasets Dataset, attributes или segments Данные для разрешённых activation, decisioning или analysis Не обязана хранить customer record заказчика или принимать media decision
DMP40 Advertising/marketing team; audience data и campaign signals Audience profiles и segments в выбранной модели продукта Segmentation и activation через рекламные integrations Не обязана быть system of record для полного customer lifecycle
CDP41 Advertiser; first-party events и customer data из product, CRM и других systems Persistent unified customer record Доступные downstream systems customer profiles, events и segments Не обязана покупать media или назначать attribution credit
Identity provider42 Advertiser, publisher или platform; identifiers из разрешённых источников Mapping или identity graph в рамках конкретного решения Связанные или переведённые identifiers для activation и measurement Не создаёт consent, не регистрирует все events и не доказывает identity реального человека

Data provider продаёт или предоставляет datasets, attributes либо audience segments. Customer платит за дополнительный signal: например, классификацию контекста или audience attribute, который можно законно и технически использовать.

DMP (Data Management Platform) — advertising-oriented система для управления, сегментации и activation audience data. CDP (Customer Data Platform) отвечает за persistent unified customer record и доступность customer data downstream systems. Историческое правило «DMP — только cookies и anonymous data, CDP — только PII» ненадёжно: современные продукты и deployment models пересекаются. Рабочая граница проходит по главной задаче и record model — рекламная audience activation против устойчивого customer record.

Identity provider связывает или переводит identifiers для разрешённых activation, measurement и смежных use cases. Например, одна integration может знать customer ID advertiser, другая — platform-specific ID; identity function помогает установить допустимое соответствие.

Различайте четыре операции:

identity    → связывает пользователей, устройства или их identifiers
tracking    → регистрирует events
attribution → назначает conversion credit по правилам
consent     → выражает разрешение или выбор в отдельном governance/legal context

Identity provider не создаёт legal permission самим фактом matching. Конкретные identifiers, алгоритмы resolution и privacy rules будут разобраны в главах 24 и 40–42.

В running example subscription app отправляет first-party события trial и подписки в CDP, чтобы поддерживать customer record. DMP или platform integration может сформировать и активировать допустимый audience segment. Identity provider помогает связать необходимые identifiers между разрешёнными environments, а внешний data provider может обогатить segment дополнительным attribute.

Одна campaign: отдельно данные и деньги

Соберём роли на одном сценарии. Subscription app рекламируется внутри mobile game. Advertiser нанял agency; media buyer в agency запускает acquisition через DSP. Publisher игры предоставляет opportunity через SSP, в продукте которой также есть exchange function (в mobile in-app эту sell-side роль часто исполняет mediation platform или SDK network — глава 12). MMP измеряет mobile acquisition, verification provider опционально оценивает delivery, а data/identity functions подключаются только там, где они нужны и допустимы.

Это один возможный состав, а не обязательная цепочка: advertiser мог купить media напрямую или через ad network, а несколько ролей могли принадлежать одной компании либо отсутствовать.

Поток данных

advertiser / media buyer
  ── campaign goal, settings, creative metadata ──→ buying и serving systems

publisher app
  ── opportunity, placement, format, разрешённый context ──→ sell-side и decision systems

decision systems
  ── выбранная реклама + delivery metadata ──→ publisher app

publisher app и participating systems
  ── impression / click / delivery events ──→ reporting, MMP, verification

subscription app / advertiser backend
  ── install, trial, subscription events ──→ MMP, CDP и advertiser reporting

Не каждый участник получает каждое событие: набор зависит от integrations, среды, договора и privacy/platform restrictions. Event flow часто двунаправлен и asynchronous; он не обязан повторять ни путь creative, ни финансовые отношения.

Поток денег

Направление то же, что на карте главы 1: media spend advertiser идёт через канал покупки к продавцам media и образует publisher revenue, а technology providers получают отдельные fees. Новое здесь — кто именно и кому платит в типичном programmatic-составе:

Кто платит Кому За что Тип денег
Advertiser Agency Планирование и ведение campaigns Обычно fee или процент от spend; иногда внутри media invoice
Advertiser или agency DSP Купленные media и использование платформы Media cost плюс platform fee, обычно процент от spend
DSP Exchange / SSP Выигранные opportunities по clearing price Media money
Exchange / SSP Publisher Проданные opportunities Publisher payout43: clearing price минус sell-side revenue share
Advertiser MMP Attribution и измерение acquisition SaaS44 или usage fee
Advertiser Verification provider Оценка условий доставки Usage fee, обычно по объёму измеренных impressions
Publisher или advertiser Свой ad server Выбор, доставка и регистрация рекламы Usage или SaaS fee
Advertiser или agency Data provider Audience segments или attributes Часто data CPM45 — надбавка к media cost, начисляемая через DSP

Advertiser — экономический источник media spend, но contractual payer по invoice DSP нередко agency: advertiser видит один consolidated invoice, а деньги далее расходятся по нескольким договорам. Invoice и settlement тоже различаются: первый — выставленное требование, второй — фактический расчёт, и суммы могут не совпасть из-за adjustments. Удержания intermediaries46 на каждом шаге и путь условных $100 — тема главы 4.

Наконец, invoice path, реальный settlement path, путь доставки creative и HTTP/event path могут иметь разные endpoints: creative может прийти с ad server или CDN, а conversion event асинхронно уйти в MMP и не вернуться через SSP.

Почему одна компания занимает несколько мест на карте

Компании совмещают роли из-за acquisitions, общей инфраструктуры и data, желания предложить managed service, единый workflow, reporting и contract. Когда одна компания контролирует несколько последовательных уровней value chain, это называют vertical integration47 (вертикальная интеграция); в курсе мы также говорим о совмещении ролей.

Для customer совмещение ролей означает меньше integrations, ниже operational overhead, быстрее обмен данными и один UI для настройки и отчётов. Но те же свойства создают риски:

  • конфликт incentives, если одна сторона одновременно представляет buyer и seller;
  • непрозрачность границ fees и внутренних money transfers;
  • преимущество собственного supply или demand в decisioning;
  • self-measurement, когда исполнитель сделки сам оценивает её качество;
  • сложность выгрузки data и сравнения внешних alternatives.

Представим условную Platform X: она продаёт упакованный media package, даёт media buyer настройки в духе DSP, доставляет creatives и показывает attribution report в одном UI. Называть её только «DSP» недостаточно. Разложим suite на функции:

Функция Platform X Отдельная карточка роли
Упаковывает и продаёт доступ к media Ad network-like managed offering
Выбирает opportunities по campaign rules DSP-like buying/decisioning
Доставляет creative и регистрирует delivery Ad serving
Связывает touchpoints с outcomes Attribution/measurement

Общий login и общий invoice не делают эти функции одной ролью. Это и есть способ анализировать незнакомую AdTech-компанию: сначала перечислить выполняемые роли, затем заполнить для каждой problem → customer → payer → data in/out → decision → money и спросить, где возникает fee и с чьими интересами она может конфликтовать. Только после этого имеет смысл сравнивать vendors по labels.

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

  • «Brand advertiser и performance advertiser — разные виды компаний». Нет: это ориентации activity. Одна компания может вести обе.
  • «Ad network — старое название DSP». Network продаёт управляемую агрегацию media по своей цене; DSP оставляет решение по каждой opportunity правилам buyer. Реальные suites могут совмещать обе функции.
  • «SSP и exchange обязаны быть разными компаниями» или «это полные синонимы». Обе крайности неверны: sell-side workflow и transaction function различимы, но часто объединены в одном продукте.
  • «MMP знает истинную причину установки, а verification provider видит абсолютную истину показа». Оба работают с доступными measurement points и методологиями. Attribution credit не равен causality, verification result ограничен интеграцией.
  • «Data provider, DMP, CDP и identity provider — четыре названия базы пользователей». Они соответственно поставляют data, организуют audience activation, поддерживают customer record и связывают identifiers.

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

  1. Карта AdTech описывает логические роли, а не обязательный список компаний.
  2. Advertiser финансирует рекламу ради outcome; publisher создаёт media environment и opportunities.
  3. Brand и performance — ориентации целей и измерения, которые один advertiser может сочетать.
  4. Ad network продаёт media по своей цене; DSP решает по каждой opportunity ставкой по правилам buyer и берёт с buyer platform fee; SSP обслуживает sell-side workflow и обычно удерживает долю из clearing price; exchange выполняет transaction function.
  5. Advertiser-side и publisher-side ad servers применяют разные наборы правил, хотя обе роли выбирают, доставляют и регистрируют рекламу.
  6. MMP/attribution, verification, data и identity — поперечные функции, а не обязательные звенья коммерческой цепочки; они обычно получают fee за функцию, а не долю media money.
  7. Data flow, delivery path, invoice path и settlement path не обязаны совпадать.
  8. Одна company может выполнять несколько roles; vertical integration снижает integration friction, но создаёт вопросы о incentives, fees, границах данных и независимости measurement.

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

  1. Почему subscription app может одновременно быть brand- и performance-advertiser?
  2. Чем media buyer отличается от agency и DSP?
  3. Для чего publisher может использовать SSP и publisher ad server в одном flow, не считая их одной ролью?
  4. Вымышленный suite предлагает publishers SSP, publisher ad server и verification в одном UI по одному invoice. Какие отдельные role cards нужно заполнить и где у такого сочетания возникает конфликт интересов?

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

  1. IAB Tech Lab — Programmatic Auction Definitions
  2. UK Government — Online Advertising Programme consultation
  3. Competition and Markets Authority — Intermediation in open display advertising
  4. Adjust — What is a Mobile Measurement Partner
  5. IAB Tech Lab — Open Measurement SDK
  6. IAB Tech Lab — Identity Solutions Guidance and Recommended Practices
  7. CDP Institute — What is a CDP?
  8. Oracle Marketing Cloud — CDP vs CRM vs DMP

Footnotes

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

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

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

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

  5. 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. ↩

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

  7. Payee / payer — две стороны одного платёжного обязательства: payer платит за billable event, payee получает оплату. В pricing model распределение риска описывается через них: при CPM payee получает право на charge раньше воронки, а post-impression risk несёт payer; при CPA payee принимает на себя весь риск до конверсии. Одна компания может быть payee в одном договоре и payer в другом. ↩

  8. Media buyer — человек, команда или функция, которая выбирает media, platforms и условия покупки, распределяет spend и настраивает campaigns. Это операционная роль, а не организация: media buyer может работать внутри advertiser, внутри agency или другой buying organization. Не синоним agency (организация-подрядчик) и не синоним DSP: человек формулирует и настраивает решения, платформа исполняет часть buying workflow в масштабе. ↩

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

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

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

  12. Brand advertising (brand-реклама) — ориентация рекламы, которая в первую очередь меняет awareness, consideration или perception аудитории: знание, рассмотрение и отношение к продукту. Оценивается по отложенным показателям, а не по немедленному действию. Это ориентация, а не вид компании: один advertiser может сочетать brand- и performance-активность. ↩

  13. Performance advertising (performance-реклама) — ориентация рекламы, управляемая вокруг измеримого действия и стоимости его получения: регистрации, trial, установки, покупки. Оценивается через attribution и стоимость результата. Это ориентация, а не вид компании и не синоним «измеримой рекламы»: цель, горизонт оценки и ожидаемые доказательства результата отличаются от brand advertising. ↩

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

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

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

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

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

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

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

  21. Bid (ставка) — предложение buyer заплатить определённую цену за конкретную ad opportunity, обычно выраженное как CPM. Bid — это решение до события: он не равен итоговой цене (clearing price) и не равен billable amount; в programmatic bid формируется DSP на каждый bid request отдельно. ↩

  22. Auction (аукцион) — механизм выбора победителя среди нескольких bids на одну ad opportunity и определения цены (clearing price) по правилам аукциона — first-price, second-price и их варианты. Auction win — событие выбора победителя; оно не равно показу и не делает impression billable само по себе. ↩

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

  24. Settlement (расчёт) — фактическое движение денег между участниками по итогам периода, в отличие от invoice (выставленного требования) и от начисления. Одна сумма проходит три состояния: accrued — начислена по событиям, billed — выставлена в invoice или statement, settled — оплачена; на каждом шаге сумма может измениться из-за adjustments, fraud filtering, credits и FX. Для одной стороны это receivable (ожидаемое поступление), для другой — payable. ↩

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

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

  27. Principal / agent — accounting assessment роли reporting entity относительно конкретного обещанного specified good/service: principal контролирует его до передачи customer и показывает оплату gross, agent организует предоставление другой стороной и показывает net fee/commission. Control — способность направлять использование и получать существенные benefits до transfer; primary responsibility, inventory risk и pricing discretion — evidence, а не механический score; одна компания может быть principal в одном flow и agent в другом. ↩

  28. Revenue share — договорное распределение названной revenue или proceeds base между сторонами в заданной доле. Без раскрытия базы не определён: нужно знать, чьи proceeds, на какой ledger boundary, за какой период, до или после каких agreed adjustments и кто выполняет расчёт; доля от одной boundary не равна доле от исходного advertiser spend. ↩

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

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

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

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

  33. Conversion (конверсия) — valuable action или outcome, который advertiser определил как значимый (install, trial, первая оплата, renewal, purchase) и который система засчитала по measurement и attribution rules. Conversions нельзя складывать без явного counting rule: один click может привести к нескольким conversions. Observed conversion — зарегистрированное событие; attributed conversion — событие, которому attribution rule назначил credit; ни то ни другое не доказывает causality. ↩

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

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

  36. Audience segment — addressable set entities, membership которого задают named rule, data source/provenance, observation window и platform matching/activation contract; entity может быть user, account, device, browser, household или modeled profile, поэтому segment не обязательно является списком известных людей. ↩

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

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

  40. DMP (Data Management Platform) — advertising-oriented система для управления, сегментации и activation audience data: собирает campaign signals и внешние datasets, строит audience profiles и segments и активирует их через рекламные интеграции. Не обязана быть system of record для полного customer lifecycle. Историческое правило «DMP — только cookies и anonymous data» ненадёжно; рабочая граница с CDP проходит по главной задаче — рекламная audience activation против устойчивого customer record. ↩

  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. ↩

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

  43. Publisher payout (выплата publisher) — сумма, которую по договору продавца должны перечислить publisher после revenue share, fees и adjustments; для SSP или network это payable, для publisher — receivable. Payout — договорная и платёжная величина; какую часть и в каком периоде publisher признаёт выручкой, определяет его accounting policy (см. publisher revenue). ↩

  44. SaaS pricing — модель оплаты software-платформы: subscription, seats, usage tier или processed volume за доступ к продукту. Образует отдельный software/service flow: usage event платформы не становится media event автоматически, а SaaS charge не превращает отношение в покупку inventory. ↩

  45. CPM (Cost per Mille) — стоимость тысячи counted impressions для buyer: CPM = advertiser cost or spend / counted impressions × 1,000. Термин неоднозначен без контракта: может означать pricing basis, rate, bid или observed average CPM post-fact; observed CPM отвечает на вопрос «сколько buyer потратил на тысячу counted impressions». ↩

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

  47. Vertical integration (вертикальная интеграция) — ситуация, когда одна компания занимает несколько ролей цепочки (например, DSP, exchange и SSP, или ad network и MMP) и совмещает их в одном продукте или бренде. Даёт customer удобство и единый invoice, но создаёт конфликты интересов: компания одновременно представляет buyer и seller, сама себя измеряет или управляет аукционом, в котором участвует. Отраслевой термин для того, что в курсе также называется совмещением ролей. ↩