Ad Exchange в рамках Real-Time Bidding (RTB) — одно из AdTech-решений, видоизменяющих рынок онлайн-рекламы. Его основная функция — стыковка большого количества SSP и DSP, которые не имеют прямой интеграции между собой, а также перепродажа разнообразного рекламного трафика между ними.
Благодаря заказу для рынка США мы с головой погрузились в специфику построения платформы Ad Exchange. И в этой статье представляем некоторые идеи и результаты.
Real-Time Bidding (RTB) обеспечивает продажу рекламных площадей на сайтах в режиме реального времени для демонстрации релевантных объявлений целевой аудитории.
Если коротко, схема процесса выглядит следующим образом:
Бирж Ad Exchange сегодня существует довольно много. Кроме того, многие SSP реализуют собственные торги (фактически закрывая функционал Ad Exchange). Но наш заказчик был уверен, что за счет некоторых новых идей сможет быстро выйти на рынок и выдержать конкуренцию.
Биржи работают по разным принципам: кто-то предлагает большую маржу, кто-то меньшую, кто-то торгует уникальным инвентарем, другие ориентируются на условный ширпотреб. Рынок довольно молод и активно развивается, поэтому проверенных годами бизнес-моделей здесь нет: все построено на смелых гипотезах и экспериментах. Большинство игроков работают по простой схеме: получают запрос от одного из нескольких SSP, с которыми удалось договориться, и отправляют его во все интегрированные DSP в ожидании лучшей ставки. Доход Ad Exchange — разница между ценой покупки и продажи рекламного инвентаря у SSP и DSP за вычетом эксплуатационных расходов.
Эту схему и предложил оптимизировать наш клиент, грамотно распределив запросы SSP к DSP — не отсылать заведомо «проигрышные» запросы, тем самым сократив эксплуатационные расходы. За счет этого можно снизить комиссию работы биржи, не проигрывая в доходах, и сделать свое предложение более привлекательным на фоне конкурирующих Ad Exchange в борьбе за SSP и DSP. А подключение большего числа партнеров даст как доход, так и стабильность положения на рынке.
Для реализации этой стратегии на рынке США перед нами была поставлена задача сделать Ad Exchange с умным распределением запросов, которое должно было обеспечить хороший процент выкупа. В теории для такого распределения можно использовать массу информации, сопутствующей запросу, даже данные из упомянутых выше сторонних систем (DMP). Однако сложная аналитика требует ресурсов, поэтому задача на самом деле заключается в поиске баланса между затратами на умное распределение и выигрышем (на фоне других игроков рынка) от его реализации. На сравнительно новом незрелом рынке строить очень сложные решения, выжимая десятые процента оптимизации, просто не имеет смысла.
Важной особенностью проекта, помимо ожидаемых высоких нагрузок, было выполнение нефункционального требования по скорости прохождения аукциона, выставляемого SSP. Адекватным в этом сегменте рынка является таймаут ожидания ответа со стороны SSP в 300 мс, в который необходимо было уложиться вместе с обращениями к внешним системам (DSP).
Проект стартовал осенью 2016 года. Благодаря опыту команды в данной области уже через три месяца мы сделали первый прототип, а еще через три был готов MVP (Minimum Viable Product), позволивший собрать первую аналитику для запуска умного распределения запросов внутри Ad Exchange.
Запуск MVP показал, что гипотеза о коммерческой успешности проекта верна — Ad Exchange начал зарабатывать клиенту деньги. В первоначальных планах развития Ad Exchange была более глубокая проработка данных — подключение к аналитике информации о конечных пользователях с внешних систем. Но на этапе MVP было принято решение использовать только те данные, которыми обладает SSP. Этого оказалось достаточно для получения ожидаемой прибыли.
Решение построено по шаблону цепочки обязанностей (Chain of responsibility), позволяющей не фиксировать маршрут запросов внутри системы, легко добавляя обработчики и различные сервисы, от самого аукциона до инструментов фильтрации.
Заказчик не ограничивал нас в стеке используемых технологий. Поэтому, заботясь о будущем развитии и поддержке проекта, мы построили горизонтально масштабируемое решение с использованием Postgres и Hadoop.
Сам Ad Exchange написан на Java — при этом мы не использовали никаких фреймворков, чтобы не проседать в нагрузке (работали на низком уровне).
Чтобы уложиться в упомянутый таймаут SSP, мы подбирали параметры garbage collector (использовался G1) и прорабатывали синхронную работу с большим количеством запросов — использовали HTTP-клиент, который не блокирует поток, а также расширение протокола HTTP keep-alive, позволяющее отправлять несколько запросов в рамках одного TCP-соединения.
Программные компоненты развернуты на арендованном у хостера железе, т.к. условия задачи не позволяли использовать облако из-за перекрытия ресурсов виртуальных облачных машин (выделение необходимых ресурсов может занять время, а у нас его нет). На данный момент Ad Exchange задействует четыре физических сервера, один из которых избыточный (для проведения бесшовных обновлений и т.п.).
В качестве message-брокера задействован опенсорсный Apache Kafka — он идеально встроился в нашу модель «one subscriber — many publishers», хотя его пришлось немного «докрутить» так, чтобы не приходили повторные сообщения.
Каждый из серверов обеспечивает в штатном режиме обработку порядка 10 тыс. запросов в секунду (эти параметры закладывались при разработке решения). Сейчас средняя нагрузка — 15—20 тыс. запросов в секунду, а в пиках поток запросов достигал 40 тысяч в секунду в течение нескольких часов, и Ad Exchange с этим прекрасно справился.
Распределение запросов между серверами осуществляет программный балансировщик нагрузки nginx, настроенный под нашу задачу. По нашему опыту, на nginx можно держать до 60—70 тыс. запросов в секунду, не выделяя отдельный аппаратный балансировщик. Если же в будущем нагрузка на Ad Exchange будет выше этого порога, мы планируем приобрести аппаратный балансировщик, который распределит запросы между несколькими однотипными nginx.
Контролирует происходящее, при условии постоянного роста нагрузки, система мониторинга, являющаяся частью созданного Ad Exchange.
Учитывая ставку на аналитику в ходе распределения запросов, база данных является неотъемлемой частью нашего Ad Exchange. Система хранит информацию о ставках, участниках аукционов и заключенных сделках.
Нет смысла собирать такой объем данных за весь период работы Ad Exchange, поэтому хранилище имеет многоуровневую архитектуру. Все данные об аукционах хранятся за неделю. На их основе строятся более высокоуровневые промежуточные агрегаты, которые хранятся несколько месяцев. А уже на базе промежуточных собираются конечные агрегаты, используемые в долгосрочной аналитике и для сверок с SSP и DSP. Среди прочей информации в этих агрегатах есть данные о том, сколько было сделано ставок и сколько денег биржа заплатит SSP или ожидает получить от DSP.
Конечные агрегаты хранятся в течение всего срока работы Ad Exchange.
Сбор аналитики и формирование агрегатов обеспечивают отдельные службы.
Чтобы хранилище соответствовало скорости работы самой системы, с ним также пришлось поработать. В частности, какое-то время мы воевали с хостером, т.к. данные о сделках просто не успевали записываться в базу. Выяснилось, что виной тому была аппаратная проблема с RAID-массивом. После его замены мы смогли выжать на Postgres 90 тыс. запросов в секунду (на вставке данных в базу).
Остальная часть Ad Exchange — stateless, что и обеспечивает в перспективе легкое горизонтальное масштабирование. Она не хранит никакие данные по запросам — максимум, полученные сведения о том, какой DSP надо выбрать. Так что мы сможем добавлять новые сервера для обработки запросов по мере необходимости.
Ключевой элемент системы, позволяющий снизить нагрузку и уложиться в обозначенные заказчиком таймауты, — это фильтрация трафика.
В соответствии с выполняемой задачей любой Ad Exchange:
Умное распределение запросов в нашем Ad Exchange включается на начальном этапе аукциона.
Получая запрос от SSP с определенной информацией (IP, user agent), мы детализируем его при помощи накопленных в системе сведений — известных данных о пользователе, перечня DSP, в которые отправлялись аналогичные запросы, их ответов и т.п. Это необходимо, чтобы выбрать наиболее выгодную комбинацию DSP под каждый запрос. Благодаря подбору такой комбинации система позволяет не посылать запросы в те DSP, которые не делают ставки или делают, но слишком низкие. Для этого отдельный сервис в режиме реального времени составляет карту того, как DSP отвечает на запросы (карты эти хранятся в Redis).
Параллельно мы проверяем состояние DSP — если доля ответов в рамках таймаута падает, система автоматически снижает количество запросов к этому DSP. Как только нагрузка на DSP снижается (а доля корректных ответов за приемлемое время растет), количество запросов постепенно возвращается на прежний уровень.
Среди DSP, ответивших вовремя, мы проводим внутренний аукцион — выделяем лучшее предложение и отсылаем его в SSP. С момента запроса от SSP до нашего ответа проходит не более 300 мс, в соответствии с отраслевым требованием.
Поскольку мы отдаем данные в SSP, где проводится свой аукцион, нам необходимо учитывать выигравшие там ставки. Их логированием занимается сервер аукциона уже на следующем этапе, при обработке пользовательского трафика. Благодаря ему карта ответов DSP обогащается новыми данными (вместе с собранной информацией о конечном пользователе).
Сопоставление данных, полученных на этапе аукциона, и параметров, известных из пользовательского трафика, позволяет отсеивать ботов (кликеров по рекламе, поисковых ботов и т.п.). Такой трафик не выкупается DSP, а при отсутствии собственной системы фильтрации он превращается в потери клиента, которые придется закрывать маржой.
Надо отметить, что фильтрация трафика ботов была запущена не сразу. Но после включения простых блокировок выигрыш по марже составил порядка 50%.
Кстати, помимо автоматических инструментов фильтрации трафика в нашей системе, предусмотрена возможность для заказчика вручную изменить пороговые значения ряда параметров, скорректировав таким образом маржу.
Сам пользовательский трафик для нас критичен, но при его обработке уже не обязательно укладываться в 300 мс. Здесь используется отдельная система обработки, которая может немного придержать пользователя, но не даст потерять этот запрос.
Для обеспечения стабильности решения была внедрена подсистема, которая, понимая текущую загрузку Ad Exchange, «обрезает» запросы на аукционы, которые она физически не может обработать. Так система защищается от неконтролируемого роста нагрузки со стороны SSP.
На сегодняшний день созданный нами Ad Exchange работает и приносит неплохую прибыль. А мы осуществляем поддержку и интеграцию новых партнеров (DSP/SSP) по необходимости. В общей сложности уже интегрировано несколько десятков систем. Каждая такая интеграция подразумевает не только программное подключение, но и всестороннее тестирование сервиса, ведь в условиях больших нагрузок проблемы подключенного сервиса могут отразиться на других партнерах.
В целом рынок движется к тому, что SSP и DSP будут соединяться напрямую, что сделает биржи ненужными. Но интеграция упирается в возможности SSP и DSP. Несмотря на существование открытого описанного API (протокола OpenRTB), он пока не является общепризнанным на рынке. К примеру, такой крупный игрок, как Appnexus, интегрировал поддержку OpenRTB совсем недавно.
По сути Ad Exchange — это провайдер ликвидности. Так что решение в ближайшее время вряд ли потеряет свою актуальность. Тем более что на остальном рекламном рынке биржевая модель только набирает популярность.
Автор статьи: Николай Еремин
P.S. Мы публикуем наши статьи на нескольких площадках Рунета. Подписывайтесь на наши страницы в VK, FB или Telegram-канал, чтобы узнавать обо всех наших публикациях и других новостях компании Maxilect.
Благодаря заказу для рынка США мы с головой погрузились в специфику построения платформы Ad Exchange. И в этой статье представляем некоторые идеи и результаты.
Постановка задачи
Real-Time Bidding (RTB) обеспечивает продажу рекламных площадей на сайтах в режиме реального времени для демонстрации релевантных объявлений целевой аудитории.
Если коротко, схема процесса выглядит следующим образом:
- конечный пользователь запрашивает интернет-страницу или мобильное приложение, где зарезервировано место под баннер (встроен код платформы продажи рекламного инвентаря — SSP, Supply Side Platform);
- для обеспечения максимальной цены продажи инвентаря SSP посредством Ad Exchange организует торги между различными DSP (Demand Side Platform), чья цель — купить инвентарь как можно дешевле;
- после объявления победителя аукциона выигравший DSP отправляет SSP код баннера, который и демонстрируется пользователю;
- еще одна сторона процесса — DMP, сторонняя система, предоставляющая DSP подробную информацию о конечном пользователе (за рамками того, что может передать SSP в виде cookies и т.п.), чтобы обосновать целесообразность покупки и предлагаемую стоимость.
Бирж Ad Exchange сегодня существует довольно много. Кроме того, многие SSP реализуют собственные торги (фактически закрывая функционал Ad Exchange). Но наш заказчик был уверен, что за счет некоторых новых идей сможет быстро выйти на рынок и выдержать конкуренцию.
Биржи работают по разным принципам: кто-то предлагает большую маржу, кто-то меньшую, кто-то торгует уникальным инвентарем, другие ориентируются на условный ширпотреб. Рынок довольно молод и активно развивается, поэтому проверенных годами бизнес-моделей здесь нет: все построено на смелых гипотезах и экспериментах. Большинство игроков работают по простой схеме: получают запрос от одного из нескольких SSP, с которыми удалось договориться, и отправляют его во все интегрированные DSP в ожидании лучшей ставки. Доход Ad Exchange — разница между ценой покупки и продажи рекламного инвентаря у SSP и DSP за вычетом эксплуатационных расходов.
Эту схему и предложил оптимизировать наш клиент, грамотно распределив запросы SSP к DSP — не отсылать заведомо «проигрышные» запросы, тем самым сократив эксплуатационные расходы. За счет этого можно снизить комиссию работы биржи, не проигрывая в доходах, и сделать свое предложение более привлекательным на фоне конкурирующих Ad Exchange в борьбе за SSP и DSP. А подключение большего числа партнеров даст как доход, так и стабильность положения на рынке.
Для реализации этой стратегии на рынке США перед нами была поставлена задача сделать Ad Exchange с умным распределением запросов, которое должно было обеспечить хороший процент выкупа. В теории для такого распределения можно использовать массу информации, сопутствующей запросу, даже данные из упомянутых выше сторонних систем (DMP). Однако сложная аналитика требует ресурсов, поэтому задача на самом деле заключается в поиске баланса между затратами на умное распределение и выигрышем (на фоне других игроков рынка) от его реализации. На сравнительно новом незрелом рынке строить очень сложные решения, выжимая десятые процента оптимизации, просто не имеет смысла.
Важной особенностью проекта, помимо ожидаемых высоких нагрузок, было выполнение нефункционального требования по скорости прохождения аукциона, выставляемого SSP. Адекватным в этом сегменте рынка является таймаут ожидания ответа со стороны SSP в 300 мс, в который необходимо было уложиться вместе с обращениями к внешним системам (DSP).
Проект стартовал осенью 2016 года. Благодаря опыту команды в данной области уже через три месяца мы сделали первый прототип, а еще через три был готов MVP (Minimum Viable Product), позволивший собрать первую аналитику для запуска умного распределения запросов внутри Ad Exchange.
Запуск MVP показал, что гипотеза о коммерческой успешности проекта верна — Ad Exchange начал зарабатывать клиенту деньги. В первоначальных планах развития Ad Exchange была более глубокая проработка данных — подключение к аналитике информации о конечных пользователях с внешних систем. Но на этапе MVP было принято решение использовать только те данные, которыми обладает SSP. Этого оказалось достаточно для получения ожидаемой прибыли.
Архитектура решения
Решение построено по шаблону цепочки обязанностей (Chain of responsibility), позволяющей не фиксировать маршрут запросов внутри системы, легко добавляя обработчики и различные сервисы, от самого аукциона до инструментов фильтрации.
Заказчик не ограничивал нас в стеке используемых технологий. Поэтому, заботясь о будущем развитии и поддержке проекта, мы построили горизонтально масштабируемое решение с использованием Postgres и Hadoop.
Сам Ad Exchange написан на Java — при этом мы не использовали никаких фреймворков, чтобы не проседать в нагрузке (работали на низком уровне).
Чтобы уложиться в упомянутый таймаут SSP, мы подбирали параметры garbage collector (использовался G1) и прорабатывали синхронную работу с большим количеством запросов — использовали HTTP-клиент, который не блокирует поток, а также расширение протокола HTTP keep-alive, позволяющее отправлять несколько запросов в рамках одного TCP-соединения.
Программные компоненты развернуты на арендованном у хостера железе, т.к. условия задачи не позволяли использовать облако из-за перекрытия ресурсов виртуальных облачных машин (выделение необходимых ресурсов может занять время, а у нас его нет). На данный момент Ad Exchange задействует четыре физических сервера, один из которых избыточный (для проведения бесшовных обновлений и т.п.).
В качестве message-брокера задействован опенсорсный Apache Kafka — он идеально встроился в нашу модель «one subscriber — many publishers», хотя его пришлось немного «докрутить» так, чтобы не приходили повторные сообщения.
Каждый из серверов обеспечивает в штатном режиме обработку порядка 10 тыс. запросов в секунду (эти параметры закладывались при разработке решения). Сейчас средняя нагрузка — 15—20 тыс. запросов в секунду, а в пиках поток запросов достигал 40 тысяч в секунду в течение нескольких часов, и Ad Exchange с этим прекрасно справился.
Распределение запросов между серверами осуществляет программный балансировщик нагрузки nginx, настроенный под нашу задачу. По нашему опыту, на nginx можно держать до 60—70 тыс. запросов в секунду, не выделяя отдельный аппаратный балансировщик. Если же в будущем нагрузка на Ad Exchange будет выше этого порога, мы планируем приобрести аппаратный балансировщик, который распределит запросы между несколькими однотипными nginx.
Контролирует происходящее, при условии постоянного роста нагрузки, система мониторинга, являющаяся частью созданного Ad Exchange.
Хранилище
Учитывая ставку на аналитику в ходе распределения запросов, база данных является неотъемлемой частью нашего Ad Exchange. Система хранит информацию о ставках, участниках аукционов и заключенных сделках.
Нет смысла собирать такой объем данных за весь период работы Ad Exchange, поэтому хранилище имеет многоуровневую архитектуру. Все данные об аукционах хранятся за неделю. На их основе строятся более высокоуровневые промежуточные агрегаты, которые хранятся несколько месяцев. А уже на базе промежуточных собираются конечные агрегаты, используемые в долгосрочной аналитике и для сверок с SSP и DSP. Среди прочей информации в этих агрегатах есть данные о том, сколько было сделано ставок и сколько денег биржа заплатит SSP или ожидает получить от DSP.
Конечные агрегаты хранятся в течение всего срока работы Ad Exchange.
Сбор аналитики и формирование агрегатов обеспечивают отдельные службы.
Чтобы хранилище соответствовало скорости работы самой системы, с ним также пришлось поработать. В частности, какое-то время мы воевали с хостером, т.к. данные о сделках просто не успевали записываться в базу. Выяснилось, что виной тому была аппаратная проблема с RAID-массивом. После его замены мы смогли выжать на Postgres 90 тыс. запросов в секунду (на вставке данных в базу).
Остальная часть Ad Exchange — stateless, что и обеспечивает в перспективе легкое горизонтальное масштабирование. Она не хранит никакие данные по запросам — максимум, полученные сведения о том, какой DSP надо выбрать. Так что мы сможем добавлять новые сервера для обработки запросов по мере необходимости.
Фильтрация трафика
Ключевой элемент системы, позволяющий снизить нагрузку и уложиться в обозначенные заказчиком таймауты, — это фильтрация трафика.
В соответствии с выполняемой задачей любой Ad Exchange:
- принимает запросы от SSP;
- проводит аукцион (рассылает запросы в несколько DSP, сравнивает предложенные цены, выявляет победителя);
- согласует с SSP победу (сообщает цену победителя за вычетом своей комиссии, дожидается ответа с итоговой ценой показа);
- завершает сделку (сообщает в нужный DSP о его победе, проводит пользовательский трафик).
Умное распределение запросов в нашем Ad Exchange включается на начальном этапе аукциона.
Получая запрос от SSP с определенной информацией (IP, user agent), мы детализируем его при помощи накопленных в системе сведений — известных данных о пользователе, перечня DSP, в которые отправлялись аналогичные запросы, их ответов и т.п. Это необходимо, чтобы выбрать наиболее выгодную комбинацию DSP под каждый запрос. Благодаря подбору такой комбинации система позволяет не посылать запросы в те DSP, которые не делают ставки или делают, но слишком низкие. Для этого отдельный сервис в режиме реального времени составляет карту того, как DSP отвечает на запросы (карты эти хранятся в Redis).
Параллельно мы проверяем состояние DSP — если доля ответов в рамках таймаута падает, система автоматически снижает количество запросов к этому DSP. Как только нагрузка на DSP снижается (а доля корректных ответов за приемлемое время растет), количество запросов постепенно возвращается на прежний уровень.
Среди DSP, ответивших вовремя, мы проводим внутренний аукцион — выделяем лучшее предложение и отсылаем его в SSP. С момента запроса от SSP до нашего ответа проходит не более 300 мс, в соответствии с отраслевым требованием.
Поскольку мы отдаем данные в SSP, где проводится свой аукцион, нам необходимо учитывать выигравшие там ставки. Их логированием занимается сервер аукциона уже на следующем этапе, при обработке пользовательского трафика. Благодаря ему карта ответов DSP обогащается новыми данными (вместе с собранной информацией о конечном пользователе).
Сопоставление данных, полученных на этапе аукциона, и параметров, известных из пользовательского трафика, позволяет отсеивать ботов (кликеров по рекламе, поисковых ботов и т.п.). Такой трафик не выкупается DSP, а при отсутствии собственной системы фильтрации он превращается в потери клиента, которые придется закрывать маржой.
Надо отметить, что фильтрация трафика ботов была запущена не сразу. Но после включения простых блокировок выигрыш по марже составил порядка 50%.
Кстати, помимо автоматических инструментов фильтрации трафика в нашей системе, предусмотрена возможность для заказчика вручную изменить пороговые значения ряда параметров, скорректировав таким образом маржу.
Сам пользовательский трафик для нас критичен, но при его обработке уже не обязательно укладываться в 300 мс. Здесь используется отдельная система обработки, которая может немного придержать пользователя, но не даст потерять этот запрос.
Для обеспечения стабильности решения была внедрена подсистема, которая, понимая текущую загрузку Ad Exchange, «обрезает» запросы на аукционы, которые она физически не может обработать. Так система защищается от неконтролируемого роста нагрузки со стороны SSP.
Перспективы
На сегодняшний день созданный нами Ad Exchange работает и приносит неплохую прибыль. А мы осуществляем поддержку и интеграцию новых партнеров (DSP/SSP) по необходимости. В общей сложности уже интегрировано несколько десятков систем. Каждая такая интеграция подразумевает не только программное подключение, но и всестороннее тестирование сервиса, ведь в условиях больших нагрузок проблемы подключенного сервиса могут отразиться на других партнерах.
В целом рынок движется к тому, что SSP и DSP будут соединяться напрямую, что сделает биржи ненужными. Но интеграция упирается в возможности SSP и DSP. Несмотря на существование открытого описанного API (протокола OpenRTB), он пока не является общепризнанным на рынке. К примеру, такой крупный игрок, как Appnexus, интегрировал поддержку OpenRTB совсем недавно.
По сути Ad Exchange — это провайдер ликвидности. Так что решение в ближайшее время вряд ли потеряет свою актуальность. Тем более что на остальном рекламном рынке биржевая модель только набирает популярность.
Автор статьи: Николай Еремин
P.S. Мы публикуем наши статьи на нескольких площадках Рунета. Подписывайтесь на наши страницы в VK, FB или Telegram-канал, чтобы узнавать обо всех наших публикациях и других новостях компании Maxilect.
