Пользователь открыл статью.
Через 127 миллисекунд его браузер отправил bid requests.

В нем — его IP, User Agent, хеш ID, URL страницы и строка согласия GDPR.
Этот JSON полетел в десяток DSP одновременно.

Через 86 мс один из них посчитал:
EV (expected value) = 0.45 CPM
Сформировал bid response с adm и nurl, вставил макрос ${AUCTION_PRICE

Еще 30 мс — аукцион на Exchange.
Ставки: 1.20, 0.95, 0.45.
Floor price: 0.80.
Победил не самый высокий — победил сбалансированный.

Через 290 мс после клика на страницу пользователь увидел баннер,
даже не заметив, что только что прошел аукцион.

А мы — заметили...

Спустя два года в Banner Stat я до сих пор не нашёл одного места, где было бы просто и по‑человечески объяснено, как работает программатик. Для выуживания хоть капли информации необходимо постоянно просматривать сухие PDF от IAB, десятиминутные слайды SSP, где каждый логотип — это «экосистема». А что на выходе? На выходе мы получаем только воду или сухие JSON с HTTP запросами. На просторах интернета просто нет материалов, которые рассматривают систему программатик комплексно.

Именно поэтому родился этот цикл. Здесь собрано все, что я узнал о рынке за несколько лет работы. Гайд дает подробное описание системы программатик рекламы, а также ключевых ее механизмов. Я постарался рассматривать все в технических деталях, во‑первых, чтобы это было полезно тех специалистам, работающим на рынке, во‑вторых только так можно понять, как реально программатик платформы общаются между собой. Однако цикл будет полезен и маркетологам, которые желают понимать, что именно происходит после того, как они запустили очередную кампанию в Яндекс Директ.

Для удобства восприятия и навигации весь материал поделен на три части:

1. Программатик: Часть 1 — Экосистема Кто есть кто: SSP, DSP, Ad Exchange, DMP и т.д Как они связаны, кто кому платит и за что, и почему между сайтом и рекламодателем оказалось 17 посредников.

2. Программатик: Часть 2 — Протоколы OpenRTB под капотом: из чего состоит bid request, что такое tmax, schain, ext.

3. Программатик: Часть 3 — Аукционы First‑price, second‑price, floor price, bid shading. Почему победил не тот, кто выше, и как цена определяется за 30 мс.

С выходом каждого нового материала тут будут появляться соответствующие ссылки на них.

Важно! Это не инструкция «как настроить Prebid». Это разбор того, что происходит между кликом и баннером.

Итак, сегодня в программе:

1. Введение

   1. Что такое программатик‑реклама

   2. Эволюция от прямых закупок к автоматизированным аукционам

   3. Место RTB в экосистеме рекламных технологий

2. Экосистема программатик‑рекламы

   1. SSP (Supply‑Side Platform)

   2. DSP (Demand‑Side Platform)

   3. Ad Exchange

   4. DMP (Data Management Platform)

   5. Cookie syncing и user ID matching

Введение

Что такое программатик-реклама

Для начала окунемся в терминологию.

Программатик‑реклама — это автоматизированный способ покупки и продажи цифровых рекламных показов (impressions) в режиме реального времени через мгновенный аукцион.

Impression (показ) — это конкретный момент, когда рекламное место (placement) на сайте или в приложении становится доступным для демонстрации пользователю. Программатик‑реклама позволяет в этот момент мгновенно продать и купить именно это рекламное место — то есть один показ.

Паблишер (publisher) — владелец или оператор сайта, приложения или другого цифрового носителя, который предоставляет рекламные площади (места) для размещения объявлений.

Покупать и продавать можно практически любую цифровую рекламу, основные виды введем сразу, так как далее будем разбирать материал на них:

• Display (баннерная реклама) — классические баннеры на сайтах

• Video (видеореклама) — ролики перед, во время или после видеоконтента (preroll, midleroll, postroll)

• Native (нативная реклама) — объявления, стилизованные под контент площадки

• In‑App (реклама в мобильных приложениях) — показы внутри мобильных приложений

• Connected TV (CTV) и Smart TV — реклама на телевизорах с доступом к интернету

• Digital Out‑of‑Home (DOOH) — цифровая реклама на уличных экранах и в общественных местах.

И да, программатик поддерживает даже аудиорекламу — цифровые голосовые блоки участвуют в аукционах!

Так терминов насыпали, свяжем их вместе. Ключевые элементы программатик‑рекламы — это impression (уже видели ранее), который продается по модели СPM (цена за тысячу показов) на площадке паблишера, где за эффективное донесение рекламного сообщения отвечает креатив, а точность показа обеспечивается с помощью таргетинга — набора правил, выбирающих именно нужную аудиторию.

Почему это полезно? Потому что программатик даёт рекламодателю точный контроль: можно покупать показы именно той аудитории, которая важна (а не весь инвентарь площадки целиком), быстро реагировать на результаты кампаний (увеличить ставку там, где хорошо конвертируется), и масштабировать кампании сразу на тысячи сайтов через несколько платформ. Владельцы площадок получают конкурентные торги за свои показы и, как правило, более высокий доход, чем при традиционных продажах по фиксированным прайс‑листам.

Важно понимать, что «программатик» — это не одна технология, это экосистема: платформы, протоколы и бизнес‑модели. Существуют разные способы закупки через программатик — от полностью автоматических мгновенных аукционов до заранее согласованных сделок (programmatic guaranteed, private marketplace). Мы позже подробно разберём эти варианты, а пока достаточно держать в голове: программатик — это автоматизация, скорость, таргетинг и масштаб.

Эволюция: от прямых закупок к автоматизированным аукционам

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

1. Ручные закупки
   История проста: сначала реклама продавалась вручную. Рекламные менеджеры заключали сделки по фиксированным показателям (например, X показов за Y рублей в неделю). Такой подход работал, когда интернет был маленьким и рекламных площадок было мало. Но с ростом интернета и появлением тысяч сайтов этот способ стал неэффективным — менеджеры физически не могли обрабатывать весь рынок, а рекламодателям требовалось охватить конкретные аудитории, а не просто «купить место на странице».

2. Ad networks
   Дальше появились ad networks — сети, которые агрегировали трафик множества мелких сайтов и продавали его рекламодателям. Это уже была промежуточная автоматизация, но внутри сетей всё ещё многое решалось централизованно, и прозрачности было мало.

3. RTB и Ad Exchanges
   Настоящий перелом принес RTB (Real‑Time Bidding) и Ad Exchanges. Концепция RTB простая и мощная: когда происходит возможность показа (пользователь загрузил страницу), система мгновенно (в миллисекунды) запускает аукцион, где покупатели делают ставки за право показать свой креатив этому конкретному пользовательскому сеансу. Это позволяет покупать «аудиторию по показу» — не заранее пакет мест, а конкретный показ под конкретного пользователя.

4. Header bidding и server2server интеграции
   Параллельно развивались технологии header bidding и server2server интеграции, которые сделали продажи ещё честнее и рынок более конкурентным: раньше у издателя был «водопад» (waterfall) — последовательность покупателей, которых спрашивали по очереди; header bidding же опрашивает многих покупателей одновременно, создавая настоящий рынок за каждый показ.

5. Развитие бизнес‑моделей
   Далее появились новые форматы сделок:

   • Programmatic Guaranteed — рекламодатель заранее бронирует объём инвентаря по согласованной цене, но с автоматической закупкой и доставкой через платформы.

   • Private Marketplaces (PMP) — закрытые аукционы с ограниченным кругом участников.

   • Гибридные модели, где часть трафика идёт через аукцион, а часть — по фиксированным сделкам.

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

Место RTB в экосистеме рекламных технологий

Чтобы понять, где находится RTB в общей схеме, представьте финансовую биржу: есть продавцы (площадки), покупатели (рекламодатели/агентства), и посредник — биржа, где проходят торги (это довольно условно, далее мы более точно расположим основные субъекты и их взаимосвязи) В рекламной экосистеме роль продавцов играют сайты, мобильные приложения, CTV‑каналы; роль покупателей — рекламодатели и рекламные агентства, которые используют DSP (Demand‑Side Platforms); а посредник — Ad Exchange. RTB (Real‑Time Bidding) — это процесс торгов на этой бирже, он реализуется через стандарты (например, OpenRTB), которые устанавливают, какую информацию передаёт каждая сторона и в каком формате.

Конкретнее, ключевые роли и как они взаимодействуют:

• Publisher (паблишер) — внедряет рекламные места и управляет инвентарём. Когда у него появляется возможность показа, он «звонит» в SSP

• SSP (Supply‑Side Platform) — агрегирует инвентарь паблишера и формирует bid request, рассылает его бирже/покупателям. SSP — это интерфейс продавца в системе

• Ad Exchange — центральная биржа, где собираются запросы и распределяются между DSP; здесь проводится аукцион

• DSP (Demand‑Side Platform) — со стороны покупателя: принимает запросы, сопоставляет их с целями рекламодателя (таргетинг, креативы, бюджеты), делает ставки и возвращает креатив в случае выигрыша

• DMP (Data Management Platform) и другие источники данные — помогают DSP «понять», насколько полезен этот конкретный показ (есть ли у пользователя нужные характеристики), и на основе этого строить ставку

RTB — это невидимая (для пользователя) оркестровка этих взаимодействий в реальном времени. Технически это выглядит так: SSP формирует JSON‑запрос (bid request) и за доли секунды получает ответы (bid responses) от нескольких DSP; Ad Exchange/SSP выбирает победителя по правилам аукциона и передаёт креатив в браузер/приложение пользователя для отображения.

Экосистема программатик-рекламы

SSP — Supply-Side Platform

Когда пользователь открывает страницу, первая система, которая вступает в игру — это SSP. (фактически это может быть не так, но для упрощения пока рассмотрим именно такой вариант). Она стоит на стыке паблишера и экосистемы программатика. Её задача — не просто «отправить запрос», а максимизировать выручку при минимальных потерях, в условиях жёстких ограничений по времени, нагрузке и прозрачности.

Технически SSP — это распределённый набор взаимосвязанных сервисов:

1. Frontend API / Publisher SDK — точка входа для паблишера. Принимает запросы от страницы (через тег, SDK или server‑side), валидирует их и передает в ядро.

2. Bidding Engine — главный «мозг». Обрабатывает тысячи bid requests в секунду, формирует OpenRTB‑запросы, маршрутизирует их в биржи и DSP.

3. Request Queue & Sharding — очередь запросов с шардированием по site.id, placement.id, geo, device.type. Нужна для балансировки нагрузки и предотвращения перегрузок.

4. Creative Cache & CDN — кеширует креативы (особенно VAST‑ролики), чтобы не гонять их по сети каждый раз при выигрыше.

5. Policy Engine — модуль, который проверяет: блок‑листы, категории, бренд‑сейфти, floor price, PMP‑правила, GDPR/consent.

6. Analytics & Reporting — realtime‑логика для сбора данных: fill rate, CPM, win rate, latency, deal performance.

7. Identity & Sync Module — управляет cookie sync, user ID mapping, server‑side identity resolution.

8. Ad Server Integration Layer — интерфейс с Google Ad Manager, Xandr, или другим ad server-ом для передачи результатов аукциона.

Мы немного узнали про компоненты SSP, теперь взглянем на их взаимодействие в жизненном цикле запроса. Представим, что пользователь открыл статью на Хабр, чтобы прогрузить правый рекламный блок произошла следующая цепочка действий:

• Запрос от браузера
  Браузер загружает тег SSP (например, через Prebid или прямой тег, подробнее об этом ниже). В запросе — placementId, pageUrl, referrer, device, userAgent, consent string.

• Валидация и нормализация
  SSP проверяет:

  • Корректность placementId

  • Домен (защита от domain spoofing)

  • Согласие (TCF string, GDPE/CCPA)

  • Формат (banner, video, native)

  • Уровень доверия (история по IP, User-Agent)

• Формирование bid requests (OpenRTB)
  На основе данных SSP конструирует JSON. Подробнее форматы json мы рассматриваем во второй части цикла. Сейчас лишь примерный набор полей:

{
  "id": "req-12345",
  "imp": [
    {
      "id": "imp-1",
      "banner": {
        "w": 300,
        "h": 250
      },
      "bidfloor": 0.80,
      "secure": 1
    }
  ],
  "site": {
    "domain": "example.com",
    "page": "[https://example.com/article](https://example.com/article)",
    "cat": ["IAB1-5"],
    "publisher": { "id": "pub-789" }
  },
  "device": {
    "ua": "Mozilla/5.0...",
    "ip": "94.25.123.45",
    "devicetype": 2,
    "language": "ru"
  },
  "user": {
    "buyeruid": "ssp_user_abc123",
    "ext": { "consent": "BOzZQY4OzZQY4ABABBENATEuABA" }
  },
  "tmax": 150,
  "source": {
    "tid": "header-bid-1",
    "ext": {
      "schain": {
        "ver": "1.0",
        "complete": 1,
        "nodes": [
          { "asi": "ssp.com", "sid": "pub-789", "rid": "req-12345", "hp": 1 }
        ]
      }
    }
  }
}

• Маршрутизация запроса
  SSP решает, куда отправить запрос:

  • В Ad Exchange (Google AdX, Xandr)

  • В несколько DSP напрямую (S2S)

  • В Predbid Server (для server‑side header bidding) Может использовать waterfall (каскад), parallel bidding, или hybrid

• Сбор ставок и аукцион
  SSP ждёт ответы в пределах tmax (обычно 100–300 мс)
  Ответы, пришедшие позже — отбрасываются.

• Определение победителя

  • Проверяет price против bidfloor (подробнее о ценообразовании ниже)

  • Учитывает PMP/PG‑сделки (они могут иметь приоритет)

  • Применяет quality adjustments (например, снижает вес ставки за плохой viewability)

  • Выбирает победителя

• Передача в ad server
  Результат (победивший adm, price, nurl) передаётся в Google Ad Manager как таргетинг‑ключ:
  hb_pb=1.20, hb_bidder=ssp_x, hb_adid=creative_999

• Отображение креатива
  Ad Server выбирает победителя между header‑bid и direct‑линиями, и рендерит баннер.

Мы кратко упомянули о том, что SSP может отослать bid requests трем разным клиентам: Ad Exchange, DSP, Prebid Server. Поговорим об этом подробнее.

1. Ad Exchange (Google AdX, Xandr, PubMatic, Magnite и др.) Централизованная биржа, где собирается множество DSP. Обычно используется для максимизации конкуренции. То есть не SSP обращается к нескольким DSP, а Ad Exchange.

2. Прямые S2S‑интеграции с DSP. Прямое подключение к DSP (например, The Trade Desk, Beesight, Criteo) через server‑to‑server API. Позволяет ускорить ответ и избежать лишних посредников.

3. Prebid Server (для server‑side header bidding). Серверный аукцион, где Prebid Server сам рассылает запросы своим bidder-ам (SSP, DSP) и возвращает лучшую ставку. Популярен у паблишеров, которые хотят контролировать аукцион и снизить нагрузку на клиент.

Выбор зависит от типа инвентаря, стратегии паблишера, ценовых ожиданий и исторической эффективности каждого партнёра. Вот основные подходы:

1. Open Auction (Waterfall) — устаревший, но ещё живой

• Запросы отправляются по очереди в порядке приоритета

• Сначала — высокодоходные SSP (например, Google AdX), потом — менее приоритетные

• Если первый не отвечает или ставка ниже floor — запрос идёт дальше

• Минусы: задержки, потеря конкуренции, низкий CPM

• Плюсы: полный контроль над приоритетами

Этот подход уступает место параллельным моделям, но ещё используется в legacy‑системах.

2. Parallel Bidding — конкуренция для максимизации CPM

• Запрос отправляется одновременно в несколько Ad Exchange и DSP

• Все участники видят одинаковые условия

• Победитель определяется по наивысшей ставке (или с учётом floor и quality)

• Плюсы: максимум конкуренции, высокий CPM

• Минусы: риск превысить tmax, если партнёры медленные

Это стандарт для modern header bidding и server‑side аукционов.

3. Hybrid (Waterfall + Parallel) — компромисс между контролем и эффективностью

• Некоторые партнёры подключены через параллельный аукцион (например, AdX, Prebid Server).

• Другие — через каскад как fallback.

• Пример:

  1. Параллельно: AdX + Prebid Server

  2. Если no‑fill: Xandr waterfall

  3. Если снова no‑fill: house ad

Позволяет сохранить высокий CPM, но не терять fill rate.

4. Deal‑based routing — приоритет для PMP/PG

• Если для placement есть активная PMP или PG‑сделка, запрос может сначала идти к участникам этой сделки

• Только если они не сделали ставку (или она ниже floor) — запускается open auction

• Это гарантирует выполнение контрактных обязательств

5. Latency‑based routing — выбор по скорости

• SSP ведёт статистику по p95 и p99 latency каждого партнёра.

• Партнёры с высокой задержкой (например, >200 мс) могут исключаться из маршрута или получать запросы позже.

• Это снижает риск потери ставок из‑за tmax.

6. Performance‑based routing — выбор по доходу

• SSP анализирует исторические данные:

  • Какой партнёр даёт самый высокий CPM по geo, device, format?

  • У кого лучший fill rate при заданном floor?

• На основе этого строится динамическая матрица приоритетов.

Так с маршрутизацией более менее разобрались (более подробно будем разбирать ниже) перейдем к ценам.

Управление ценой

Отдельного внимания заслуживает то, как SSP управляет ценой, так как фактически это одна из самых важных функций платформы. Конкретно сейчас нас интересует bidfloor или floor price — минимальная цена, по которой SSP готова принимать ставки от DSP (измеряется в CPM), устанавливается на уровне imp (конкретного рекламного слота). Если все ставки ниже — аукцион завершается с no‑fill, и реклама не показывается (или запускается fallback, например house ad). Выделяют 4-е вида основных floor price:

• Static floor — Фиксированная цена

• Dynamoc floor — Цена рассчитывается в реальном времени на основе исторических данных

• Per‑bidder floor — Разные цены для разных DSP (например, Google — 1.00, остальные — 0.80)

• Deal‑specific floor — Для PMP/PG сделок — своя цена, независимо от open auction

Выбор типа напрямую влияет на баланс между доходом и fill rate. Например, слишком высокий static floor может убить конкуренцию, а dynamic floor, построенный на слабой модели — искусственно занижать цену.

Еще одним важным моментом является поддержка разных типов аукционов или же моделей закупки. Появление нескольких типов вызвано необходимостью паблишеров работать с определенными агентствами, брендами и прямыми покупателями.

• Open Auction — Все DSP могут участвовать

• Private Marketplace (PMP) — Закрытый аукцион, только приглашенные

• Programmatic Guaranteed (PG) — Зарезервированный объем по фиксированной цене.

• Preferred Deal — Нет резервации, но приоритет и фиксированная цена.

PMP и PG могут перебивать open auction, даже если ставка ниже — это важно для выполнения контрактных обязательств.

Чтобы оценить, насколько хорошо работает SSP, используют ключевые метрики:

• QPS — сколько запросов в секунду.

• Fill Rate — процент запросов с победителем.

• Win Rate — как часто выигрывает конкретная DSP.

• CPM (eCPM) — средняя цена за 1000 показов.

• Latency (p95, p99) — время обработки.

• Deal Fill Rate — как часто заполняются PMP/PG‑сделки.

Эти метрики становятся основной для решений по оптимизации маршрутизации и партнерских интеграциях.

Итог: SSP — это распределённая система, которая принимает запросы от паблишера, маршрутизирует их в Ad Exchange, DSP или Prebid Server, управляет ценой и качеством, аукционирует ставки и передаёт победителя в ad server, балансируя между CPM, fill rate и задержками.

Переходим к следующему звену цепочки — DSP.

DSP — Demand-Side Platform

Если SSP представляет собой центр рекламного предложения, то DSP, напротив, ядро рекламного спроса. Основная цель DSP за доли секунды принимать решения о том, за какой показ, предложенный SSP, бороться и сколько за него платить. Как и SSP, DSP построена на микро‑сервисной архитектуре. Разберем подробнее.

1. Bid Request Processor — проводит валидацию входящих запросов, проверяет на соответствие OpenRTB‑стандарту и распределяет по обработчикам. Этот модель отсеивает до 30% некорректных запросов (например, с поддельными URL или несоответствующими форматами)

2. Identity Resolution Engine — сердце DSP. Здесь происходит сопоставление анонимных идентификаторов (cookie, mobile ID, hashed email) с профилями пользователей из DMP (о DMP поговорим в следующем блоке). Определяет, что один и тот же пользователь просматривал контент сначала на телефоне, а потом на ноутбуке, чтобы обеспечить сквозной таргетинг и избежать превышения лимитов показов. Сопоставление идентификаторов необходимо для персонализации рекламы, особенно в условиях ограничений браузеров и устройств (блокировка третих кук, App Tracking Transparency и т. д.)

3. Real‑Time Bidding Engine — мозг DSP. Здесь принимается решение о ставке. Работает с латентностью 10–30 мс и обрабатывает до 1 млн запросов в секунду на одном кластере. Фактически именно этот модуль принимает решение, участвовать в аукционе или нет. Тут происходит анализ параметров запроса (профиль пользователя, контекст площадки, ограничения рекламодателя, бюджетные стратегии) и рассчет оптимальной цены показа

4. Creative Management System (CMS) — организует хранение и управление рекламными креативами. Автоматически проверяет соответствие креативов техническим требованиям площадок и с помощью Dynamic Creative Optimization (DCO) формирует персонализированные варианты объявлений под конкретного пользователя или контекст

5. Budget & Pacing Controller — контролирует расход рекламного бюджета, фактически отвечает за равномерное расходование денег в течение кампании. Прогнозирует доступный трафик и динамически корректирует савки в RTB Engine, чтобы достигать максимальной эффективности и при этом не превышать лимиты бюджета

6. Fraud Detection Module — анализирует входящие запросы и поведение пользователей, выявляя аномалии, характерные для мошенничества (бот‑трафик, клик‑фрод)

7. Reporting & Analytics Pipeline — собирает данные о показах, кликах, конверсиях для последующей оптимизации.

Как и прежде, взглянем на жизненный цикл bid request и соединим все наши элементы:

• Прием запроса

  • Запрос приходит через S2S (server to server) соединение

  • Проверка подписи запроса (HMAC‑SHA256) для предотвращения спуфинга

  • Валидация OpenRTB‑схемы

• Идентификация пользователя

  • Сопоставление buyeruid (метка конкретного пользователя, может называться иначе, пример из спецификации OpenRTB) из запроса с внутренней базой

  • Если отсутствует, отправляется запрос к DMP

  • Для мобильных приложений проверяется IDFA/AAID и их соответствие сегментам

  • Пример: buyeruid: "dsp_user_7f3a2c" сопоставляется с сегментом «мужчины 25-34, интересуются технологиями»

• Контекстный анализ

  • Анализ URL через внутренний crawler (не только домен, но и конкретный контент). Crawler сам обходит страницы, чтобы отнести ее контент к определенной категории

  • Проверка на соответствие бренду (brand safety) с использованием NLP. Цель: не показывать рекламы рядом с нежелательным контентом

  • Пример: URL «habr.com/ru/post/123456» анализируется как технический контент, категория IAB1-5

  • Проверка на мошенничество: совпадает ли домен в site.domain с site.page?

• Таргетинг и сегментация

  • Сопоставление с активными кампаниями

  • Проверка frequency capping (сколько раз пользователь видел эту рекламу)

  • Пример: для кампании «ноутбуки Dell» проверяется:

    • Принадлежит ли пользователь сегменту «интересуется гаджетами»

    • Не превышен ли лимит показов (3 раза в сутки)

    • Соответствует ли гео (только Москва и СПб)

• Расчет ожидаемой ценности

  Здесь происходит основная «магия» DSP. Именно тут решается, участвовать ли в аукционе. Каждая DSP использует свою методологию расчета EV (expected value), здесь приведем лишь упрощенную формулу:

Где:

• — вероятность конверсии, рассчитанная моделью ML

• — целевая стоимость конверсии кампании

• — наценка

• — прогноз цены аукциона (на основе исторических данных)

• — вероятность победы при данной ставке

Пример:

• Вероятность конверсии для конкретного пользователя: 0.8%

• $50

• 1.3

• $1.1

• при ставке $1.2: 95%

— ставку делать безрассудно

При вероятности конверсии 2.5%:
 — делаем ставку $1.2

• Принятие решения о ставке

  • Для first‑price аукционов: bid = EV + buffer (небольшой запас, чтобы увеличить шанс победы)

  • Для second‑price аукционов: bid = прогнозируемая вторая цена × коэффициент (та же логика, увеличиваем шанс на победу)

  • Bid shading: если исторически победа наступает при ставке 85% от максимальной, DSP автоматически снижает ставку до этого уровня Пример для first‑price: EV + buffer = $1.20 → Исторически достаточно 85% → DSP снижает ставку: $1.20 × 0.85 = $1.02

• Формирование bid‑response

  • DSP подбирает подходящий креатив из CMS. Формирует HTML, JS, VAST

  • вставляются специальные макросы (позволяют отслеживать ставки и события на стороне площадки и DSP), которые SSP/Ad Exchange заменит на реальные значения при показе:

    • ${AUCTION_PRICE} — фактическая цена, по которой DSP выиграл аукцион;

    • ${AUCTION_ID} — уникальный идентификатор аукциона.

  • Добавление трекинг‑пикселей (win notice, impression, click)

  • Подпись ответа для предотвращения модификации (например, HMAC или цифровой подписью), чтобы SSP/Ad Exchange мог проверить, что код креатива не был изменён.

• Отправка ответа и логирование

На текущий момент мы поняли основное назначение DSP и ее функционал. Окунемся глубже в детали основных задач платформы.

Как DSP "понимает", что это не The Guardian

Самой основной задачей DSP является не слить деньги рекламодателя в трубу, а именно этого и пытается добиться domain spoofing. Мошенники регистрируют домен похожий на премиальный сайт, например, guardian-news.com. Размещают контент похожий на оригинальный, чтобы проходить контентный анализ DSP. Далее при запросе на аукцион через SSP указывают поддельный сайт, как премиальный, чтобы получить высокую ставку. Для валидации DSP используют пул механизмов:

1. SChain (Supply Chain) — проверка цепочки поставки в поле source.ext.schain (если в цепочке указан «guardian.com», но домен в site.domain — «fake‑guardian.ru», запрос отклоняется, к тому по всей цепочки проверяются подписи узлов)

2. Контентный анализ — если контент не соответствует основному домену, запрос отмечается спуфингом

3. Поведенческий анализ — сравнение патеронов поведения с эталонным для данного домена (если пользователь «The Guardian» обычно проводит 3+ минуты на статье, а здесь 5 секунд — спуфинг)

4. Базы известных мошенников — интеграции с IAB's ads.txt и sellers.json и проверка publisher ID против базы известных спуферов

Управление бюджетом и pacing: как DSP тратит деньги клиента

Управление бюджетом и pacing — одна из самых сложных задач DSP, поскольку рекламный бюджет должен расходоваться равномерно и эффективно в течение дня или всей кампании. Если потратить деньги слишком быстро, рекламные показы могут закончиться раньше пика аудитории; если слишком медленно — недостигается полный охват и упускаются возможности.

Pacing — это механизм, который отвечает за равномерное и оптимальное расходование рекламного бюджета в течение кампании или дня.

Чтобы контролировать расход, DSP строит прогноз трафика на основе исторических данных по часам. Это позволяет заранее определить, в какие часы ожидается пик активности пользователей, а когда трафик минимален. Например, пик может приходиться на вечерние часы с 18:00 до 22:00, а ночью с 3:00 до 6:00 активность минимальна. Эти прогнозы становятся основой для динамического управления ставками и распределения бюджета.

Сам процесс управления бюджетом реализуется через динамические алгоритмы pacing. Linear pacing просто равномерно распределяет бюджет во времени, а performance‑based pacing увеличивает ставки в часы с высокой конверсией, чтобы не упустить ценные показы. Adaptive pacing сочетает оба подхода: система учитывает фактический расход бюджета и динамику конверсий, корректируя ставки в реальном времени. Формула adaptive pacing учитывает оставшийся бюджет и оставшееся время кампании, а также соотношение целевого и текущего коэффициента конверсии, чтобы определить коэффициент корректировки ставок.

В реальной работе DSP постоянно перераспределяет ставки. Если к середине дня расходуется меньше бюджета, чем планировалось, ставки могут быть увеличены, чтобы успеть потратить деньги до конца периода. Если бюджет расходуется слишком быстро, система автоматически снижает ставки, чтобы сохранить его до конца дня.

Кроме того, DSP управляет бюджетом одновременно по сотням кампаний, перераспределяя средства в зависимости от ROI. Например, если одна кампания достигает целевого CPA быстрее и эффективнее, платформа может направить часть бюджета с менее эффективной кампании на более результативную, чтобы максимизировать общую отдачу от рекламных инвестиций.

DCO и работа с креативами

DSP не просто покупает показы, но и оптимизирует креативы в реальном времени через несколько механизмов:

1. Dynamic Creative Optimization (DCO)

   • Разделение креатива на компоненты: заголовок, изображение, CTA, предложение.

   • Персонализация на лету под профиль пользователя.

   • Пример: мужчины 25–34 видят технические характеристики, женщины 35–45 — акцент на удобство.

2. A/B тестирование в реальном времени

   • Одновременное тестирование до 16 вариантов.

   • Автоматическое увеличение доли показов лучших вариантов.

   • Пример: вариант B с CTR на 15% выше увеличивается с 50% до 70% показов.

3. Кросс‑девайсная персонализация

   • Пользователь видит разные креативы на разных устройствах.

   • Пример: на мобильном — короткий текст с большой кнопкой, на десктопе — подробные характеристики.

Отслеживание и атрибуция

После показа DSP продолжает контролировать эффективность рекламы и собирать данные для оптимизации:

• Post‑bid tracking:

  • Win notice — подтверждение победы в аукционе

  • Impression tracking — фиксация показов

  • Viewability measurement — определение видимости баннера

  • Click tracking — фиксация кликов

• Конверсионное отслеживание:

  • Пиксели на целевых страницах

  • S2S интеграции с CRM

  • Модели атрибуции (last click, linear, time decay)

• Оптимизация на основе данных:

  • Ежечасное обновление прогнозных моделей

  • Коррекция ставок по свежим данным о конверсиях

  • Пример: если в 14:00 конверсии упали на 20%, ставки автоматически увеличиваются на 15% для восстановления объема

Чтобы оценить, насколько хорошо работает SSP, используют ключевые метрики:

• Win Rate — доля выигранных аукционов

• CPM — средняя цена за 1000 показов

• eCPM — эффективная цена с учетом конверсий

• Viewability Rate — процент реально видимых показов

• Fill Rate — доля запросов, приведших к показу

• Bid Response Time — среднее время ответа (< tmax)

• ROAS — возврат на рекламные инвестиции

Итог: DSP — это платформа рекламного спроса, которая за миллисекунды решает, участвовать ли в аукционе и сколько платить за показ, сопоставляет пользователя с сегментами, борется с фродом, управляет бюджетом и персонализирует креативы для максимального ROI.

Дальше — Ad Exchange, где начинается реальная битва за каждый показ.

Ad Exchange

Ранее мы упоминали, что именно SSP проводит аукцион и это верно. SSP всегда проводит свой первый аукцион но это не всегда финал. На текущие момент насчитывается только 24 SSP и 66 DSP, и это только иностранные решения и абсолютные топы, которым подконтрольная большая часть европейского и американского рынка. Выходит, что для полного покрытия нам надо обеспечить архитектуру перцептрона между SSP и DSP, у которых разные протоколы. К тому же DMP системы используют разные DSP, то есть будут возникать проблемы с метчингом ids. Именно тут в игру вступает Ad Exchange — это централизованная биржа, которая выступает в роли универсального посредника, объединяющего множество продавцов (SSP) и покупателей (DSP) в едином ликвидном рынке.

Основными задачами Ad Exchange является:

1. Прием bid requests

2. Валидация и безопасность

   • Тот же спуфинг

   • Блокировка участников с плохой репутацией и высокой latency

   • Brand safety и интеграции с verification vendors

3. Распределение запросов

   • Маршрутизация запросов к DSP

   • Поддержка parallel bidding — все DSP видят одинаковый запрос одновременно

   • Поддержка deal‑based routing — приоритетные сделки (PMP/PG) проверяются первыми

4. Проведение аукциона (поддержка всех моделей, что и у SSP)

5. Передача bid response

6. Аналитика и оптимизация

   • Bid Request / Response logging: полный стек для последующего аудита.

   • Supply Path Optimization (SPO): анализ маршрутов поставки трафика, минимизация посредников.

   • Исторические метрики

   • Используется для оптимизации будущих аукционов, маршрутизации и рекомендации floor price

Жизненный цикл запроса через Ad Exchange

1. SSP отправляет bid request (JSON) на биржу.

2. Биржа проверяет request: корректность схемы, SChain, domain, floor price.

3. Запрос маршрутизируется к DSP (или нескольким DSP) в параллельном или deal‑приоритетном режиме.

4. DSP возвращают bid responses с adm, price, nurl.

5. Биржа применяет правила аукциона (floor, bid shading, quality adjustments).

6. Выбирается победитель. Если есть PMP/PG, они могут перебить open auction.

7. Победителю возвращается подтверждение победы и передается место для показа креатива.

8. Логируются все ставки, цены и параметры запроса для последующего анализа.

Я полагаю, что у читателя на текущий момент произошла путаница во взаимодействиях элементов в столь неочевидной архитектуре. Давай до перехода к DMP свяжем все элементы в единой целое. Самые типичные модели взаимодействия платформ представлены в таблице ниже.

Из таблицы мы сразу можем заметить, что обязательные платформы у нас везде SSP и DSP все остальные связующие опциональны.

Итог: Ad Exchange — централизованная биржа между SSP и DSP, обеспечивающая универсальную маршрутизацию, параллельные аукционы, приоритетные сделки (PMP/PG), защиту от фрода и прозрачную аналитику. SSP и DSP обязательны всегда, а Ad Exchange лишь упрощает взаимодействие и повышает ликвидность.

Переходим к следующей платформе — DMP, DMP, где данные превращаются в топливо для всей рекламной экосистемы.

DMP — Data Management Platform

DMP — система, которая собирает, обрабатывает и превращает данные о пользователях в рекламные аудитории. Без DMP DSP видит аудиторию, как набор разрозненных сигналов, единственное, что будет реализуемо это определение, что реклама показывается одному и тому же пользователю и дай бог кросс‑девайсный метчинг, но вся история с целевой аудиторией и таргетингом будет провалена, что лишит смысла весь программатик.

Сама DMP состоит из четырех взаимосвязанных слоев:

• Data Ingestion Layer DMP питается из десятков источников, которые условно делят на три группы:

  • First‑party data (данные самого рекламодателя): CRM — e‑mail, покупки, LTV, история заказов; Сайт и мобильные приложения — сессии, конверсии, поведенческие события; Оффлайн‑точки — данные с касс, программ лояльности.

  • Second‑party data (партнёрские): совместные кампании с другими брендами, обмен данными по согласованию.

  • Third‑party data (внешние сегменты): готовые поведенческие аудитории от Nielsen, Lotame, Oracle Data Cloud — «интересуется авто», «luxury‑покупатель», «молодые родители» и т. д.

Чтобы эти данные попали в DMP, используются разные каналы: API, SFTP/CSV (пакетная загрузка), Server‑to‑Server (S2S) (передача событий напрямую), пиксели (tag‑based ingestion) (сбор данных с паблишера).

• User Stitching Engine Главная ценность DMP — не просто собирать данные, а сопоставлять разные идентификаторы одного человека. Это называют user stitching или identity resolution. Здесь используются два метода:

  • Однозначное сопоставление (детерминированное): например, один и тот же хэшированный e‑mail найден и в CRM, и в логах сайта. Точность до 95–99%

  • Статистическое сопоставление (пробабилитическое): совпадают IP, User Agent, временная зона, поведение. Точность 70–85%

В результате создаётся единая карта пользователя:

{
"user_id": "dmp_7f3a2c",   
"ids": [     
	 {"type": "cookie", "value": "a1b2c3"},     
	 {"type": "idfa", "value": "x9y8z7"},     
	 {"type": "email_hash", "value": "abc123"}  
],   
"segments": [
	"tech_enthusiast", "laptop_shopper", "moscow"
]
}

• Segmentation Engine После того как DMP собрала и склеила идентификаторы, начинается магия сегментации. Платформа позволяет строить аудитории на основе:

  • Правил («если посетил страницу ноутбуков 2+ раза — добавь в сегмент»)

  • Моделей машинного обучения (предсказание интереса к продукту)

  • Жизненного цикла («новый», «возвращающийся», «рискует уйти»)

Примерами сегментов могут выступать: «Покупатели за последние 30 дней» (CRM‑данные); «Посетили страницу ноутбуков 2+ раза» (поведенческие); «Мужчины 25–34» (демография через поведенческий анализ); «Похожие на лучших клиентов» (look‑alike сегменты).

• Activation Layer Сегменты DMP не висят мёртвым грузом — они отправляются в рабочие каналы:

  • DSP — показываем рекламу только тем, кто ищет ноутбуки

  • SSP — паблишеры продают премиальный инвентарь по сегментам

  • E‑mail/CRM‑системы — отправляем скидку только тем, кто добавил товар в корзину.

  • Look‑alike expansion — ищем 100 000 пользователей, похожих на уже купивших.

Жизненный цикл данных в DMP

Чтобы увидеть, как всё это работает вместе:

1. Пользователь зашёл на сайт → пиксель DMP отправил URL, IP, User Agent

2. DMP обогащает данные: добавляет гео по IP, девайс по User Agent, контекст страницы

3. Если есть совпадение с CRM (e‑mail, покупка) → профиль обновляется. Если нет → создаётся новый

4. Пользователь попадает в сегмент «ищет ноутбук»

5. Сегмент через API отправляется в DSP The Trade Desk → реклама показывается только этим пользователям

6. Пользователь купил ноутбук → его убирают из сегмента «ищет ноутбук» и добавляют в «новые владельцы»

DMP и борьба с фродом

DMP — это не только про таргетинг, но и про защиту инвентаря:

• Bot detection — выявление нереалистичных сессий, подозрительных User Agent.

• Domain spoofing protection — проверка, что «читатель The Guardian» не появился внезапно на «fake‑guardian.ru».

• Invalid Traffic filtering — интеграции с IAS, DoubleVerify, Moat.

DMP изначально решали задачу: собрать крошки данных о пользователях из разных источников, склеить их в сегменты и передать в DSP для таргетинга. Эти платформы были заточены под анонимные ID и cookie, а значит, жили короткими циклами — профиль пользователя мог исчезнуть через пару дней после того, как cookie истекла. Для медийных закупок это работало отлично, но для долгосрочной работы с клиентами — уже нет.

Ситуация изменилась: браузеры режут third‑party cookies, Apple закрыла идентификаторы iOS, пользователи требуют прозрачности и контроля над своими данными. В такой среде классическая DMP начала терять актуальность: её данные быстро старели, а анонимные сегменты не позволяли строить персонализированные цепочки коммуникаций.

Здесь на сцену выходит CDP. Если DMP — это «специалист по таргетингу на аукционе», то CDP — это «директор по клиентскому опыту».

• DMP строит краткоживущие сегменты на базе cookie и MAID.

• CDP собирает first‑party данные и формирует долгоживущие клиентские профили.

• DMP ориентирована на рекламные аукционы.

• CDP охватывает весь маркетинг: e‑mail, push, соцсети, call‑центр.

По сути, бренды двигаются от работы с обезличенными ID к работе с реальными людьми, где реклама — лишь один из каналов взаимодействия. CDP стала естественным развитием DMP: всё то же ETL, та же логика identity resolution, но с упором на собственные данные компании, на их долговременное хранение и использование.

Главное отличие от DMP: CDP всегда работает с first‑party данными, с реальными клиентами, а не с анонимными сегментами.

• Data Ingestion Layer — что CDP собирает:

  • CRM и офлайн‑точки — e‑mail, телефон, покупки в магазинах, LTV.

  • Сайт и приложения — клики, корзины, отказы, сессии, воронки.

  • Службы поддержки и колл‑центры — обращения, жалобы, тикеты.

  • E‑mail и SMS‑платформы — реакция на кампании (open, click).

  • Программы лояльности — баллы, уровни, история транзакций.

• Identity Resolution — как CDP склеивает клиента Если DMP строит анонимные профили (cookie, IDFA), то CDP строит персональные профили:

  • Детерминированные ID — e‑mail, телефон, loyalty ID.

  • Пробабилитические связи — если один человек использует мобильное приложение и сайт, CDP связывает профили по IP, UA, времени входа.

В итоге получается единый Golden Record (Single Customer View):

{   
"customer_id": "c_54783",   
"name": "Анна Петрова",   
"email": "anna@example.com",   
"loyalty_level": "Gold",   
"recent_activity": ["added_to_cart", "chat_with_support"],   "predicted_churn_risk": 0.78 
}

• Segmentation & Insights — зачем нужны эти профили

  • строить сегменты «живых клиентов» — не просто «женщины 25–34», а «купили 2 раза за последние 3 месяца и открывали e‑mail‑рассылку»

  • прогнозировать churn и LTV

  • запускать персональные сценарии в реальном времени — «бросил корзину → пуш с промокодом через 10 минут».

• Activation — где CDP приносит деньги

CDP подключается напрямую к каналам:

• E‑mail и SMS — персональные триггеры.

• Push и In‑app — нативные уведомления.

• DSP и соцсети — таргет только на реальных клиентов, синхронизированных по хэшированным e‑mail или UID.

• Колл‑центр — операторы видят всю историю клиента до звонка.

DMP vs CDP — в чём разница

• DMP — анонимные профили, покупка рекламы, сегменты живут днями.

• CDP — реальные клиенты, омниканальный маркетинг, профили живут годами.

CDP не заменяет DMP — они работают вместе:

• CDP хранит золотые профили и LTV.

• DMP от имени CDP находит look‑alike в открытых аукционах DSP.

Пример связки в реальной жизни:

1. Клиент покупает ноутбук на сайте.

2. CDP фиксирует транзакцию, обновляет профиль («новый владелец ноутбука»).

3. DMP убирает этого человека из сегмента «ищет ноутбук» и ищет похожих через DSP.

4. CDP запускает e‑mail с апсейлом (сумка для ноутбука).

5. Через 30 дней CDP проверяет: если человек не открыл письмо → push с новой скидкой.

Итог: DMP — это мозг классического программатика: собирает данные из разных источников, склеивает идентификаторы, строит краткоживущие сегменты и отправляет их в рекламные каналы для таргетинга. Но её слабое место — зависимость от cookie и анонимных ID, из-за чего сегменты быстро устаревают и плохо подходят для долгосрочных отношений с клиентами. Именно поэтому бренды постепенно переходят к CDP, где данные принадлежат компании, живут годами и используются не только для рекламы, но и для персонального маркетинга во всех каналах.

Дальше — cookie syncing, где рекламные платформы учатся «говорить на одном языке», чтобы узнать пользователя, даже если у каждого он записан по-разному.

Cookie syncing и user ID matching

Cookie syncing — это технический процесс сопоставления идентификаторов пользователей между различными рекламными платформами. Это критически важный, но при этом один из самых «грязных» процессов в программатик‑рекламе. Без него DSP не смогла бы узнать, что пользователь на сайте X — тот самый, кому она показывала рекламу неделю назад на сайте Y.

Представим ситуацию:

• Пользователь заходит на сайт A, где работает SSP1. SSP1 ставит cookie ssp1_user=abc123.

• Позже пользователь заходит на сайт B, где работает DSP2. DSP2 ставит cookie dsp2_user=xyz789.

• Когда пользователь заходит на сайт C, SSP1 хочет знать: «Этот пользователь с ssp1_user=abc123 — тот самый, кого DSP2 считает ценным клиентом?».

При этом SSP1 и DSP2 не могут напрямую обмениваться данными из‑за изоляции доменов в браузере (same‑origin policy). Следовательно, SSP1 не может прочитать установленную DSP2 куку.

Для решения данного вопроса основным механизмом выступает пиксельный редирект через 302-статуст. Под капотом это работает следующим образом:

• Пользователь заходит на сайт, браузер начинает загрузку, включая тег от SSP

• SSP запрашивает bid request у DSP, например, The Trade Desk (TTD)

• Для синхронизации SSP генерирует iframe с URL: https://sync.adsrvr.org/-match?ssp\_id=abc123&r=https%3A%2F%2Fssp.com%2Fsync%3Fssp\_id%3Dabc123

где:

sync.adsrvr.org — домен TTD для синхронизации

ssp_id=abc123 — идентификатор пользователя в SSP

r — URL для редиректа после синхронизации (закодированный)

• Браузер соотвестcвенно грузит iframe, тем самым обращаясь уже к домену DSP. Браузер уже либо передает куки на этот домен, если id TTD уже существует передает его домену, если нет, то DSP генерирует новый id. После просиходит 302 редирект на домен SSP из параметра r с добавление dsp_id.

• SSP получает запрос, например на https://ssp.com/sync?ssp\_id=abc123&dsp\_id=xyz789 и сохраняет:

{
  "ssp_id": "abc123",
  "dsp_id": "xyz789",
  "dsp": "The Trade Desk",
  "timestamp": "2023-10-15T12:30:45Z"
}

• При следующих формированиях bid_request для этого пользователя dsp_id будет добавлен в OpenRTB‑запрос

Важно заметить, что Prebid.js также может делать cookie syncing, для этого он имеет встроенный модель User ID и User Sync, которые отвечают за инициализацию запросов от SSP для синка.

Сейчас мы рассмотрели Client‑side syncing, когда мы работает на стороне браузера. Такая реализация имеет главную проблему: она работает на third‑party cookie, соответсвенно, после их отмены iframe просто не сможет устанавливать куки файлы. Поэтому платформы начали переходит на server‑to‑server syncing. Здесь схема работы следующая:

• Паблишер (или его SSP) генерирует свой first‑party ID и отправляет запрос напрямую к DSP

POST /v1/sync HTTP/1.1
Host: dsp-api.com
Content-Type: application/json
Authorization: Bearer YOUR_API_KEY

{
  "publisher_id": "pub-123",
  "ssp_user_id": "ssp_user_abc123",
  "source": "server"
}

• DSP проверяет наличие соответствия. Если ssp_user_id уде есть в базу, возвращает dsp_user_id, если нет — происходит генерация нового.

• После ответа DSP, SSP сохраняет соответствие на сервере.

Таким образом браузер убирается из цепочки, что решает проблему блокировки сторонних cookie. Однако и server‑to‑server syncing не лишён недостатков:

• Потеря соответствия при очистке cookie на стороне пользователя — ID приходится восстанавливать через детерминированные или вероятностные методы.

• Необходимость согласия пользователя (GDPR/CCPA, TCF/CMP) — без него синхронизация невозможна.

• Ограниченная совместимость: не все DSP/SSP поддерживают единые ID или готовы к полному переходу на S2S‑схему.

Современные альтернативы cookie syncing

С развитием ограничений на third‑party cookies индустрия перешла к новым подходам идентификации пользователей.

1. Privacy Sandbox (Google).
Privacy Sandbox предлагает браузерные API для таргетинга без передачи персональных идентификаторов.

• Topics API: браузер сам определяет интересы пользователя на основе посещенных сайтов и каждую неделю обновляет список релевантных тем. При рекламном аукционе передаются темы, а не ID пользователя. Например, Chrome может определить, что пользователь интересуется «технологиями» и «спортом», и передать эти темы в bid request:

{
  "user": {     
    "ext": {       
      "topics": [         
        {"taxonomyVersion": 1, "id": 123, "version": 1662286200000},         
        {"taxonomyVersion": 1, "id": 456, "version": 1662286200000}       
      ]     
    }
  } 
}

• Protected Audience API (ранее FLoC): объединяет пользователей в когорты по интересам. Каждая когорта содержит тысячи людей с похожими предпочтениями, и при аукционе передается ID когорты вместо индивидуального ID пользователя.

2. Clean Rooms.
Clean rooms позволяют рекламодателям и платформам обмениваться аудиторными данными без раскрытия персональных данных. Например, рекламодатель загружает свою CRM‑аудиторию, платформа — свои данные, а clean room вычисляет пересечения. Это позволяет узнать, какие пользователи вашей аудитории взаимодействуют с контентом, не раскрывая конкретных идентификаторов.

3. Authenticated Traffic.
Этот подход опирается на логины пользователей. Когда человек авторизуется на сайте, его email хешируется и отправляется в SSP или DSP. Платформы используют этот хеш как основу для создания уникального идентификатора, что позволяет безопасно таргетировать пользователя.

Таким образом, современные методы позволяют обходить ограничения third‑party cookies и обеспечивать таргетинг и аналитические возможности без нарушения приватности пользователей.

Ну а на этом все, куки умерли, идентичности мутировали, серверы синхронизировали. Если вы ранее думали, что реклама — это просто баннеры, поздравляем: теперь вы в матрицк программатик‑аукционов.

В следующей части мы погрузимся в технические стандарты и протоколы: OpenRTB, Prebid.js и Header Bidding, разберём видео‑форматы VAST/VPAID/OMID и нативную рекламу, а также пройдём путь от запроса bid до показа рекламы через клиентские и серверные интеграции.