Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

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

927 views

Published on

  • Be the first to comment

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

  1. 1. Анатомия RTBВладимир Климонтович
  2. 2. Real time biding
  3. 3. Old school
  4. 4. RTB: (new school)
  5. 5. Аукцион второй цены• Выигравший участник платит вторую цену +delta (1 цент, 1 копейка)• Если участник один, оплачиваетсяминимальная цена (floor cpm) + delta• Аукцион второй цены стимулируетучастников называть реальную цену• Время ответа: 100ms
  6. 6. Основные игроки• SSP (Sell Side Platform) – обслуживаетинтересы площадок• DSP (Demand Side Platform) – обслуживаетинтересы рекламодателей• DMP (Data Management Platforms) –продают данные о пользователе
  7. 7. SSP• Обслуживает площадки• Технологически проще DSP• По сути, одинаковая бизнес-модель у всехSSP
  8. 8. DSP• Обслуживает рекламодателей• Сложнее чем DSP• Разные бизнес модели: retargeting, searchretargeting, audience targeting• Разные модели оплаты: pay-per-click, pay-per-conversion
  9. 9. Retargeting• Показываем рекламу только темпользователям, которые уже были на сайтерекламодателя• По статистике, вероятность конверсииможет вырасти с 0.005% до 0.9%
  10. 10. Audience targeting• Показываем объявления толькозаинтересованной аудитории• Например, показываем рекламу новойHonda посетителям автомобильных сайтов• Данные можно брать свои, можно покупатьу DMP
  11. 11. Pay-per-click/pay-per-conversion• Рекламодатель платит DSP только в случаесовершения пользователем целевогодействия (клик, конверсия)• DSP всегда платит SSP за показы• Вывод: DSP должна хорошо уметьоценивать вероятность клика/конверсии
  12. 12. Cookie sync
  13. 13. Cookie sync – проблема• До RTB-эры пользователейидентифицировали по cookie• Но DSP и SSP “живут в разных доменах”
  14. 14. Cookie sync – проблема
  15. 15. Cookie sync – решение (sync pixel)
  16. 16. Match table• Порядок: 10-100 млн строк• В идеале хранится на стороне SSP, но невсегдаSSP User Id DSP User ID10:22741675 03goMw3rI64
  17. 17. Виды cookie sync• Инициированный SSP• Инициированный DSP
  18. 18. Что еще?• До RTB-эры данные о пользователе (частотапоказов, посещенные сайты) хранились вcookie• Cookie sync обеспечивает толькосинхронизацию ID. Остальное нужнохранить в БД на стороне DSP (NoSQL )
  19. 19. Под капотом RTB
  20. 20. Основные проблемы• HTTP-нагрузка (тысячи входящих иисходящий HTTP-запросов в секунду)• Хранение и анализ логов (10-100Gb в день)• Online хранилища (match table, user table)• Machine learning: алгоритмы предсказаниякликов/конверсий
  21. 21. HTTP-нагрузка• Средняя SSP: 5 000 входящих, 20 000исходящих запросов в секунду• Средняя DSP: 10 000 входящих запросов всекунду
  22. 22. HTTP-нагрузка, что делать?• Не боятся!• Использовать Java/C++, остерегаться Pythonи PHP• Использовать event-driven подход, lock-freeсинхронизацию и т.д.
  23. 23. HTTP-нагрузка: библиотеки• Java: akka, NIO, Netty• C++: libevent, libev
  24. 24. Online хранение пользователей
  25. 25. Что храним?SSP USER ID SSP INTERNAL USER ID10:22741675 adfox 03goMw3rI64USER ID INTERNAL USER ID03goMw3rI64Cookie sync table (100 млн записей)User data(100 млн записей)
  26. 26. Требование к хранилищу• Ответ на чтение: 10ms (помним, timeoutвсего аукциона 100ms)• Хранение всех данных в RAM• Цена! И еще раз цена!• Легкое масштабирование
  27. 27. Чего требовать не надо• Надежности• 99,99% availability – более, чем достаточно
  28. 28. Варианты• Терпимые: Mongo, Redis, Cassandra,Tarantool• Плохие: Hbase• Неясные: MySQL/PostgresSQL
  29. 29. Offline данные (логи)
  30. 30. Проблемы• Данных много: 10-100Gb в день• Люди хотят быстро получать ответы насложные вопросы: сколько у нас естьпоказов в Киеве людям в возрасте 20-25лет, которые до этого искали билеты насамолет в Яндексе
  31. 31. Философия данных
  32. 32. Философия данных• Там где идет речь об аналитике, какправило, скорость ответа важнее точности• Там, где идет речь о деньгах, как правило,точность важнее скорости
  33. 33. Как пожертвовать точностью?date domain city impressions (показы)2013-01-14 12:12 a.com Moscow 1Считаем показы в Москве за один день:SELECT sum(impressions) WHEREcity=‘Moscow’ and date=‘2013-01-14’
  34. 34. Sampling• Выбросим случайны 9 строчек из 10• Для оставшихся строчке умножимimpressions на 10• SELECT sum(impressions) WHEREcity=‘Moscow’ and date=‘2013-01-14’date domain city impressions (показы)2013-01-14 12:12 a.com Moscow 10
  35. 35. Sampling – считаем ошибку• Пусть в ответе на запрос мы получили числоN• Тогда оценка ошибки:• При N=1 000 000, ошибка: 0.6%2N /10
  36. 36. Sampling0.00%10.00%20.00%30.00%40.00%50.00%Статистическая ошибка
  37. 37. Уникальные пользователи• SELECT count (distinct user_id) WHEREcity=‘Moscow’ and date=‘2013-01-14’• Как оптимизировать?date domain city user_id impressions (показы)2013-01-14 12:12 a.com Moscow 6VdckZtTUkN 1
  38. 38. Вероятностные алгоритмы• Наглядные: K-minumum values, linearcounter• Другие: LogLog counters
  39. 39. Что использовать?• Apache Hadoop – лучшее из худшихрешений• Storm (from Twitter) – потоковый“MapReduce”. Для некоторых задачзаменяет Hadoop• Колоночные БД
  40. 40. Колоночные БД
  41. 41. Колоночные БД• Важно! Hbase, Cassandra – не колоночные• Пример: SELECT sum(impressions) WHEREcity=‘Moscow’ and date=‘2013-01-14’• Будут прочитаны только файлы для сданными impressions и city
  42. 42. Колоночные БД – преимущества• Данные хорошо сжимаются (данные вколонках однородные)• Скорость агрегирующих запросов в разывыше• Недостатки: сложность загрузки данных
  43. 43. Вопросы?• klimontovich@gmail.com• Skype: klimontovich

×