Анатомия RTB

Владимир Климонтович

Real time biding

Old school

Проблемы• Финальный исход зависит от порядка ad

networks в цепочке • Большой размер цепочки замедляет

загрузку страницы

RTB! (new school)

Аукцион второй цены• Выигравший участник платит вторую цену +

delta (1 цент, 1 копейка)• Если участник один, оплачивается

минимальная цена (floor cpm) + delta• Аукцион второй цены стимулирует

участников называть реальную цену• Время ответа: 100ms

Основные субъекты рынка• SSP (Sell Side Platform) – обслуживает

интересы площадок• DSP (Demand Side Platform) – обслуживает

интересы рекламодателей• DMP (Data Management Platforms/Data

Exchange) – собирает данные о пользователе

SSP• Обслуживает интересы площадок

размещения (сайтов)• Технологически проще DSP• По сути, одинаковая бизнес-модель у всех

SSP

DSP• Обслуживает рекламодателей• Сложнее чем SSP• Разные бизнес модели: retargeting, search

retargeting, audience targeting• Разные модели оплаты: pay-per-click, pay-

per-conversion

Retargeting• Показываем рекламу только тем

пользователям, которые уже были на сайте рекламодателя

• По статистике, вероятность конверсии может вырасти с 0.005% до 0.9%

Audience targeting• Показываем объявления только

заинтересованной аудитории• Например, показываем рекламу новой

Honda посетителям автомобильных сайтов• Данные можно брать свои, можно покупать

у DMP

Pay-per-click/pay-per-conversion• Рекламодатель платит DSP только в случае

совершения пользователем целевого действия (клик, конверсия)

• DSP всегда платит SSP за показы• Вывод: DSP должна хорошо уметь

оценивать вероятность клика/конверсии

Cookie sync

Cookie sync – проблема• До RTB-эры пользователей

идентифицировали по cookie• Но DSP и SSP “живут в разных доменах”

Cookie sync – проблема

Cookie sync – решение (sync pixel)

Match table

• Порядок: 10-100 млн строк• В идеале хранится на стороне SSP, но не

всегда

SSP User Id DSP User ID

10:22741675 03goMw3rI64

Виды cookie sync• Инициированный SSP• Инициированный DSP

Что еще?• До RTB-эры данные о пользователе (частота

показов, посещенные сайты) хранились в cookie

• Cookie sync обеспечивает только синхронизацию ID. Остальное нужно хранить в БД на стороне DSP (NoSQL )

Под капотом RTB

Основные проблемы• HTTP-нагрузка (тысячи входящих и

исходящий HTTP-запросов в секунду)• Хранение и анализ логов (10-100Gb в день)• Online хранилища (match table, user table)• Machine learning: алгоритмы предсказания

кликов/конверсий

HTTP-нагрузка• Средняя SSP: 5 000 входящих, 20 000

исходящих запросов в секунду• Средняя DSP: 10 000 входящих запросов в

секунду

HTTP-нагрузка, что делать?• Не боятся!• Использовать Java/C++, остерегаться Python

и PHP• Использовать event-driven подход, lock-free

синхронизацию и т.д.

HTTP-нагрузка: библиотеки• Java: akka, NIO, Netty• C++: libevent, libev

И последнее: RAM и только RAM!

Храним в памяти• Все рекламные кампании, таргетинги,

настройки и т.д.• На диск пишем только логи, ничего не

читаем

Online хранение пользователей

Что храним?

SSP USER ID SSP INTERNAL USER ID

10:22741675 adfox 03goMw3rI64

USER ID USER DATA

03goMw3rI64 Частота показов по кампаниям и т.д.

Cookie sync table (100 млн записей)

User data (100 млн записей)

Требование к хранилищу• Ответ на чтение: 10ms (помним, timeout

всего аукциона 100ms)• Хранение всех данных в RAM• Цена! И еще раз цена!• Легкое масштабирование

Чего требовать не надо• Надежности• 99,99% availability – более, чем достаточно

Варианты• Терпимые: Mongo, Redis, Cassandra,

Tarantool• Плохие: Hbase• Неясные: MySQL/PostgreSQL

Offline данные оно же Big Data

Проблемы• Данных много: 10-100Gb в день• Люди хотят быстро получать ответы на

сложные вопросы: сколько у нас есть показов в Киеве людям в возрасте 20-25 лет, которые до этого искали билеты на самолет в Яндексе

Философия данных

Философия данных• Там где идет речь об аналитике, как

правило, скорость ответа важнее точности• Там, где идет речь о деньгах, как правило,

точность важнее скорости

Как пожертвовать точностью?date domain city impressions (показы)

2013-01-14 12:12 a.com Moscow 1

Считаем показы в Москве за один день:SELECT sum(impressions) WHERE

city=‘Moscow’ and date=‘2013-01-14’

Sampling

• Выбросим случайны 9 строчек из 10• Для оставшихся строчке умножим

impressions на 10• SELECT sum(impressions) WHERE

city=‘Moscow’ and date=‘2013-01-14’

date domain city impressions (показы)2013-01-14 12:12 a.com Moscow 10

Sampling – считаем ошибку• Пусть в ответе на запрос мы получили

число N• Тогда оценка ошибки: • При N=1 000 000, ошибка: 0.6%

Sampling

1,000,000

800,000

600,000

400,000

400,000

100,000

40,000

10,0003,000

1,000400

0.00%

10.00%

20.00%

30.00%

40.00%

50.00%

Статистическая ошибка

Уникальные пользователи

• SELECT count (distinct user_id) WHERE city=‘Moscow’ and date=‘2013-01-14’

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

date domain city user_id impressions (показы)

2013-01-14 12:12 a.com Moscow 6VdckZtTUkN 1

Вероятностные алгоритмы• Наглядные: K-minimum values, linear counter• Другие: LogLog counters

Что использовать?• Apache Hadoop – лучшее из худших

решений• Storm (from Twitter) – потоковый

“MapReduce”. Для некоторых задач заменяет Hadoop

• Колоночные БД

Колоночные БД

Колоночные БД• Важно! Hbase, Cassandra – не колоночные• Пример: SELECT sum(impressions) WHERE

city=‘Moscow’ and date=‘2013-01-14’ • Будут прочитаны только файлы для с

данными impressions и city

Колоночные БД – преимущества• Данные хорошо сжимаются (данные в

колонках однородные)• Скорость агрегирующих запросов в разы

выше• Недостатки: сложность загрузки данных

Machine learning

Machine learning• Предсказание вероятности клика• Предсказание вероятности конверсии• Look-alike (предсказание пола, возраста,

поведения пользователя)

Несколько фактов• На рынке есть хорошие open-source

решения• Лучше плохой алгоритм, чем никакой• Алгоритм важен, но еще важнее параметры

обучений (features) и настройки

Вопросы?• klimontovich@gmail.com• Skype: klimontovich