Recommandé
Recommandé
Contenu connexe
En vedette
En vedette (11)
Similaire à Rtb
Similaire à Rtb (20)
Rtb
- 3. Old school
- 4. Проблемы • Финальный исход зависит от порядка ad networks в цепочке • Большой размер цепочки замедляет загрузку страницы
- 6. Аукцион второй цены • Выигравший участник платит вторую цену + delta (1 цент, 1 копейка) • Если участник один, оплачивается минимальная цена (floor cpm) + delta • Аукцион второй цены стимулирует участников называть реальную цену • Время ответа: 100ms
- 7. Основные субъекты рынка • SSP (Sell Side Platform) – обслуживает интересы площадок • DSP (Demand Side Platform) – обслуживает интересы рекламодателей • DMP (Data Management Platforms/Data Exchange) – собирает данные о пользователе
- 8. SSP • Обслуживает интересы площадок размещения (сайтов) • Технологически проще DSP • По сути, одинаковая бизнес-модель у всех SSP
- 9. DSP • Обслуживает рекламодателей • Сложнее чем SSP • Разные бизнес модели: retargeting, search retargeting, audience targeting • Разные модели оплаты: pay-per-click, pay- per-conversion
- 10. Retargeting • Показываем рекламу только тем пользователям, которые уже были на сайте рекламодателя • По статистике, вероятность конверсии может вырасти с 0.005% до 0.9%
- 11. Audience targeting • Показываем объявления только заинтересованной аудитории • Например, показываем рекламу новой Honda посетителям автомобильных сайтов • Данные можно брать свои, можно покупать у DMP
- 12. Pay-per-click/pay-per-conversion • Рекламодатель платит DSP только в случае совершения пользователем целевого действия (клик, конверсия) • DSP всегда платит SSP за показы • Вывод: DSP должна хорошо уметь оценивать вероятность клика/конверсии
- 13. Cookie sync
- 14. Cookie sync – проблема • До RTB-эры пользователей идентифицировали по cookie • Но DSP и SSP “живут в разных доменах”
- 15. Cookie sync – проблема
- 16. Cookie sync – решение (sync pixel)
- 17. Match table • Порядок: 10-100 млн строк • В идеале хранится на стороне SSP, но не всегда SSP User Id DSP User ID 10:22741675 03goMw3rI64
- 18. Виды cookie sync • Инициированный SSP • Инициированный DSP
- 19. Что еще? • До RTB-эры данные о пользователе (частота показов, посещенные сайты) хранились в cookie • Cookie sync обеспечивает только синхронизацию ID. Остальное нужно хранить в БД на стороне DSP (NoSQL )
- 20. Под капотом RTB
- 21. Основные проблемы • HTTP-нагрузка (тысячи входящих и исходящий HTTP-запросов в секунду) • Хранение и анализ логов (10-100Gb в день) • Online хранилища (match table, user table) • Machine learning: алгоритмы предсказания кликов/конверсий
- 22. HTTP-нагрузка • Средняя SSP: 5 000 входящих, 20 000 исходящих запросов в секунду • Средняя DSP: 10 000 входящих запросов в секунду
- 23. HTTP-нагрузка, что делать? • Не боятся! • Использовать Java/C++, остерегаться Python и PHP • Использовать event-driven подход, lock-free синхронизацию и т.д.
- 24. HTTP-нагрузка: библиотеки • Java: akka, NIO, Netty • C++: libevent, libev
- 25. И последнее: RAM и только RAM!
- 26. Храним в памяти • Все рекламные кампании, таргетинги, настройки и т.д. • На диск пишем только логи, ничего не читаем
- 28. Что храним? SSP USER ID SSP INTERNAL USER ID 10:22741675 adfox 03goMw3rI64 USER ID USER DATA 03goMw3rI64 Частота показов по кампаниям и т.д. Cookie sync table (100 млн записей) User data (100 млн записей)
- 29. Требование к хранилищу • Ответ на чтение: 10ms (помним, timeout всего аукциона 100ms) • Хранение всех данных в RAM • Цена! И еще раз цена! • Легкое масштабирование
- 30. Чего требовать не надо • Надежности • 99,99% availability – более, чем достаточно
- 31. Варианты • Терпимые: Mongo, Redis, Cassandra, Tarantool • Плохие: Hbase • Неясные: MySQL/PostgreSQL
- 32. Offline данные оно же Big Data
- 33. Проблемы • Данных много: 10-100Gb в день • Люди хотят быстро получать ответы на сложные вопросы: сколько у нас есть показов в Киеве людям в возрасте 20-25 лет, которые до этого искали билеты на самолет в Яндексе
- 34. Философия данных
- 35. Философия данных • Там где идет речь об аналитике, как правило, скорость ответа важнее точности • Там, где идет речь о деньгах, как правило, точность важнее скорости
- 36. Как пожертвовать точностью? date domain city impressions (показы) 2013-01-14 12:12 a.com Moscow 1 Считаем показы в Москве за один день: SELECT sum(impressions) WHERE city=‘Moscow’ and date=‘2013-01-14’
- 37. 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
- 38. Sampling – считаем ошибку • Пусть в ответе на запрос мы получили число N • Тогда оценка ошибки: • При N=1 000 000, ошибка: 0.6% 2 N /10
- 40. Уникальные пользователи • 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
- 41. Вероятностные алгоритмы • Наглядные: K-minimum values, linear counter • Другие: LogLog counters
- 42. Что использовать? • Apache Hadoop – лучшее из худших решений • Storm (from Twitter) – потоковый “MapReduce”. Для некоторых задач заменяет Hadoop • Колоночные БД
- 43. Колоночные БД
- 44. Колоночные БД • Важно! Hbase, Cassandra – не колоночные • Пример: SELECT sum(impressions) WHERE city=‘Moscow’ and date=‘2013-01-14’ • Будут прочитаны только файлы для с данными impressions и city
- 45. Колоночные БД – преимущества • Данные хорошо сжимаются (данные в колонках однородные) • Скорость агрегирующих запросов в разы выше • Недостатки: сложность загрузки данных
- 46. Machine learning
- 47. Machine learning • Предсказание вероятности клика • Предсказание вероятности конверсии • Look-alike (предсказание пола, возраста, поведения пользователя)
- 48. Несколько фактов • На рынке есть хорошие open-source решения • Лучше плохой алгоритм, чем никакой • Алгоритм важен, но еще важнее параметры обучений (features) и настройки
- 49. Вопросы? • klimontovich@gmail.com • Skype: klimontovich
Notes de l'éditeur
- - Всемдоброеутро! Яприятноудивлен, чтовстольраннийчассобралосьтакмноголюдей. Значиттемадостаточноинтересная.(Всемдоброеутрохорошо, чтолюдейтакнемного. Значитвывсенастольколюбите RTB, чтоготовыпожертвоватьутреннимсном)(пауза)Вообще, язанимаюсьвсякимиштукамиоколо RTB ужепочти 4ре года, имогурассказатьоченьмногоинтересного. Вообщемойдоклад, скореепростыкбизнесаитехнологии, прото, какбизнесдиктуеттехнологическиеусловиявданнойобласти. Слайдовяприготовилмного, такчтонеуверен, чтопровсеуспеюрассказатьподробно. Хочуспроситьувас: подминимитеруките, комускореепробизнесаспекты RTB? Акомупротехнологии?И еще последний момент. В любой момент вы можете прервать меня и задавать вопросы. Возможно, мы я тогда про что-то не успею рассказать, но это лучше недопонимания. На простые вопросы я буду отвечать сразу.Однако, если вопрос сложный, я его с вашего позвления пропущу, и отвечу после в частном порядке
- RTB. Расшифровываетсякак Real time bidding, илиаукционреальноговремени. Этонекотораяпопыткаперенестибиржевыемоделивмиронлайнрекламы. Насамомделе, доконцанеясночтоизэтоговышло. Рынокпоявилсягде-тов 2009-ом годуидосихпорстремительноэволюционирует
- Итак, давайтенемногопроисторию. Воткакбылаустроенажизньдо RTB. Площадка, продаваярекламноеместоставилакодкакой-нибудьрекламнойсети. Сзаходомпользователя, вызывалсяэтоткодирекламнаясетьискалаподходящееобъявлениевсвоейбазе. Еслиподходящийбаннернашелся, тосетьвыдавала HTML-коддляотображениябаннера. Еслиничегоненашлось, сетьвыдавалакодследующейрекламнойсетивцепочке.Впрочем, этонето, чтобыистория. Простораньшеэтобылединственныйвариант
- Итак, проблемыстарогоподхода: - Нуво-первых, то, какоеобъявлениебудетпоказановрезультате, сильнозависитотпорядкарекламныхсетейвцепочке. Здесьнетчестнойконкуреции - Во-вторых, длиннаяцепочкарекламныхсетейтормозитзагрузкусайта - Ряддругихпроблем
- Чтобырешитьэтупроблему, появилось RTB. Накаждыйрекламныйпоказпроводитсяаукцион. Аукционпроводяттакназываемые SSP, sell-side platforms, которыепредставляютинтересыплощадок. Ваукционахучаствуют DSP, demand side platforms, которыепредставляютинтересырекламодателей.Аукционпроводитьсячерез HTTP. SSP вместес HTTP запросомприсылаетмногоразнойинформации: IP адреспользователя, егобраузер, urlразмещенияит.д.Вответ DSP отвечаетставкойи HTML-кодом, которыйбудетпоказанпользователювслучаевыигрыша
- RTB - этоаукционвторойцены. Все сначала удивляются и расстраиваются. Но на самом деле, так выгоднее
- Итак, ещераз, повторяем!Ещебывают DMP, этоплатформы, которыеводихместахсобираютданныеопользователе. "Данные" этообычнопол, возраститакдалее. Этиданные DMP продают DSP, чтобытемоглипоказыватьболеетаргетированнуюрекламуПро DMP мысегодняговоритьнебудем. Во-первых, этонетакинтересно. А, во-вторых, яперсональносчитаю, чтоэтодовольнодурацкийибесполезныйбизнес
- Подробнеепо SSP. Во-первых, какяужеисказал, SSP обслуживаетинтересыплощадок. Во-вторых, SSP штукахотьисложная, нопроще DSP. Ещеонивсеодинаковыевсмыслебизнесмоделе.Явсеклонюктому, что SSP этонеоченьинтересно, имыпронихсегодняпочтинебудемговорить
- Абудемговоритьвосновномпро DSP. Какяужеиговорил, DSP обслуживаетрекламодаталей. АсрекламщикамивсегдавсесложноТехнологическиэтосложнееиинтереснее. Тутестьнесколькоинтересныхбизнесмоделей, онекоторыхизнихярасскажупоподробнее
- Самаяраспостраненнаямодель - retargeting.- (!!!!!) КСТАТИ, НАВЕРНОЕ, У МНОГИХ ТУТ СТОИТ AD-BLOCK ИЛИ ЧТО-ТО ВРОДЕ ЭТОГО. ПОДНИМИТЕ РУКУ, У КОГО ОН ЕСТЬ?- Остальные, наверное, знаютчтотакоеретаргетинг. Этокогдавыодинраззашливинтернет-магазин, апослецелыймесяцвасмучаетрекламаэтогожемагазина.- Каксказалодинмойзнакомый: невозможнокупитьженеподарокнановыйгодвинтернете, чтобыонаобэтомнеузнала. Хотя, думаю, этонесамаянеловкаяситцацяикотораяможетвсвязисретаргетингомвозникнуть- Итого, идеяретаргетингапонятно. Надопонимать, чтоделаетсяэтонеизвредности. Статистика - упрямаявещь. Вероятностьконверсииприусловиипоказаретаргетированногобаннерасущественновыше
- Ещеестьаудиторныйтаргетинг. Есливкратце, этопоказобъявленийзаинтересованнойаудитории. Останавливатьсянаэтомнебудем. По-моемумнению, этонеоченьрабочаямодель
- Ещеважнаяштукапо DSP. Некоторыеигрокиработаютсрекламодателямипомоделиоплатызакликилизаконверсию. Приэтомрасчетыс SSP происходятвсегдазапоказы. Тутпоявляетсякучаинтересныхтехническихмоментов, связанныхсточнойоценкивероятностикликаиликонверсиидлякаждого RTB запроса, чтобынеработатьвминус. Всяэтаисторияназываетсяарбитраж. Пронееподробнееярасскажувконце, еслиуспею
- - Ещеважнаяштуканазывается cookie sync. Этонасамомделеоченьнудноинеинтересно. Новажносточкизренияпониманиятехнологий. - Обратитевниманиенакартинкунаслайде. Еслиничегонепонятно, тотакидолжнобыть. Какяисказал, cookie sync эторутина, нопостарайтесьпотерпетьпаруминутиявсеобъясню
- Итак, зачемвсеэтонужно. До RTB дляидентификациипользователейихраненияонихинформации ()
- Вотещеразпроблема. Когда SSP размещаеткоднасайте, онооперируеткукамивсвоемдомене, ssp.com. Приэтому DSP кукивсвоемдоменеикакая-тосвояинформацияопользователе.Если, например, DSP показалокакое-тообъявление 100 разодномупользователспомощьюдругого SSP ипользовательнанемнекликал, тонаверное, показыватьегодальшебесполезно. Нокакузнать, чтонатекущем SSP пришелтотсамыйпользователь.
- Итак, решение. Когда SSP показыватобъявление, неважнооткакого DSP, оноставитвконцемногомаленьких, прозрачныхпикселей (такназываемыезиро-пиксели). Каждыйпиксельсоответсвуетодной DSP.Этипикселивызывают URL насайте DSP, передаваявпараметрахзапросасвойидентификаторпользователя. А DSP всвоюочередь, идетифицируетпользовтелякукойвсвоемдоменеиможетвнутрисебязапомнитьсоответсвие.Когдавследующийразот SSP придетзапрос, DSP сможетвтаблиценайтисвой, внутреннийидентификаторпользователяииспользоватьэтуинформацию
- Итого, длясоответсвияпользователейнужнохранитьтакуютаблицуиздвухколонок, коотораяназывается match tableНадопонимать, чтовмиререкламыпользовательэтонетожесамое, чтопользовательсайта. Людиимеютсвойствотеретькуки, менятьбраузерыит.д. Такчтодлясредней DSP таблицапользователейможетбытьот 10 до 100 млн.Ещевпрошломслайдебылапредставленачутьупрощеннаякартинамира. Всеможетбытьнесколькосложнее. Такчтовзависимостиотреализации cookie sync table могутхранитькак SSP, таки DSP. Лучшебы, чтобывсегдахранили SSP, ноэтонетак
- Ещепарумоментовпро cookie sync. Взависимостиоттого, гдестоитпиксельнастороне SSP или DSP, различаютдвавида
- Чтотутещеможносказать? Ну, например, еслираньшетакуюинформацию, какчастотупоказовбаннера, илипоследнийпоказбаннерахраниливкуках, топри RTB этовозможностьисчезла. Механизм cookie sync имеетограничения, такчтотакиевещиприходитсяхранитьв БД настороне DSP. Обычно, используютсявсякиеNoSQLрешения.
- ----- Meeting Notes (4/21/13 23:08) -----И так, переходим к самому интересному. К обзору технологий, которые позволяют работать всей этой экосистеме.Если приглядется, на картинке изображен двигатель машины марки Лада, которая отличается качеством.На самом деле, в мире RTB все так же. Нет устоявшихся технологий и компании не могут много вкладывать в IT. Зато получается очень весело и интересно!
- Итак, перечислимосновныетехнологическиепроблемы
- HTTP нагрузкавцифрах. Каквидно, нетакмало. Чтожеснейделать?
- Ну, первыйпункт, этонебоятся. ПОДНИМИТЕ РУКИ ТЕ, КТО ПИСАЛ СИСТЕМЫ ОБРАБАТЫВАЮЩИЕ более 1000 запросоввсекунду?Вотвидете, этонетакстрашно. Современноежелезоифреймворкидовольномощные.Еще, конечно, надописатьна Java или C++. Ну, есливзятьэкзотикуerlangтожеможетбытьподойдет. Главное, избегать PHP и Python. Наверное, наэтихтехнологияхможночто-тонаписать, ноуспешныеисториимненеизвестны. Нуиобязательносмотритевсторону event-driven программирования, lock free синхронизацииивообщевсторонувсяхновыхмногопоточныхштук
- Несколькопримеровтого, чтостоитиспользоватьдля Java иС++. В C++ яразбираюсьнеочень, такчтотамможетбытьещечто-нибудьесть.
- Золотое правило рекламы. Все храним только в оперативной памяти
- Это относится ко всем рекламным кампаниям, таргетингам, настройкам. Никаких SQL-запросов.На диск можно писать только логи
- Так, с HTTP разобрались. Теперь про хранение данных о пользователях.
- Во-первых скорость и еще раз скорость. Время чтения не должно превышать 10 милисекунд. Ну или такого порядка. Помним, что на аукционный запрос надо ответитьза 100 миллисекундИз скорости сдедуют, что хранилище должно читать данные из памяти, диск не должен быть задействован. Да, на диск будет происходить запись, потому что надежностьнам все-таки не повредит. Но чтение – только оперативная памятьЕще важна цена. Если это платное решение, и хранение пользователя стоит 1 доллар за 1000 пользователей, то при 100 миллионах записей месячная цена будетоколо 100 000 долларов. Такие затраты посильны для банков, но не для DSPНу еще неплохо бы чтобы эта штука легко масштабировалась. Бизнес DSP штука нестабильная с непредсказуемым ростом
- А теперь еще более важная штука – что требовать не надо. На самом деле, в таких вещах всегда важно смягчать требования там, где это возможно. Это может упростить жизнь в несколько раз.Как ни странно слышать это про базы данных, но в данном случае нам не нужна надежность. База может иногда терять данные, не отвечать на запросы и т.д. Если одному из миллиона пользователеймы покажем не тот баннер или же не покажем ничего – не страшно. Главное, чтобы ошибки не были системными и были распределенными.
- Вот список вариантов для хранения данных о пользователе, которые существуют на рынке. Кстати, про MySQL/PostgreSQL. Я не знаю, можно ли их эффективно использовать как key value storage для таблиц с 100 миллионами строк. Если кто-то расскажет, буду благодарен.
- И так, самое интересное. Это оффлайновая обработка данных. Обычно, на каждое действие (показ, аукцион, клик) пишется строчка в лог, а потом люди хотят по этим логам получать какую-то аналитику.Например, статистические отчеты.ЭТА САМАЯ ИНТЕРЕСНАЯ ЧАСТЬ ДОКЛАДА. ТОТ, КТО ЕЩЕ НЕ ПОТЕРЯЛ ИНТЕРЕСА, УЗНАЕТ, КАК СОКРАТИТЬ ОБЪЕМ ХРАНИМЫХ ДАННЫХ в 10 РАЗ НЕ ПОТЕРЯВ ПРАКТИЧЕСКИ НИЧЕГО
- И так, какие с логами есть проблемы. Например, из много. В зависимости от размера DSP от 10 до 100 гигабайт в день.Во-вторых, люди хотят быстро получать ответы на сложные вопросы. Например ????
- И так, про философию данных в RTB.Посмотрите на скришоты, всем видно? Это типичные разговоры про данные с конечными пользователями. (Зачитать, если не видно??)
- Итак, выводы из предыдущих скриншотов. Вывода два и они очень важны:
- Как пожертвовать точностью и как-то от этого выиграть? Сейчас я приведу пример довольно простой техники.Практическая задача: у нас есть логи показов баннеров. Будем считать количество показов в городе Москва за 14 января сего года. Для удобства, представим, что все у нас хранится в SQL таблице. Тогда запрос будет выглядеть примерно так.Помним о средних размерах DSP, это может быть 30 миллионов показов в сутки. Что же делать?
- Ответ – sampling. Около каждой строчки подкинем 10гранный кубик. Если выпала единичка, оставляем строчку. Иначе выкидываем.Итого мы выкиним 9 из 10 строчек. А в оставшихся строчках давайте домножим количество показов на 10.И выполним тот же запрос. Выглядит радикально?
- На самом деле нет! Пусть в ответ на запрос (помним, мы считаем количество показов в москве от 14 января) мы получили число N. Тогда статистическая ошибка будет ….Ну например, если у нас был в Москве один миллион показов, то ошибка будет около половины процента, т.е. совсем не много
- Как видно, чем меньше ответ, тем больше значение ошибки. Однако, если мы вспомним наш изначальный кейс, когда цифра по показам нужна менеджеру по продажам, то и 10% ошибка не страшна.Сильно большая ошибка возникает, когда ответ на вопрос менее 3000. Но в этом случае, ответ настолько мало отличается от 0, что и ошибка в общем-то не важна
- Ладно,Sampling это просто, есть вещи куда интереснее. Например, давайте добавим колонку идентификатор пользователя в наш лог. И попытаемся посчитать количество уникальных пользователей за один день.Опять же, для простоты будем мыслить в терминах SQL. Посмотрите на запрос, это еще мощнее чем предыдущий. sum относительно простая операция по сравнению с count distinct
- Что же делать? Есть куча вероятностных алгоритмов для подсчета уникальных пользователей с ошибкой. К сожаление, в рамках доклада нет времени рассказывать о них подробно, но они довольно красивые.Советую погуглить и почитать.
- Так, давайте резюмируем и поговорим про конкретные технологии, а не про алгоритмы.Во-первых, в большинстве случаев используется несколько технологий, для разных задач.В целом популярен Hadoop. Он стабилен, относительно других NoSQLрешений.Еще удобен Storm. Это такой потоковый MapReduce, которые местами заменяет хадупА еще спасают, колоночные базы данных.У НАС ЕЩЕ ЕСТЬ ВРЕМЯ? Тогда расскажу про них подробнее.
- Основная идея. Если в традиционных БД данные хранятся по строкам, то в колоночных БД – по столбцам. Один столбец – один файл.
- Важно.Hbaseи Cassandra не колоночные БД, хотя их так иногда называют. Так вышло, что здесь вышла путаница в терминологии. Но важно понимать, что Cassandra и Hbaseхранят данные по строчкам.Давайте посмотрим все тот же любимый пример в виде SQL запроса и будем считать количество показов в москве за определенный деньСила колоночных БД в том, что будут прочитаны только два файла с данными по нужным колонкам. При большой таблице (а в реальной жизни в логах может быть около 50 полей),будут прочитаны всего 4% дневных данных
- Итак, резюмируем про колоночные БД.