Система управления баннерной рекламой

Анатолий Филин: Добрый день, Артем!

Если вспомнить историю нашей компании, то самым первым нашим проектом была разработка большой партнерской баннерной сети для японской компании ValueCommerce. Мы сделали успешную систему, и в какой-то момент компания-заказчик вышла на IPO (публичное размещение). В настоящий момент компания ValueCommerce успешно функционирует ее акции торгуются на Токийской фондовой бирже.

Также одним из значимых для нас проектов стала система статистики для баннерной рекламы, которая была сделана для движка
DoubleClick по заказу IMHO VI. Это достаточно известный американский движок, сам бизнес DoubleClick несколько лет назад был куплен Гуглом. Сам движок всех устраивал, а вот фронт-энд и, в особенности, статистика были достаточно примитивны, поэтому мы их написали с нуля. Этот проект активно развивался, в последующих версиях была добавлена функциональность для рекламных агентств, а также реализован модуль пост-клик анализа, который позволял отслеживать поведение пользователей после их перехода на сайт рекламодателя.

В данный момент, мы разрабатываем достаточно крупную систему, проект который идет уже не первый год и продолжает развиваться – это баннерная система для известной в Рунете компании HeadHunter. Компания HeadHunter занимается рекрутингом, и ей принадлежит довольно много сайтов: основной сайт с большим числом посетителей и большим числом показов, региональные сайты, а также всевозможные проекты («Карьера.ру», «Портал образование» и другие). На всех этих площадках HeadHunter зарабатывает деньги; происходит это не только при помощи основного бизнеса компании, но и благодаря рекламе. В настоящий момент наша баннерная система обслуживает все сайты HeadHunter Group, а также сайт Rabota.Mail.ru, который сделан на движке HeadHunter.

У нас достаточно большой опыт аналитики в области баннерных систем; мы делали Техническое Задание для видео-баннерки, а также нескольких систем, связанных с контекстной рекламой. Кроме того, у нас есть несколько проектов, про которые мы в данный момент не можем говорить, поскольку они еще находятся в стадии разработки.

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

Итак, сделанная нами баннерная система для ValueCommerce выделяется как самая крупная и высоконагруженная; на тот момент, когда мы прекратили ее разрабатывать, в ней было порядка 1 млрд. показов в день. В нашей «копилке» есть разные баннерные проекты: они отличаются по масштабу и специфике. Естественно, наших клиентов будет интересовать следующий вопрос: насколько наш опыт как разработчиков баннерных систем, может быть использован на их конкретном проекте?

Артем Вольфтруб: Здравствуйте, Анатолий!

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

Баннерная система, сделанная для компании ValueCommerce, имеет ряд уникальных особенностей. Во-первых, в этой системе присутствовали такие объемы данных, которых нет ни в одной из существующих в России баннерных систем. Это, разумеется, накладывает, определенные ограничения на архитектуру системы. Кроме того, бизнес модель компании была основана на комиссии с конечных продаж
(CPA), а не на показах и кликах, как это обычно бывает сегодня в России. Система отслеживала факт совершения покупки на конечном сайте рекламодателя, а потом связывала его с кликом на определенный баннер на определенной площадке для того, чтобы потом выплатить комиссию этой площадке и получить свою долю. От эффективности работы этого алгоритма напрямую зависел доход компании.

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

Кроме того, стоит сказать пару слов о существовавшем в системе ValueCommerce биллинге. Он был достаточно сложным, поскольку по завершению отчетного периода необходимо было учесть все события, выставить счета рекламодателям, а также — заплатить комиссию площадкам. Размер комиссии не был фиксирован, а зависел от многих факторов: категория площадки, вид товара, объем продаж и т.п. Кроме того, нужно было учитывать товары, которые вернули обратно в магазин, исключив эти покупки из расчета комиссии.

Анатолий: Биллинг – один из очень важных компонентов для любой системы; через него проходят денежные средства. Однако, мне кажется, что мы немного отклонились от описания структуры баннерки в сторону back-office. Давай поговорим про другие системы. Какова специфика баннерки, созданной для HeadHunter?

Артем: Если смотреть на баннерку, сделанную для HeadHunter, то она как раз ориентирована на продажу показов и кликов
(CPM, CPC), и этим она кардинальным образом отличается от системы ValueCommerce.

В случае продажи показов (CMP) важен общий трафик площадки (количество посетителей), тогда как в случае продажи кликов (CPC), важно отношение числа кликов к общему числу показов (CTR – click through rate), именно по этому показателю оценивается эффективность работы площадки, поэтому важно демонстрировать рекламу именно тем людям, которым она максимально интересна; здесь на первый план выходит таргетирование.

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

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

Анатолий: С таргетированием и бизнес моделью все более или менее понятно. Но таргетирование это скорее дополнение к ядру системы. Есть ли какие-то существенные отличия в движке показов?

Артем: Да, сам движок показов, или Banner Engine, как мы его называем, – в обеих системах похож. Конечно, определенные отличия есть, но сам механизм обработки запроса на показ, выбора баннера и учета статистики очень похож. Серверу приходит запрос, содержащий параметры рекламного места – это идентификатор, информация о пользователе, если она есть, и какие-то другие параметры, затем запрос обрабатывается и в ответ сервер возвращает готовый html-код баннера или метаданные, содержащие информацию о том, откуда загрузить картинку, куда направить пользователя в случае клика, как фиксировать факт показа баннера и т.п.

Анатолий: Если говорить о баннерной системе в целом, какие компоненты должны в ней присутствовать?

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

Анатолий: Давай поговорим о технологиях, которые мы используем в баннерных системах. Часто разговор с потенциальными клиентами начинается с вопроса: «На чем вы собираетесь писать?». Существует распространенное мнение о том, что программы, которые должны работать максимально быстро, нужно писать на языке C или C++. Я со своей стороны могу сказать, что первый баннерный движок, в написании которого я принимал участие, был написан на Perl. Потом, через какое-то время, когда нагрузки стали увеличиваться, Perl перестал справляться. Все, что мы сейчас делаем в области баннерных систем, пишется на Java. Артем, есть ли у тебя, как руководителя разработки, какие-либо предпочтения с точки зрения выбора языка программирования? Можно ли сказать, что есть оптимальные языки для написания баннерных систем, или это все равно – на чем писать?

Артем: Мне кажется, что этот вопрос не имеет прямого отношения к баннерным системам, его можно применить к любому высоконагруженному проекту. Есть несколько факторов, которые нужно учитывать при выборе технологии. Самый основной состоит в том, что наиболее оптимальным языком разработки является тот, на котором команда, разрабатывающая систему, умеет качественно и быстро писать. Еще одним фактором является стоимость владения и поддержки. Можно написать код, который будет на 3%, на 5%, и даже на 10% работать быстрее, аналогичный код на другом языке, но при этом стоимость поддержки, которая складывается из стоимости поиска сотрудников, времени, необходимом на внесение изменений, сложность тестирования и т.п., будет в несколько раз выше.

Для баннерной системы важным критерием является ее способность к масштабированию. Если сервер, который мы написали, легко масштабируется и относительно легко модифицируется, то язык программирования, отходит на второй план.
Если говорить про сделанные нами баннерные системы, то они все разработаны на Java. При этом, они прекрасно работают и легко масштабируются. Система, сделанная для ValueCommerce, «обрабатывала» порядка миллиарда событий в день, в случае системы HeadHunter – порядка ста миллионов показов. Это достаточно серьезные цифры.

Анатолий: Но все же, если посмотреть на производительность отдельно взятого сервера, то как на нее влияет выбор языка программирования? Можно ли, например, сказать: «C на 20% лучше, чем на Java»? Или наоборот?

Артем: Чтобы ответить на этот вопрос, нужно «написать» два одинаковых сервера — один на Java, а другой — на C, и протестировать их на одинаковых данных. Мне кажется этого никто никогда не делал, да это и невозможно, поскольку конечный код все равно будет разным. На мой взгляд, всегда нужно отталкиваться от конкретной задачи, например, обрабатывать запрос на показ баннера максимум за 100 миллисекунд. Эту конкретную задачу можно решить как на Java, так и на С. Подозреваю, что ее также можно решить и на PHP и на Perl. Но, конечно не стоит забывать про такой показатель, как число запросов на показ в единицу времени (обычно в секунду).

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

Артем, скажи, а на какой операционной системе должна работать баннерная система: Windows? Unix?

Артем: Я давно не видел, чтобы высоконагруженная система работала на Windows-сервере. Обычно, если система работает на Windows, это связано с какими-то корпоративными правилами: политикой компании, лицензиями, или скидками, которые дает Microsoft. Я не знаю статистику по Fortune 500, но если брать российский крупный интернет-бизнес, с которым мы, как компания, сталкивались, то все используют Unix подобные операционные системы для промышленной эксплуатации.

Анатолий: Ну я боюсь, теперь к нам ПРИДУТ апологеты Microsoft . Ладно, давай немного поговорим про развитие баннерных технологий. Если смотреть на последние проекты нашей компании и вообще на то, как эволюционирует «баннерная экосистема», то мы наблюдаем, что последние пять лет на Западе и в последние года два в России происходит резкое усложнение баннерной инфраструктуры. Происходит переход в сторону технологий под «кодовым названием» Real Time Bidding.

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

Артем: Начнем с того, что в современном мире, где крупные интернет-игроки уже давно сформировались, сделать с нуля новую баннерку, которая способна привлечь большое число клиентов, довольно непросто. Основная сложность состоит не только в технологии, но еще и в привлечении трафика (площадок), которые всегда в большом дефиците, сейчас особенно.
Если посмотреть на те проекты, в которых мы принимали участие, то система ValueCommerce создавалась в момент, когда рынок еще не был сформирован, в результате удалось подключить к системе нескольким сотен тысяч площадок, что обеспечило достаточный трафик. Особенность системы, разработанной нами для компании HeadHunter состоит в том, что они продает рекламу только на своих площадках, достаточно узкой тематики. У них есть неплохой по меркам рунета объем трафика и задача его увеличения не является приоритетной.

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

С другой стороны, площадки, которые генерируют трафик, часто не могут полностью продать его рекламодателю: возникаю паузы между рекламными компаниями, остается трафик с «непопулярными таргетингами» и т.п. Естественно, площадки хотят продавать весть трафик, в том числе и остаточный. Если сложить весь остаточный трафик с нескольких площадок, получится достаточно большой объем.

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

Анатолий: Артем, мне хотелось бы услышать, что нам принесло RTB с технологической стороны? .

Артем: Если в «традиционной баннерке» можно выделить четыре основных компонента, о которых я говорил (баннерный сервер, система управления рекламными кампаниями, модуль обработки статистики и модуль синхронизации), то в RTB есть два больших блока SSP (Sell Side Platform) и DSP (Demand Side Platform). SSP включает в себя баннерный сервер, модуль аукциона, систему управления подключенными площадками, модули синхронизации и статистики. DSP состоит из системы управления рекламными кампаниями, движка взаимодействия с аукционом, включающего интеллектуальный модуль выбор рекламы для с учетом вероятности клика, таргетингов и лимитов и цены показа, а также, по аналогии с SSP, подсистемы статистики и синхронизации.

Взаимодействие между DSP и аукционом осуществляется по протоколу Open RTB. Важно отметить еще один момент, связанный с бизнес моделью. DSP всегда платит SSP за показ, а своим рекламодателям продает клики (CPC) или покупки (CPA), поэтому ключевым в работе DSP является модуль прогнозирования, который должен определить, какие показы с большей вероятностью приведут к клику или продаже.

Анатолий: То есть, то, что мы делали раньше – теперь переехало в зону SSP?

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

Анатолий: Аукцион баннеров – явление, я думаю, интересное.

Артем: …но достаточно простое. В целом, если говорить про подобные системы – их сложность не в большом количестве бизнес-правил и строк кода, а в том, что они должны работать быстро и надежно. Также и с аукционом: логика его проведения довольно проста: опрос всех подключенных DSP-систем и выбор победителя по достаточно простому алгоритму.

Конечно, модуль SSP это не только аукцион. Там есть и дополнительная функциональность, например, некоторые площадки хотят оставаться анонимными для рекламодателя, чтобы не афишировать свое присутствие на аукционе. Также есть взаимодействие с модулем anti-fraud для отсечения паразитного трафика, обогащение данных запроса дополнительной информацией о пользователей, получаемой из внешней системы (DMP – Data Management Platform), различные настройки для подключенных DSP (некоторые SSP системы передают подключенным DSP лишь часть имеющейся информации, а дополнительные данные предоставляют за отдельную плату) и многое другое.

Анатолий: По всей видимости, систем RTB не может быть слишком много. Так например, торговля акциями происходит на финансовых биржах, их не так мало, но и не так много. И всего нескольких крупнейших: Лондонская биржа, и биржи в Нью-Йорке и Токио. В Москве было две биржи, но даже двух оказалось много и они объединились. По-видимому, и RTB-систем должно быть на порядок меньше, чем просто баннерных систем. RTB-систему может позволить себе, я думаю, только очень крупная компания.

Артем: Насколько я знаю, в России сейчас работает две RTB-системы, одну сделал Яндекс, вторую AdFox. Еще несколько подобных систем в разработке и должны появиться через какое-то время. Конечно, их будет не очень много. Я уже упоминал о проблеме нехватки трафика. В случае RTB все то же самое, число площадок не бесконечно, на всех их не хватит.

Анатолий: Понятно. Тогда логично, что Яндекс, будучи крупнейшим российским медийным ресурсом по объему «инвентаря», создал RTB у себя.

Артем: Конечно. Яндекс как раз с удовольствием подключает любые DSP-системы к своей бирже.

Анатолий: Хорошо. Если смотреть на другие компоненты, которые представлены на этой диаграмме — все, что касается SSP Core, то есть, ядро SSP-системы – мы делали и неоднократно. Менеджер сайтов и компаний управления сайтами-компаниями – тоже; имели дело и с anti-fraud системами. А что на данной диаграмме означает «мониторинг»?

Артем: В разных ситуациях «мониторинг», конечно, означает разное. В данном конкретном случае, речь идет о мониторинге бизнес-метрик. Главная его идея состоит в том, что определенная часть запросов на показ, которые приходят в SSP в Banner Engine – «пробрасываются» в систему мониторинга, которая на основании полученных данных может сигнализировать о потенциальной проблеме, например, резком уменьшении числа показов или кликов, что говорит о проблемах на какой-то из площадок или увеличении паразитного трафика (проблемах с модулем anti-fraud) соответственно.

Анатолий: На диаграмме изображены прямые рекламодатели, да?

Артем: Да. Тут речь идет о площадках, у которых есть собственные рекламодатели, которым они продают рекламу напрямую, используя RTB систему как обычную, «традиционную» баннерку.

Анатолий: Достаточно типичная для России история. Артем, выше ты сказал, что, баннерные системы – это не очень сложная вещь. А с чем ты сравниваешь?

Артем: Я имел ввиду следующее: с точки зрения объема кода и логики работы, баннерные системы – это не очень сложная вещь. С точки зрения реализации она, конечно, непростая.

Анатолий: Насколько я помню, свою первую баннерку для ValueCommerce мы сделали правильно все-таки не с первого раза. Работа по оптимизации всех компонентов под высокие нагрузки заняла несколько лет. Это был ценный опыт. Но все же, мог бы ты рассказать, какие, по твоему мнению, сложные моменты для разработчиков и архитекторов действительно присутствуют в баннерке. Где пришлось, так скажем, «поломать голову»?

Артем: В каждой из есть свои «изюминки». Если, например, смотреть на систему, созданную нами для компании HeadHunter, то основная сложность баннерного сервера там заключалась в сложных правилах таргетирования и лимитах.

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

Есть еще одна интересная задача, которая в данный момент находится у нас в разработке, это – прогноз показов с учетом таргетингов. Сейчас все рекламодатели хотят еще до начала рекламной кампании оценить объем инвентаря, охват аудитории и т.п., причем этот прогноз нужно делать «на лету», с учетом выбранных параметров таргетирования и параллельно идущих рекламных кампаний. Все это достаточно непросто, но без этого современную баннерку уже практически невозможно представить. Также интересной задачей является автоматические изменение приоритетов показа по отдельным баннеров, с учетом статистики по кликам, чтобы баннеры, у которые более высокий CTR получали наивысший приоритет.

Анатолий: Спасибо большое за интервью, Артем! До новых встреч в эфире

Артем: Спасибо вам!