Budget Smoothing в DSP 💵

Сегодня рассмотрим, как DSP рассчитывают ставки из объема оставшегося бюджета на рекламную кампанию. DSP должна распределять бюджет таким образом, чтобы он не закончился слишком рано и при этом не оставался неиспользованным, когда уже слишком поздно. Для этого в ставку добавляют множитель, т.н. smoothingFactor

bidDSPSmoothed = bidDsp x smoothingFactor

Рассчитывают smoothingFactor обычно при помощи PI-регулятора (пропорционально-интегрального). Формула для smoothingFactor в час h+1 может быть записана так:

smoothingFactor(h+1) = smoothingFactor(h) + p x proportionalError + i x integralError

- proportionalError = targetBudget - spentBudget. Пропорциональная часть управляет быстротой реакции и амплитудой ответа на изменение оставшегося бюджета от часа к часу.
- integralError = sum(proportianlErrors[0:n]). Интегральная часть обеспечивает стабильность регулятора (своего рода инерция).
- p и i — гиперпараметры, которые подбираются офлайн.

Из практики дифференциальная часть (D) в регуляторе практически не используется. Если бюджет на размещение задаётся на сутки, то smoothingFactor следует пересчитывать каждый час. Также необходимо учитывать суточный профиль распределения трафика. Чтобы избежать сбоев в стратегии ставок из-за возможных скачков smoothingFactor (например, для размещений с низким объёмом или тестовых кампаний), вводится ограничение бюджета: в случае sold out bidFactor принудительно задаем 0.

Чтобы корректно распределять бюджет в течение суток, мы также взвешиваем дневной бюджет по профилю распределения трафика по часам. Распределение трафика нормировано так, чтобы его сумма за все часы была равна 1. Если у нас есть суточный целевой бюджет targetDailyBudget, мы можем разбить его по часам, умножив на соответствующий вес в распределении трафика:

targetHourlyBudget(h) = targetDailyBudget x TrafficDistribution(h)

Не мог пройти мимо этого шедевра

Bid Shading

Сегодня разберем алгоритм маржинальности 💵 в аукционах в программатик рекламы, т.н. Bid Shading. Согласно статьи на AdExchanger, многие DSP использует этот алгоритм для искусственного занижения ставки, и для многих он является черным ящиком. Мы же разберем, как можно реализовать алгоритм технически.

Для начала введем величину ставки bid к примеру для DSP (платформы стороны спроса). Она представляет собой "истинную" цену, которую DSP готова заплатить за покупаемый инвентарь. Когда мы конкурируем с другими DSP, может случиться так, что мы сделаем (и оплатим) ставку слишком высокую, не адаптированную к уровню конкуренции.

Чтобы адаптировать ставку по отношению к другим игрокам и максимизировать маржу мы введем коэффициент shadingFactor в диапазоне [0..1]. В двух крайних случаях, если shadingFactor = 0, то ставку не понижаем, а если shadingFactor = 1 , то бидим 0.

Запишем формулу для маржи с учетом shadingFactor и заниженой "шейдированной" ставки shadedBid

shadedBid = bid x (1 - shadingFactor)
margin = bid - shadedBid = bid x shadingFactor

Теперь нужно задаться вопросом, как выбрать оптимальный shadingFactor. Сделаем мы это следующим образом,

Сначала нам нужно учитывать вероятность выигрыша p(bidWin | bidRequest, bidShadingFactor) нашей платформы в аукционе при условии признаков покупаемого слота, пользователя, спроса и shadingFactor. Это нужно, поскольку чем выше shadingFactor, тем ниже вероятность победы в аукционе. Поскольку мы ввели в формулу маржи вероятность, то нам стоит максимизировать ее мат. ожидание

E(margin) = bid x shadingFactor x p(bidWin | bidRequest, bidShadingFactor)

При этом вероятность победы в аукционе p(bidWin) может предсказываться для каждого слота с помощью классической бинарной ML-моделью. Тогда оптимальный коэффициент bidShading' запишется в виде:

bidShadingFactor' = argmax(E(margin))

Этот оптимальный коэффициент мы можем включить в формулу пониженной шейдированной ставки

shadedBid = bid x (1 - shadingFactor')

Новая ставка shadedBid будет адаптирована к ставкам конкурентов и будем принимать во внимание возможную просадку доли побед bidWin в аукционах.

Я много пишу про программатик и работу с паблишерами по части supply. Наряду с этим в рекламе есть арбитраж трафика. В нем выкупается инвентарь с разных площадок и перенаправляется на партнёрские офферы, с прибылью за счёт разницы между стоимостью привлечения и конверсий в основном CPA, CPC.

В отличие от программатика, где цепочки доставки рекламы автоматизированы, арбитраж зачастую требует ручных настроек. Также многие при упоминании арбитража в первую очередь представляют трейдинг и открутку бюджетов 💰 Но здесь есть и обратная сторона медали - это техническая часть, она же зачастую оказывается скрытой от глаз. Успехи медиа байеров являются результатами правильной автоматизации работы с трекерами, партнерками и алгоритмами монетизации.

Каналов, где можно узнать про техничку мало, и каждый из них на вес золота. Поэтому хочу порекомендовать канал Евгения BoostClicks, в котором вы найдете:

➡️ API интеграции с партнерскими сетями с примерами кода
➡️ Кодовую базу к скриптам и ботам для улучшения качества трафика, расшаривания пикселей, создания уникальных креативов и многого другого
➡️ Способы обхода модерации Яндекс Директа и реджектов кабинетов Google Ads

Я в своей практике регулярно черпаю из канала полезные посты и ссылки, поэтому и вы присоединяйтесь! 🚀️️️️️️

Проектируем платформу ставок с нуля? 💵

Сегодня займемся проектированием своей Real Time Bidding платформы ставок. На упрощенной схеме мы разберем из каких основных блоков она должна состоять, и как эти блоки между собой связаны.

➡️ Article
Собственно сама веб-страница с размещенными на ней рекламными слотами. Также в случае Header Bidding интеграции в шапке HTML кода страницы могут быть прописаны настройки, в которые добавлен наша платформа ставок, как игрок, имеющий доступ к покупке слотов.

➡️ TagJS
JS код, размещенный на странице паблишера. Отвечает за трекинг действий пользователя на сайте, например, когда пользователь доскролил до слота, увидел пиксель, кликнул etc. Отправляет события на нашу сторону.

➡️ Bidder
Биддер - это модуль, отвечающий за коммуникацию с паблишером (или с Prebid'ом, если закупаем трафик через Header Bidding) и отправку ставок.
- Принимает запрос на ставку + фичи паблишера + user agent, чтобы извлечь фичи пользователя.
- Собирает ставку с учетом заложенной маржи на запрос bid = CPM x (1 - margin) x bidFactors, с учетом коэффициентов, понижающих ставок, выданных автобиддингом.
- Когда ставка посчитана, отправляет на ендпоинт паблишера или Prebid'а ответ со ставкой.

➡️ Models
Все ML модели, отвечающие за фильтрацию, монетизацию
- Фильтрация по вероятности показа, клика, досмотра etc.
- Фильтрация по фроду
- Оптимизация ставки (shading, автобиддинг)
- Budget pacing
Может быть как интегрирован внутрь биддера, так и вынесен в отдельный сервис, к которому биддер будет обращаться как клиент.

Инференс, встроенный в биддер
В первом случае у нас получается маленький монолит внутри платформы из двух сервисов, в связи с чем потребуется быть более аккуратными при внедрении изменений в сервис, но появляется возможность кешировать модели, и насладиться относительно низким latency.

Отдельный инференс сервис
Во втором же случае структура получается модульная, в оба сервиса можно вносить изменения независимо друг от друга, но придеться заплатить более высоким latency (в основном из-за HTTP коммуникации между сервисами). Также встает вопрос, что делать биддеру, если сервис с моделями упал. Если в первом случае артефакты были закешированны на биддере, он мог пользоваться ими до тех пор, пока новые модели не подъедут, то во втором случае модули друг для друга становятся черными ящиками, и нужно задаться вопросом обеспечения минимального availability

➡️ Tracking
Пожалуй, центральный элемент всей схемы, поскольку на нем замыкаются все. Логирует абсолютно все события
- на стороне паблишера: действия пользователя + транзакции
- на стороне биддера: отказ от ответа, таймаут, ставка с ее значением
- на стороне моделей фильтрации: события фильтрации + ее причины
Кроме того логируем события биллинга, когда по аукциону мы должны получить оплату от рекламодателя и заплатить паблишеру

➡️ DB
Затреканные события и транзакции нужно куда-то писать, делать это быстро, и иметь оптимизированное хранилище. Здесь все делаем по заветам книжки с кабанчиком. Чаще всего прибегаем к следующему варианту. Tracking сервис пишет события по мере их поступления в очередь данных (Kafka, RabbitMQ). Далее с помощью либо Kafka коннектора, либо Spark Streaming джобы пишем события из очереди в батчи в объектное хранилище (S3, GCS) партициями. Также можно писать и в OTLP хранилище с быстрой записью транзакций (Greenplum)

Кроме того, нам также потребуется хранилище для аналитики (по-английски еще называют OLAP хранилища). Это нужно для отслеживания статов платформы в целом по аггрегатам трафик, CPM, CPC, CPV group by publisher, тип контракта, страна etc. Для этого подойдут ClickHouse или Google BigQuery

Invoicing
Модуль, который читает данные из OLAP хранилища и отвечает за выстапление счетов рекламодателю. На этапе трекинга в момент логирования события оплаты, сама оплата не происходит. Записанные события с биллингом аггрегируются, и рекламодателю выставляется счет на сумму, которая должна биться с бюджетом, который наша платформа открутила. Эта процедура делается раз в месяц или в квартал.

Сегодня порефлексируем на тему, куда делись Prоject Manager'ы?

В бытность моей работы в авиа отрасли в компаниях-подрядчиках Airbus'а буквально в каждой команде на каждом проекте имелся Project менеджер. Именно он замыкал на себе весь цикл проекта: от первой встречи с заказчиком до приемки, задавал сроки и дедлайны, решал конфликты внутри команды.

Недавно я поймал себя на мысли, что в бигтехе таких позиций в командах в принципе не осталось. Куда же они пропали?

Моя гипотеза такая, что задачи проджектов распределились между менеджерами команд (или engineering manager'ами), продактами и самими разработчиками.

➡️ Менеджеры команд
Engineering менеджеры сегодня должен делать все необходимое, чтобы масштабировать уже существующий продукт. Он приоретизирует задачи, находит ресурсы, снимает блокеры, в общем делает все необходимое, чтобы продукт приносил прибыль, улучшался, а команда работала эффективно и окупала себя

➡️ Продакты
Что касается определения болей клиента, ответа на вопрос, "что строим и зачем" - это все задачи продакта. Они планируют и запускают проекты с 0 до MVP, а дальнейшее развитие продукта передают уже в руки engineering менеджера.

➡️ Разрабы
Что касается разрабов, то во многих командах операционную часть проекта вполне можно доверить Senior разработчику. Сейчас команды имеют бОльшую автономность и самоорганизацию и способны сами оценить сроки, наладить day-to-day взаимодействие, разрулить блокеры. Это результат писанных кровью наработанных практик общения, review, ответственности за реализацию продукта и налаженного стека выкатки в прод.

Крупные проекты, в которые вовлечены много команд, и на кону многомилионная выручка, уже естественно управляются лично engineering менеджерами, и с клиентами общаются тоже они

Как зарабатывать на рекламе, не продавая ее? 🤔

Знали ли вы, что зарабатывать на программатик цепочке можно, не являясь непосредственным участником аукционов и не продавая трафик. Нужно всего лишь подцепиться к этой цепочке и предложить платформам ставок ее оптимизацию. SSP и DSP несут огромные расходы на сетевую передачу данных запросов ставок, 80% из которых остаются без ответа. Среднеразмерные SSP готовы покупать решения из коробки, которые помогут им срезать сетевые косты хотя-бы на 10-20%.

Как же на этом заработать?
Допустим, мы компания разрабатывающая умное ML решение на фильтрацию невостребованных рекламных запросов. Для начала оценим расходы клиента SSP на HTTP коммуникацию. Возьмем 1M аукционов, проходящих через нашего потенциального клиента SSP. Предположим, каждый adCall рассылается 10 биддерам. Мы получаем 10M запросов ставок

1M auctions x 10 SSPs = 10M bid requests

Считаем объем переданных данных. Обычно бид реквест имеет размер около 1-1.5Kb, тогда объем переданных данных за 10M запросов составит 15 Gb

10 bid reqests x 1.5Kb = 15 Gb

Теперь оценим network cost из расчета расходов на HTTP коммуникации $0.10 за 1Gb переданных данных. Получим $1.5 за проведение 1M аукционов. Таким образом мы оценили верхнюю границы нашего прайса: комиссия не должна быть выше, чем расходы на коммуникации

15 Gb x $0.10 = $1.5

Экономическую модель берем, как процент от сэкономленных расходов на инфру клиента (Revenue Share Model на английском). Если мы с помощью нашей модели умной фильтрации сможем снизить косты SSP с $1.5 на 40%, то экономия составит $0.60. С этого значения мы возьмем свою комиссию в 30%. В итоге получим значение нашей выручки на 1M аукционов

$1.5 x 0.4 = $0.60
$0.60 x 0.3 = $0.18 / 1M auctions

При этом 1M аукционов не такая уж и большая цифра для среднеразмерной SSP. Для таких платформ суточный трафик может достигать 7 млрд аукционов, а месячный около 200 млрд. Отсюда можем посчитать выручку за месяц

$0.18 x 200 x 10^3 = $36k

Итого за месяц нашей моделью фильтрации на одной SSP мы можем заработать $36k. При этом по мере масштабирования трафика и подключения более крупных SSP мы можем предлагать дисконты на комиссию на 1M аукционов: 30% -> 20% -> 15%.

Далее дело за малым: построить свой сервис, который сможет снижать косты на отправку бид реквестов и правльно фильтровать их. Кроме того во взаимодействии с клиентов возникнет трудность, настроить мониторинг и расчет фильтрованного трафика и экономии костов на HTTP запросы так, чтобы это было прозрачно для нас и для клиента.

Подготовил статью на Хабре про введение в систему очередей Apache Kafka. В статье много картинок и демка, как поднимать Consumer в облачном сервисе Confluent Cloud. Рекомендую всем, кто интересуется потоковой обработкой данных на проде.
https://habr.com/ru/articles/880700/

Что не так с программатиком сегодня?

Мне на глаза попалась пара схем из отчета Национальной ассоциации рекламодателей (ANA) в штатах, в котором приводится распределение расходов на всей программатик цепочке между моментом закупки трафика рекламодателем и выплатой паблишеру.

Так на каждые $1k открученного бюджета рекламодателя 29% оседает в карманах многочисленных посредникам SSP/DSP в виде комиссии, в которую в том числе зашиты их расходы на инфру и маржа. Далее еще 35% уходит в буквальном смысле в пустоту на MFA, non-viewable/ non-measurable/ non-brand-safe/ невалидный трафик. В конечном итоге до паблишеров доходит 36% от всего открученного бюджета, из-за чего от них мы все чаще слышим резонный вопрос "Где деньги?!"

Касательно раздутых цепочек посредников, если лет 5-7 назад паблишеры могли повышать монетизацию за счет постоянно растущего числа конкурирующих между собой платформ на Header Bidding'е и на внутренном аукционе SSP, сейчас этот рост прекратился, поскольку на рынке осталось полтора десятка крупных платформ, которые поглотили всех остальных. При этом количество adCall'ов не уменьшилось. Вместо этого запросы на один и тот же слот мультиплицируются и рассылаются на одни и теже площадки Criteo, Pubmatic, TTD etc. (пример на картинке)

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

Добиться этого можно следующими способами:
- Отсеивать невалидный и non-viewable трафик на самом раннем этапе AdCall'а (см. пост про traffic-shaping)
- Сократить цепочки посредников SSP за счет фильтрации тех, кто редко отвечает ставкой на трафик
- Перестать применять в отношении MFA (Made for advertising) сайтов полумеры и просто отключать их без выплат

Поэтому Let's make programmatic great again!

Про управление в командах

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

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

Но с другой стороны директивный стиль лучшего всего показывает себя в ситуациях:
- горящих дедлайнов, когда нет времени мусолить альтернативные идеи, надо делать 🔥
- на заводе, когда есть четкий тех. процесс и меры техники безопасности 🏭
- в работе с junior-коллегами и стажерами. Чтобы неопределенность в сложных задачах их не демотивировала, мы даем точные понятные инструкции и такой же фидбек
- в случае инцидентов/ критических ситуациях, когда на кону стоят миллионы денег, и нужно принимать решения быстро

Зачем тогда нужно недирективное управления?
Оно нужно, когда мы хотим построить более автономную команду, способную действовать в условиях неопределенности и принимать собственные решения. Здесь вместо того, чтобы давать инструкции сотрудника, мы поощряем инициативу и личную ответственность и даем свободу в принятии решений на его уровне (например выбор фреймворков, design паттернов, оценку сроков задач, взаимодействие со смежниками etc.)

Вроде бы все просто. Что может пойти не так? 🤔
- Отсутствие мотивации у сотрудника: сколько волка не корми, он все равно в лес смотрит. Здесь особо ничего не сделаешь 🤷‍♂️
- Наличие/ отсутствие безопасной среды: инициатива должна правильно восприниматься менеджерами без херни и токсичности. С другой стороны есть инициативы, а есть приоритеты команды на квартал, и поскольку ресурсы команды ограничены, ими нужно распоряжаться разумно
- Фокус на сотруднике: менеджер должен понимать, как сотрудник видит свое личное развитие, и задавая правильные вопросы, направлять его на благо команды
- Обоюдная готовность к переменам: изменения состава/ направления работы команды требуют сил и времени, и не все к этому могут быть готовы

Attention is all you need 🧐

Сегодня поговорим про Attention, только не тот, что в трансформерах (архитектуры сеток мы обсудим в следующих статьях).

Речь пойдет про метрику внимания в рекламе. Пару лет назад программатик открутчиками и трейдерами было выявлено, что метрики конверсий (CPA, qualified visit, доля конверсий) коррелирует с длительностью просмотра рекламного слота. Тогда же выяснилось, что если для видео оптимизировтаь только view-through-rate, то 70% от всех viewable ads уходят в пустоту, и за ними не следует ни досмотров, ни кликов, ни конверсий

➡️ Отсюда и зародилась концепция "борьбы за внимание" пользователя.
- Ввели метрику под названием Attentive seconds per mille impressions (APM), или количество секунд просмотра на тысячу показов. Далее выявлено, что APM обратно скоррелирована с метриками перформанса CPA, CPC.
- Вдобавок к времени просмотра также ввели cost per mille attentive impressions (aCPM), т.е. косты на тысячу показов, время просмотра, которых не ниже определенного порога, например в 3 секунды

➡️ Зная эти метрики можно поступить двумя способами
- Разбить трафик на бакеты с высоким, средним и низким aCPM, и если цель кампании CPA, то закупать только трафик из нижнего бакета aCPM и высоким временем просмотра
- Аналогично можно поступить и на таргетинге пользователей, доставляя показы только до сегментов IAB с высоким APM
- Зная APM и aCPM, их можно добавить в АБТесты креативов. Поскольку мы находимся на post-impression, привлекательность и цепкость креатива здесь играет важную роль

➡️ Как измерять attention?
- Самый простой способ - это замерить время, когда пиксель слота, трекаемый адсервером GAM или Яндекс Метрикой находится во view-порте устройства пользователя. Достаточно просто реализовать для Desktop'а и мобилок, но точно не сработает для DOOH и CTV. К слову именно на CTV достигаются самые высокие доли досмотров CVTR
- Можно поступить чуть хитрее и измерять время пролета мышки над слотом. Проблема здесь та же, что и в предыдущем пункте: нигде кроме desktop'а это не реализовать
- В британской компании Lumen пошли еще дальше и начали трекать взгляд пользователя на экран. В результате строится тепловая карта просмотра слота в разные моменты времени, откуда и замеряются метрики внимания. Ясное дело, заставить всех пользователей дать согласие на eye-tracking не получится, используют тестовые группы из пары сотен/тысяч пользователей, которые за денюжку соглашаются установить eye-tracking приложение, с которого 24/7 собираются тепловые карты просмотров слотов

В целом подход к оптимизации метрик внимания помогает снизить CPA и повысить конверсии, и потому является неплохой прокси метрикой для перформанса

Я подготовил новую хабр статью. На этот раз про виртуальную рекламу в спортивных видео. Здесь вы найдете примеры форматов рекламы в индустрии спорта и демку на OpenCV с детектированием ключевых точек (ранее про задачу я также писал), в которой разместил баннер Адидаса в видео

Как оптимизировать CPA?

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

➡️ Избавляйтесь от ботового трафика и MFA, поскольку они первыми блэклистятся основными DSP и Google Ads

➡️ Используйте везде, где возможно, server-side логирование ивентов. Это касается всех ивентов пользователя, conversion paths, time-to-conversion etc. В противном случае будете терять до 30% данных о пользователе. Это значит, что вам нужен собственный пиксель на странице паблишера или свои first-party cookie

➡️ Также проблемой может быть то, что агенство/ реселлер не умеет различать новых и вернувшихся клиентов. Для алгоритмов DSP это имеет значение. Вводите сквозной user_id для корректного отслеживания пользователя

➡️ Отслеживайте пользователей с разными устройствами. Так показ клиенту может быть залогирован на мобиле, а покупка на десктопе. Вы должны объединять профили этого клиента и отправлять полные данные в DSP

➡️ Принимайте во внимание ускоренное выгорание креативов. Раньше можно было крутить АБ тесты над креативами по 2-3 недели. Сейчас этот срок ужимается до 5-7 дней, после чего креатив выгорает. Решением может быть ускорять итерации АБ тестов, запускать до десятка активных вариантов креативов. В совокупности это поможет снизить CPA на треть

Касательно полезностей в работе с CPA хочу порекомендовать канал CPAInform 💵

Что вы найдете
- На какие вертикали нужно заливать трафик в 2025 году, чтобы быть в плюсе?
- Топ-5 Gen AI сеток для обработки креативов и голоса, подписки на которые не загонят вас в долги
- Влияние налога на рекламу и инфляции на CPA и CPC в недвижимости, ecomm'е, фарме etc.

Кроме того, получать инсайты по офферам и взаимодействовать с партнеркой можно через бота. CPAExchange_RegistrationBot – ваша возможность зарабатывать на арбитраже!

Изучайте эффективные методы продвижения и внедряйте их в свой бизнес!
Присоединяйтесь к CPAInform! 🔥