Кейс: как заработать сотни тысяч долларов на перепродаже трафика в программатике (RTB)

В отсутствие прямой интеграции SSP (supply-side platform) с DSP (demand-side platform), при известных неурегулированности и непрозрачности рынка в целом, посреднический бизнес автоматизированной биржи Ad Exchange может принести хорошие доходы. И сегодня это огромный рынок, где в цепочку доставки рекламного объявления от рекламодателя (advertiser) до издателя (publisher) встраиваются звенья-посредники. Учитывая высокую конкуренцию между ними за свою долю заработка, успех посреднической деятельности напрямую зависит от технической реализации биржи Ad Exchange и идей в основе ее бизнеса.

Так каким образом можно заработать сотни тысяч долларов США?

Совсем недавно мы участвовали в проекте для рынка США, где как раз реализовывали функционал биржи Ad Exchange, осуществляющей автоматическую перепродажу трафика между SSP и DSP, не имеющими прямой интеграции. Мы довольно глубоко погрузились в тему программатик RTB и сформулировали для себя, что ключом к запуску проекта для извлечения доходов из схемы перепродажи трафика являются несколько моментов.

Первое – понимание бизнес-модели аукциона. Что именно будет критерием успеха? Это будет фильтрация и таргетинг трафика? Реализация закрытого аукциона для “избранных”? Доставка трафика, к которому у данного DSP нет доступа (например, из-за отсутствия поддержки протокола OpenRTB, что все еще встречается на рынке)?

В реализованном нами проекте для извлечения прибыли оказалось достаточно анализа данных о предыдущих сделках. Благодаря заложенному алгоритму система не посылает заведомо бессмысленные запросы в те DSP, которые на аналогичные запросы ранее не отвечали или давали слишком низкие ставки. Кроме того, мы обеспечили фильтрацию ботов (порядка 70% трафика). Этот функционал появился уже после проверки первоначальной гипотезы о работоспособности идеи перепродажи, и по предварительным оценкам он может увеличить маржу на 50%. В нашем решении параметры всех фильтров доступны клиенту из панели управления, что позволяет подстраиваться под рынок.

Теоретически трафик может обогащаться иным образом, например можно внедрить таргетирование по различным параметрам из DMP (data management platform). Кстати, независимые DMP-платформы активно развиваются, агрегируя все новые данные аудитории, что позволяет строить все более сложный таргетинг, в зависимости от потребности рекламодателя. Мы как раз завершили такой проект для американского заказчика (до этого управление сегментами данных шло на стороне AppNexus).

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

Второе – договоренности бизнеса с SSP и DSP. На наш взгляд, это один из основных элементов, определяющих успех проекта. Очевидно, что различные системы предлагают и закупают разнородный трафик, поэтому нужно выбрать такое сочетание SSP и DSP, где интересы продавца и покупателя хоть в чем-то перекрываются, но при этом они не интегрированы напрямую. И от того, насколько это востребованная ниша, будет зависеть итоговый доход.

Разумный подход – интеграция с несколькими SSP и DSP для увеличения количества показов. Например, наш клиент на старте интегрировал два DSP и четыре SSP, а позже число партнеров было доведено до 20. А мы со своей стороны реализовали механизмы балансировки количества запросов к партнерам в единицу времени, чтобы не перегружать их системы.

Третье – техническая грамотность команды. Об интеграциях надо не только договориться, но и не потерять их из-за технических проблем реализованной биржи. Как уже упоминалось выше, система чувствительна к времени ответа. При этом доход напрямую зависит от потока поступающих запросов.

К примеру, в проекте нашего клиента на этапе MVP биржа получала в день порядка 245 млн запросов (это эквивалентно примерно 2,800 QPS, т.е. операций в секунду). Показами заканчивается около 0.3% запросов, а доход от 1,000 показов – порядка 10 - 50 центов. В день при таком объеме запросов общий доход сервиса на этапе MVP составлял около от 50 до 300 долларов США.

После интеграции с новыми партнерами число операций в секунду возросло до 30,000. Вырос и доход, так что заказчик вышел на очень комфортные уровни прибыли.

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

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

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

Стоит отметить, что бесперебойная работа под нагрузкой определяет и требования к “железу”. В нашем проекте для обеспечения бесперебойной работы брались в аренду выделенные сервера (Dedicated servers) в дата-центре США (порядка 1,5 тыс. долларов США в месяц).

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

К сожалению, не всегда человек, погруженный в программатик RTB, имеет техническую экспертизу, достаточную для принятия такого решения самостоятельно. И вот здесь снова решающую роль играет качество команды, реализующей техническую часть.

В прошедшем проекте мы представили работающий прототип за три месяца, а MVP - за шесть месяцев. При этом система поддерживала только базовый функционал для ответа на вопрос, можно ли заработать за счет оптимизации запросов к DSP через анализ предыдущих сделок.

После получения подтверждения, что аукционная модель работает, “допилили” системы, позволяющие повысить прибыль, – фильтрацию бот-трафика, нормальную ежедневную отчетность для SSP и DSP (количество запросов, показы, стоимость), сбор метрик о работе сервиса – о нагрузке на сервера, задержках ответов из и в системы партнеров и т.п.

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

Пятое – курс развития технического решения. Рынок меняется, постоянно появляются новые игроки, более хитрые боты и т. п. С другой стороны, заметна тенденция усиления борьбы основных игроков с трафиком ботов и поддельным инвентарем (фродом). Если упустить ситуацию, например допустить больший процент бот-трафика, который будет отфильтрован уже на уровне партнеров, придется смириться с сокращением доходов, а может, и разрывом партнерских отношений. Поэтому для планирования работы решения в долгосрочной перспективе (а это необходимо для окупаемости) следует задумываться о курсе дальнейшего развития.

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

Сочетание компетенций, позволяющее собрать все упомянутые моменты в одном проекте, встречается не так часто, как и сами проекты бирж Ad Exchange, приносящие стабильный доход. Но заказчик упомянутого решения за год эксплуатации созданной системы получил доход порядка 500 тыс. долларов США.

Мы верим, что на этом рынке есть место для самых разных идей, и можем предложить свою техническую экспертизу. С учетом этого и других Ad Tech проектов мы готовы рассматривать разные модели взаимодействия, например revenue sharing, где клиент становится партнером и достигается договоренность об обязательствах и % по разделению дохода. Технологическое решение при этом мы могли бы запустить за 3–6 недель, в зависимости от количества и сложности интеграций на старте. Таким образом в сотрудничестве с нами можно быстро и сравнительно дешево проверить новую модель биржи Ad Exchange для конкретных SSP и DSP еще до запуска полноценного проекта.

Автор статьи: Максим Коротков, генеральный директор Maxilect

Обсудим детали?

PS. Мы возвращаемся к регулярным публикациям в блоге компании на VC, где будем рассматривать особенности рынков, подходы к продажам и прочие бизнес-темы. Наши технические статьи вы можете найти в блоге на Хабре. Следите за нашей активностью в социальных сетях: VK, FB и подписывайтесь на Telegram-канал.