Anatomy of banner system


Анатомия баннерной системы

This talk deals with a banner platform and its components and based on our experience of developing at least three high-performance banner systems. The major topics include principles of efficient display of banners, banner view limits and architectural structure and limitations of banner platform. Much attention is paid to synchronization of data between various system components. We also consider some issues related to banner platform statistical component: statistics that banner system can collect; dealing with large amount of data especially on unique clicks; methods of analysis of advertising campaigns efficiency. We also touch upon the issue of false clicks and police tools, system monitoring, as well as support and maintenance of typical banner system.

Кто: Artem Volftrub
Где: HighLoad 2011
Когда: October 3-4, 2011

abs_01


Артем Вольфтруб:
Добрый день!

Меня зовут Артем Вольфтруб, я руковожу работой компании «Грамант». Сегодняшний доклад будет посвящен баннерным системам. Так сложилось, что в последнее время, в нашу компанию регулярно обращаются клиенты по вопросам, связанным с созданием баннерных систем. Несколько больших систем мы уже сделали, в других случаях консультировали наших клиентов. В результате, у нас накопился некоторый опыт, которым мы бы хотели поделиться с вами.

К слову, несколько систем, которые мы сделали в последнее время:

value_commerce

• Система онлайновой рекламы с отслеживанием продаж

• 700 000 000 (семьсот миллионов) показов в день

• Модель ориентированная на продажи

• Собственная разработка с нуля

logo-imhovi

• Баннерная система для компании IMHO VI

• 50 000 000 (пятьдесят миллионов) показов в день

• Решение построенное на базе DoubleClick DART Enterprise

• Расширенная система статистики

HH

• Система управления баннерной рекламой для группы компаний HeadHunter

• 85 000 000 (восемьдесят пять миллионов) показов в день

• Полностью наша разработка от формирования требований до внедрения

• Инструменты медиапланирования

• Гибкая система таргетирования

• Лимиты

Давайте для начала посмотрим, как на самом примитивном уровне устроена баннерная система. Условно ее можно разделить на три компонента: баннерный сервер, система управления рекламными кампаниями (UI) и модуль статистики.

abs_system

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

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

abs_04

Тем не менее, принципиально состав основных модулей от этого не изменится.

Давайте сначала немного отойдем от технических деталей и поговорим о бизнес-моделях, баннерных систем. Их три.

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

Следующий распространенный тип бизнес-модели – продажа интереса посетителей. Тут важен не только факт показа, но и посетитель, который видит рекламу. Эффективность таких рекламных кампаний в конечном счете отслеживают по динамике продаж, поэтому к выбору аудитории нужно подходить особо тщательно. Очень часто в этом случае продают даже не показы, а клики.

Третий тип, который, насколько я знаю, в России практически не представлен – когда продается «продажа». В этом случае баннерная система должна уметь отслеживать факт покупки и связывать его с показом и кликом. При этом сами показы и клики могут не стоить ничего.

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

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

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

Давайте теперь подробно рассмотрим технические особенности каждого из компонентов баннерной системы.

Начнем с основного компонента – модуля показа баннеров (баннерного сервера).

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

Какие же требования предъявляются к баннерному серверу?

1. Простота. Чем проще логика его работы, тем лучше, потому что это уменьшает вероятность сбоев и увеличивает скорость, что является критичным для нас.

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

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

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

5. Принцип «не молчать». В любой ситуации баннерный сервер должен возвращать какой-то результат в ответ на запрос. Это нужно для того, чтобы пользователи или системы, которые ожидают ответа от вашего сервера, всегда понимали что происходит, даже если произошла ошибка и вы не можете показать им баннер.

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

Есть две стратегии обновления баннерных серверов. Одна, «Pull-стратегия», состоит в том, что сервера получают данные по активным рекламным либо из базы данных, либо от какого-то промежуточного компонента, API и т. п.

abs_10

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

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

К незначительным минусам push-стратегии, на наш взгляд, можно отнести необходимость регистрировать каждый новый баннерный сервер в модуле синхронизации. Кроме того сам модуль синхронизации представляет собой единую точку отказа (Single point of failure). Впрочем, достаточно легко настроить мониторинг модуля синхронизации, а также обеспечить автоматической восстановление после сбоев.

abs_11

Говоря о синхронизации необходимо сказать, что она бывает двух видов: полная и инкрементальная.

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

Скажу пару слов про хранение медиа-данных. Есть два варианта хранения.

Первый – когда вся информация хранится в файловой системе самих баннерных серверов. Это достаточно простой вариант, который к тому же добавляет им независимости. В процессе синхронизации мы выгружаем файлы баннеров на сервера и складываем их определенным образом. В этом случае можно использовать стандартные средства Unix.

Второй вариант – отдельное хранилище. В этом случае мы храним весь контент на отдельной машине, общаясь с ним по одному из стандартных протоколов (ftp, webdav и т.п.). Единственная дополнительная работа, которая потребуется в этом случае, – поддержать необходимый протокол в модуле синхронизации, что, впрочем, достаточно просто. Дополнительным плюсом такого подхода является уменьшение объема данных на каждом из баннерных серверов, возможность кластеризации хранилища или использование CDN, который обеспечит быструю доставку контента посетителю, что особенно актуально в случае видеорекламы.

Давайте теперь перейдем к вопросу о лимитах. Эта тема возникает всегда, когда мы когда мы говорим о системе, которая «продает интересы посетителей». Рекламодатель заинтересован в том, чтобы его рекламу увидело как можно большее число потенциальных клиентов, поэтому он хочет ограничить число показов рекламы одному посетителю, а также установить суточный лимит показов, чтобы обеспечить определенную продолжительность рекламной кампании. Баннерная система в этом случае должна очень внимательно следить за динамикой показов и отключать исчерпавшие лимит рекламные кампании, поскольку все лишние показы не будут оплачены клиентом. Естественно, менеджеры хотят чтобы лишних показов не было совсем, разработчики, понимая, что это сильно усложняет архитектуру системы, начинают торговаться с ними, выясняя, какая задержка допустима и нельзя ли сойтись на каком-то компромиссном варианте.

Важно понимать, что существует два типа лимитов: лимиты, которые устанавливаются на уровне рекламной кампании (число показов или кликов в день и общее число показов или кликов за рекламную кампанию) и лимиты, которые устанавливаются на уровне посетителя (показать определенный баннер не более чем N раз каждому посетителю). Разные типы лимитов требуют разный подход к реализации.

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

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

Второй подход к реализации лимитов состоит в использовании общего кэша (key – value storage) для хранения информации об актуальном значении лимитов. Такой подход позволит нам иметь актуальные данные. То есть, в момент обработки запроса мы получаем текущее значение лимита и увеличиваем счетчик показов. Все баннерные сервера работают с одним хранилищем (возможно распределенным), получая актуальную информацию. Такой подход избавляет нас от перекруток, но добавляет дополнительную точку отказа, как правило данные хранятся в памяти и будут потеряны в случае любого сбоя. Дополнительная проблема состоит в необходимости синхронизировать данные в кэше со статистикой, в какой-то момент времени эти данные могут разойтись по ряду причин.

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

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

Второй момент состоит в том, что нужно стараться ограничивать число параметров таргетирования; ведь чем больше параметров, тем сложнее их осуществлять выбор по ним.

Ну и, разумеется, нужно договорится о том, на чьей стороне определяются значения параметров таргетирования для конкретного запроса. Ни в коем случае нельзя допускать ситуацию, когда вам говорят: «пришел запрос от посетителя, там есть IP-адрес. По IP-адресу определите регион, и сделайте таргетинг по региону». Это очень плохая ситуация. Баннерный сервер должен получать уже готовые значения параметров таргетирования в момент поступления запроса на показ баннера. Иначе драгоценное время будет потрачено неэффективно.

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

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

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

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

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

Как автоматически изменять вес баннера так, чтобы обеспечить необходимое число показов или так, чтобы показывать наиболее эффективные баннеры (баннеры с высоким CTR – click through rate)?

В этом случае очень важно смотреть не только на текущее значение CTR, но и на динамику за период (CTR за период), чтобы очень старые данные не влияли на выбор.

Перейдем к разговору о статистике.

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

Если посмотреть на соотношение объемов данных, в системе, которая ежедневно обрабатывает 50 000 000 запросов на показ, объем данных статистики по уникальным посетителям примерно в 2000 раз больше, чем объем простой статистики. Это происходит потому, что данные без идентификаторов посетителей легко агрегируются (сворачиваются) по рекламному месту, в одной строке базы данных. В случае уникальных посетителей сделать этого не удастся. Ежедневное увеличение объема данных в этом случае составляет 30-40 тысяч записей для простой статистики и 6-8 миллионов для статистики по уникальным посетителям. Такой объем данных требует дополнительных манипуляцией с базой данных, например, регулярного партиционирования, архивации старых данных и т.п., в противном случае система очень быстро станет неработоспособной.

Зачем же всем так нужна статистика по уникальным посетителям?

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

Давайте рассмотрим несколько моментов, связанных с обработкой статистики:


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

2. Для загрузки данных в СУБД лучше использовать стандартные средства (SQL Loader Orcale, COPY в PostgreSQL и т.п.), которые значительно сокращают время загрузки. Для этого, возможно, потребуется предварительная обработка данных статистики, приведение их к специальному формату.

3. Простую статистику и статистику по уникальным посетителям нужно хранить в разных базах данных (или разных partition), желательно на разных физических машинах.

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

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

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

Теперь немного поговорим про мониторинг.

Основные преимущества, которые мониторинг дает вашей системе хорошо известны:

Прогнозирование нагрузки

Диагностика проблем на ранней стадии

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

abs_34

В нашей практике мы используем три вида мониторинга:


• Мониторинг на физическом уровне – доступность сервера, CPU, память, свободное место на диске, и другие параметры.


Мониторинг на уровне приложений – ответы HTTP, актуальность баннеров, актуальность статистики, размер очередей и т. п.


Мониторинг на уровне бизнес-метрик – учитывает логику приложения, например, это может быть среднее число обработанных запросов системой за период в сравнении с историческими данными, процент CTR, динамика изменения значений параметров таргетирования и т. п.

В качестве инструментов мониторинга мы используем Nagious, для которого мы разрабатываем набор необходимых критериев. Помимо этого используются тренды Cacti, журналы Tenshi, графики для анализа логов и прочее.

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

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

Спасибо за внимание!

Если у вас возникли вопросы – обращайтесь!

pishite@gramant.ru