1. Анатомия RTB
Владимир Климонтович

2. Real time biding

3. Old school

4. RTB: (new school)

5. Аукцион второй цены
• Выигравший участник платит вторую цену +
delta (1 цент, 1 копейка)
• Если участник один, оплачивается
минимальная цена (floor cpm) + delta
• Аукцион второй цены стимулирует
участников называть реальную цену
• Время ответа: 100ms

6. Основные игроки
• SSP (Sell Side Platform) – обслуживает
интересы площадок
• DSP (Demand Side Platform) – обслуживает
интересы рекламодателей
• DMP (Data Management Platforms) –
продают данные о пользователе

7. SSP
• Обслуживает площадки
• Технологически проще DSP
• По сути, одинаковая бизнес-модель у всех
SSP

8. DSP
• Обслуживает рекламодателей
• Сложнее чем DSP
• Разные бизнес модели: retargeting, search
retargeting, audience targeting
• Разные модели оплаты: pay-per-click, pay-
per-conversion

9. Retargeting
• Показываем рекламу только тем
пользователям, которые уже были на сайте
рекламодателя
• По статистике, вероятность конверсии
может вырасти с 0.005% до 0.9%

10. Audience targeting
• Показываем объявления только
заинтересованной аудитории
• Например, показываем рекламу новой
Honda посетителям автомобильных сайтов
• Данные можно брать свои, можно покупать
у DMP

11. Pay-per-click/pay-per-conversion
• Рекламодатель платит DSP только в случае
совершения пользователем целевого
действия (клик, конверсия)
• DSP всегда платит SSP за показы
• Вывод: DSP должна хорошо уметь
оценивать вероятность клика/конверсии

12. Cookie sync

13. Cookie sync – проблема
• До RTB-эры пользователей
идентифицировали по cookie
• Но DSP и SSP “живут в разных доменах”

14. Cookie sync – проблема

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

16. Match table
• Порядок: 10-100 млн строк
• В идеале хранится на стороне SSP, но не
всегда
SSP User Id DSP User ID
10:22741675 03goMw3rI64

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

18. Что еще?
• До RTB-эры данные о пользователе (частота
показов, посещенные сайты) хранились в
cookie
• Cookie sync обеспечивает только
синхронизацию ID. Остальное нужно
хранить в БД на стороне DSP (NoSQL )

19. Под капотом RTB

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

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

22. HTTP-нагрузка, что делать?
• Не боятся!
• Использовать Java/C++, остерегаться Python
и PHP
• Использовать event-driven подход, lock-free
синхронизацию и т.д.

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

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

25. Что храним?
SSP USER ID SSP INTERNAL USER ID
10:22741675 adfox 03goMw3rI64
USER ID INTERNAL USER ID
03goMw3rI64
Cookie sync table (100 млн записей)
User data(100 млн записей)

26. Требование к хранилищу
• Ответ на чтение: 10ms (помним, timeout
всего аукциона 100ms)
• Хранение всех данных в RAM
• Цена! И еще раз цена!
• Легкое масштабирование

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

28. Варианты
• Терпимые: Mongo, Redis, Cassandra,
Tarantool
• Плохие: Hbase
• Неясные: MySQL/PostgresSQL

29. Offline данные (логи)

30. Проблемы
• Данных много: 10-100Gb в день
• Люди хотят быстро получать ответы на
сложные вопросы: сколько у нас есть
показов в Киеве людям в возрасте 20-25
лет, которые до этого искали билеты на
самолет в Яндексе

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

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

33. Как пожертвовать точностью?
date domain city impressions (показы)
2013-01-14 12:12 a.com Moscow 1
Считаем показы в Москве за один день:
SELECT sum(impressions) WHERE
city=‘Moscow’ and date=‘2013-01-14’

34. 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

35. Sampling – считаем ошибку
• Пусть в ответе на запрос мы получили число
N
• Тогда оценка ошибки:
• При N=1 000 000, ошибка: 0.6%
2
N /10

36. Sampling
0.00%
10.00%
20.00%
30.00%
40.00%
50.00%
Статистическая ошибка

37. Уникальные пользователи
• 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

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

39. Что использовать?
• Apache Hadoop – лучшее из худших
решений
• Storm (from Twitter) – потоковый
“MapReduce”. Для некоторых задач
заменяет Hadoop
• Колоночные БД

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

41. Колоночные БД
• Важно! Hbase, Cassandra – не колоночные
• Пример: SELECT sum(impressions) WHERE
city=‘Moscow’ and date=‘2013-01-14’
• Будут прочитаны только файлы для с
данными impressions и city

42. Колоночные БД – преимущества
• Данные хорошо сжимаются (данные в
колонках однородные)
• Скорость агрегирующих запросов в разы
выше
• Недостатки: сложность загрузки данных

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