BS
Object not found!
The requested URL was not found on this server.
Size: a a a
2017 July 06
NB
Спонсоры: мыши-байкеры с Марса
BS
Написал в аудиториус Нагорному, Кашину, Иванову. Пока молчат
V
Всем привет! Зачем писать Гене? Сейчас отвечу я :)
V
Собственно, как-то рассказывали про это уже.
V
сейчас будет лонгрид!
V
"троттлинг" помогает оптимизировать работу DSP, а еще бывает полезным и во многих других сферах.
Небольшая преамбула: технологии в prоgrammatic – это высокие нагрузки на инфраструктуру. Фраза Real Time в аббревиатуре RTB подразумевает что скорость ответа на bid не должна превышать 0,05 с. При этом только в России в среднем в секунду разыгрывается 15 000 показов. Это значит, что каждую секунду DSP должно 15 000 раз принять решение о покупке показа и сделать это менее чем за 0,05 секунд. А это включает проверку соответствия таргетингов заданным рекламным кампаниям, контроль бюджета, предсказание «нужности» показа для рекламодателя и еще много чего. Чем больше логики и чем она сложнее, тем больше машинного времени нужно на каждое событие. Чем больше машинного времени требуется в сумме, тем дороже и сложнее инфраструктура, которая все это счастье обслуживает. Важный критерий в работе DSP – стоимость обслуживания 1 000 000 запросов. Чем ниже эта цена (при сопоставимых возможностях DSP), тем выгоднее это рекламодателю.
Так какова же роль троттлинга в DSP системах?
По сути это механизм предварительной фильтрации входящих запросов с целью снижения стоимости обслуживания 1 000 000 запросов. Задача троттлинга – с минимальным машинным временем (нагрузкой на инфраструктуру) откинуть запросы которые скорее всего не будут выкуплены и отдать в сложную бизнес-логику (где проверяются таргетинги и остальная логика) те запросы, которые потенциально интересны рекламодателям. Чем совершеннее система троттлинга, тем дешевле обслуживание 1 000 000 запросов и тем качественнее закупка (троттлинг не выкидывает нужные запросы).
Принципов работы троттлинга может быть очень много:
🔹троттлинг-монетка. Примитивный случай, когда система случайным образом «пускает» во внутреннюю логику нужное количество запросов, например, каждый 10-й (количество регулируется вручную);
🔹баджет-троттлитнг. Более продвинутый случай, когда система так же случайным образом выбирает нужное количество запросов, но их объем зависит от бюджета рекламной кампании и его исполнямости (чем больше отставания от планового бюджета в момент времени, тем больше пропускается трафика в бизнес-логику. Делитель постоянно пересчитывается);
🔹предикт-троттлинг. Еще более продвинутый случай, когда помимо контроля исполняемости бюджета, как в примере выше, троттлинг пропускет показы не случайно, а по какой-то предиктивной модели скоринга. Например, все показы с минимальным машинным временем скорятся на вероятность совершения нужного действия – клика и т.д. В данном случае помимо того, что контролируется нужный объем инвентаря для исполнения бюджета, пропускается трафик более полезный (например, более кликабельный), чем со случайным делителем.
Прекрасный пример троттлинга не из рекламной сферы – работа коллайдера CERN. В процессе столкновения частиц в секунду генерируется 40 терабайт данных. Хранить и обрабатывать данные в таком объеме практически невозможно. Для этого в детекторах есть два уровня троттлинга, снижающих количество данных с 40 тб/сек до 1гб/сек, то есть тротлинг пускает дальше на обработку 1/40 000 всех событий. При этом качество работы троттлинга такое, что даже столь сильная фильтрация не помешала сделать выдающиеся открытия!
Небольшая преамбула: технологии в prоgrammatic – это высокие нагрузки на инфраструктуру. Фраза Real Time в аббревиатуре RTB подразумевает что скорость ответа на bid не должна превышать 0,05 с. При этом только в России в среднем в секунду разыгрывается 15 000 показов. Это значит, что каждую секунду DSP должно 15 000 раз принять решение о покупке показа и сделать это менее чем за 0,05 секунд. А это включает проверку соответствия таргетингов заданным рекламным кампаниям, контроль бюджета, предсказание «нужности» показа для рекламодателя и еще много чего. Чем больше логики и чем она сложнее, тем больше машинного времени нужно на каждое событие. Чем больше машинного времени требуется в сумме, тем дороже и сложнее инфраструктура, которая все это счастье обслуживает. Важный критерий в работе DSP – стоимость обслуживания 1 000 000 запросов. Чем ниже эта цена (при сопоставимых возможностях DSP), тем выгоднее это рекламодателю.
Так какова же роль троттлинга в DSP системах?
По сути это механизм предварительной фильтрации входящих запросов с целью снижения стоимости обслуживания 1 000 000 запросов. Задача троттлинга – с минимальным машинным временем (нагрузкой на инфраструктуру) откинуть запросы которые скорее всего не будут выкуплены и отдать в сложную бизнес-логику (где проверяются таргетинги и остальная логика) те запросы, которые потенциально интересны рекламодателям. Чем совершеннее система троттлинга, тем дешевле обслуживание 1 000 000 запросов и тем качественнее закупка (троттлинг не выкидывает нужные запросы).
Принципов работы троттлинга может быть очень много:
🔹троттлинг-монетка. Примитивный случай, когда система случайным образом «пускает» во внутреннюю логику нужное количество запросов, например, каждый 10-й (количество регулируется вручную);
🔹баджет-троттлитнг. Более продвинутый случай, когда система так же случайным образом выбирает нужное количество запросов, но их объем зависит от бюджета рекламной кампании и его исполнямости (чем больше отставания от планового бюджета в момент времени, тем больше пропускается трафика в бизнес-логику. Делитель постоянно пересчитывается);
🔹предикт-троттлинг. Еще более продвинутый случай, когда помимо контроля исполняемости бюджета, как в примере выше, троттлинг пропускет показы не случайно, а по какой-то предиктивной модели скоринга. Например, все показы с минимальным машинным временем скорятся на вероятность совершения нужного действия – клика и т.д. В данном случае помимо того, что контролируется нужный объем инвентаря для исполнения бюджета, пропускается трафик более полезный (например, более кликабельный), чем со случайным делителем.
Прекрасный пример троттлинга не из рекламной сферы – работа коллайдера CERN. В процессе столкновения частиц в секунду генерируется 40 терабайт данных. Хранить и обрабатывать данные в таком объеме практически невозможно. Для этого в детекторах есть два уровня троттлинга, снижающих количество данных с 40 тб/сек до 1гб/сек, то есть тротлинг пускает дальше на обработку 1/40 000 всех событий. При этом качество работы троттлинга такое, что даже столь сильная фильтрация не помешала сделать выдающиеся открытия!
NB
"троттлинг" помогает оптимизировать работу DSP, а еще бывает полезным и во многих других сферах.
Небольшая преамбула: технологии в prоgrammatic – это высокие нагрузки на инфраструктуру. Фраза Real Time в аббревиатуре RTB подразумевает что скорость ответа на bid не должна превышать 0,05 с. При этом только в России в среднем в секунду разыгрывается 15 000 показов. Это значит, что каждую секунду DSP должно 15 000 раз принять решение о покупке показа и сделать это менее чем за 0,05 секунд. А это включает проверку соответствия таргетингов заданным рекламным кампаниям, контроль бюджета, предсказание «нужности» показа для рекламодателя и еще много чего. Чем больше логики и чем она сложнее, тем больше машинного времени нужно на каждое событие. Чем больше машинного времени требуется в сумме, тем дороже и сложнее инфраструктура, которая все это счастье обслуживает. Важный критерий в работе DSP – стоимость обслуживания 1 000 000 запросов. Чем ниже эта цена (при сопоставимых возможностях DSP), тем выгоднее это рекламодателю.
Так какова же роль троттлинга в DSP системах?
По сути это механизм предварительной фильтрации входящих запросов с целью снижения стоимости обслуживания 1 000 000 запросов. Задача троттлинга – с минимальным машинным временем (нагрузкой на инфраструктуру) откинуть запросы которые скорее всего не будут выкуплены и отдать в сложную бизнес-логику (где проверяются таргетинги и остальная логика) те запросы, которые потенциально интересны рекламодателям. Чем совершеннее система троттлинга, тем дешевле обслуживание 1 000 000 запросов и тем качественнее закупка (троттлинг не выкидывает нужные запросы).
Принципов работы троттлинга может быть очень много:
🔹троттлинг-монетка. Примитивный случай, когда система случайным образом «пускает» во внутреннюю логику нужное количество запросов, например, каждый 10-й (количество регулируется вручную);
🔹баджет-троттлитнг. Более продвинутый случай, когда система так же случайным образом выбирает нужное количество запросов, но их объем зависит от бюджета рекламной кампании и его исполнямости (чем больше отставания от планового бюджета в момент времени, тем больше пропускается трафика в бизнес-логику. Делитель постоянно пересчитывается);
🔹предикт-троттлинг. Еще более продвинутый случай, когда помимо контроля исполняемости бюджета, как в примере выше, троттлинг пропускет показы не случайно, а по какой-то предиктивной модели скоринга. Например, все показы с минимальным машинным временем скорятся на вероятность совершения нужного действия – клика и т.д. В данном случае помимо того, что контролируется нужный объем инвентаря для исполнения бюджета, пропускается трафик более полезный (например, более кликабельный), чем со случайным делителем.
Прекрасный пример троттлинга не из рекламной сферы – работа коллайдера CERN. В процессе столкновения частиц в секунду генерируется 40 терабайт данных. Хранить и обрабатывать данные в таком объеме практически невозможно. Для этого в детекторах есть два уровня троттлинга, снижающих количество данных с 40 тб/сек до 1гб/сек, то есть тротлинг пускает дальше на обработку 1/40 000 всех событий. При этом качество работы троттлинга такое, что даже столь сильная фильтрация не помешала сделать выдающиеся открытия!
Небольшая преамбула: технологии в prоgrammatic – это высокие нагрузки на инфраструктуру. Фраза Real Time в аббревиатуре RTB подразумевает что скорость ответа на bid не должна превышать 0,05 с. При этом только в России в среднем в секунду разыгрывается 15 000 показов. Это значит, что каждую секунду DSP должно 15 000 раз принять решение о покупке показа и сделать это менее чем за 0,05 секунд. А это включает проверку соответствия таргетингов заданным рекламным кампаниям, контроль бюджета, предсказание «нужности» показа для рекламодателя и еще много чего. Чем больше логики и чем она сложнее, тем больше машинного времени нужно на каждое событие. Чем больше машинного времени требуется в сумме, тем дороже и сложнее инфраструктура, которая все это счастье обслуживает. Важный критерий в работе DSP – стоимость обслуживания 1 000 000 запросов. Чем ниже эта цена (при сопоставимых возможностях DSP), тем выгоднее это рекламодателю.
Так какова же роль троттлинга в DSP системах?
По сути это механизм предварительной фильтрации входящих запросов с целью снижения стоимости обслуживания 1 000 000 запросов. Задача троттлинга – с минимальным машинным временем (нагрузкой на инфраструктуру) откинуть запросы которые скорее всего не будут выкуплены и отдать в сложную бизнес-логику (где проверяются таргетинги и остальная логика) те запросы, которые потенциально интересны рекламодателям. Чем совершеннее система троттлинга, тем дешевле обслуживание 1 000 000 запросов и тем качественнее закупка (троттлинг не выкидывает нужные запросы).
Принципов работы троттлинга может быть очень много:
🔹троттлинг-монетка. Примитивный случай, когда система случайным образом «пускает» во внутреннюю логику нужное количество запросов, например, каждый 10-й (количество регулируется вручную);
🔹баджет-троттлитнг. Более продвинутый случай, когда система так же случайным образом выбирает нужное количество запросов, но их объем зависит от бюджета рекламной кампании и его исполнямости (чем больше отставания от планового бюджета в момент времени, тем больше пропускается трафика в бизнес-логику. Делитель постоянно пересчитывается);
🔹предикт-троттлинг. Еще более продвинутый случай, когда помимо контроля исполняемости бюджета, как в примере выше, троттлинг пропускет показы не случайно, а по какой-то предиктивной модели скоринга. Например, все показы с минимальным машинным временем скорятся на вероятность совершения нужного действия – клика и т.д. В данном случае помимо того, что контролируется нужный объем инвентаря для исполнения бюджета, пропускается трафик более полезный (например, более кликабельный), чем со случайным делителем.
Прекрасный пример троттлинга не из рекламной сферы – работа коллайдера CERN. В процессе столкновения частиц в секунду генерируется 40 терабайт данных. Хранить и обрабатывать данные в таком объеме практически невозможно. Для этого в детекторах есть два уровня троттлинга, снижающих количество данных с 40 тб/сек до 1гб/сек, то есть тротлинг пускает дальше на обработку 1/40 000 всех событий. При этом качество работы троттлинга такое, что даже столь сильная фильтрация не помешала сделать выдающиеся открытия!
Это что-то аналогичное pretargeting в AdX?
BS
Спасибо Valeriya. Я упомяну Геннадию в переписке ваш быстрый и развернутый ответ.
DI
Отличный лонгрид 👍
GN
Спасибо Valeriya. Я упомяну Геннадию в переписке ваш быстрый и развернутый ответ.
Серёжа, привет. Спасибо Лере за ликбез) К слову у нас очень сильный и полезный канал в Телеграмме, где выходит очень много образовательных статей на регулярной основе. Если есть ещё вопросы, готовы ответить)
VK
Это что-то аналогичное pretargeting в AdX?
Не совсем. Претаргетинг в adx по сути ограничевает трафик который гугл льет на DSP заданными рамками (ГЕО, формат, сегменты и так далее)
В нашем случае задача тротлинга иная. Льется куча трафика на нас, порядка 15 000 QPS. Все их прогонять по внутренне бизнес логике DSP приложения аппаратно накладно. Это запрос в Aerospike на сегменты, это расчет вероятсностей по разным предиктам, это расчет градиента на суточную кривую затрат в рамках конкретной РК (скорость и равномерность затрат бюджета), это прогон воронки таргетингов (гео, домен и тд) И это на каждую кампанию, а потом аукцион внутри между компаниями. Суть тротлинга в нашем случае, это снизить количество запросов, которые попадают во внутреннюю логику приложения, чтобы в пустую не греть воздух в ДЦ кучей серверов. И как Лера писала выше, есть разные варианты, от "тупого" - проспускать % от общего трафика в бизнес логику (в таком случае явно умирает нормальный ретаргетинг, так как в тупую часть нужных бидов по нужным людям проподает), до "умного" - пропускать какой то % во внутреннюю бизнес логику, но тех запросов, которые максимально вероятно будут нужны под нужные(и цели, например клик или конверсия) задачи активных кампаний. И этот трафик уже прогонять по бизнес логике.
Как то так)
В нашем случае задача тротлинга иная. Льется куча трафика на нас, порядка 15 000 QPS. Все их прогонять по внутренне бизнес логике DSP приложения аппаратно накладно. Это запрос в Aerospike на сегменты, это расчет вероятсностей по разным предиктам, это расчет градиента на суточную кривую затрат в рамках конкретной РК (скорость и равномерность затрат бюджета), это прогон воронки таргетингов (гео, домен и тд) И это на каждую кампанию, а потом аукцион внутри между компаниями. Суть тротлинга в нашем случае, это снизить количество запросов, которые попадают во внутреннюю логику приложения, чтобы в пустую не греть воздух в ДЦ кучей серверов. И как Лера писала выше, есть разные варианты, от "тупого" - проспускать % от общего трафика в бизнес логику (в таком случае явно умирает нормальный ретаргетинг, так как в тупую часть нужных бидов по нужным людям проподает), до "умного" - пропускать какой то % во внутреннюю бизнес логику, но тех запросов, которые максимально вероятно будут нужны под нужные(и цели, например клик или конверсия) задачи активных кампаний. И этот трафик уже прогонять по бизнес логике.
Как то так)
RN
Не совсем. Претаргетинг в adx по сути ограничевает трафик который гугл льет на DSP заданными рамками (ГЕО, формат, сегменты и так далее)
В нашем случае задача тротлинга иная. Льется куча трафика на нас, порядка 15 000 QPS. Все их прогонять по внутренне бизнес логике DSP приложения аппаратно накладно. Это запрос в Aerospike на сегменты, это расчет вероятсностей по разным предиктам, это расчет градиента на суточную кривую затрат в рамках конкретной РК (скорость и равномерность затрат бюджета), это прогон воронки таргетингов (гео, домен и тд) И это на каждую кампанию, а потом аукцион внутри между компаниями. Суть тротлинга в нашем случае, это снизить количество запросов, которые попадают во внутреннюю логику приложения, чтобы в пустую не греть воздух в ДЦ кучей серверов. И как Лера писала выше, есть разные варианты, от "тупого" - проспускать % от общего трафика в бизнес логику (в таком случае явно умирает нормальный ретаргетинг, так как в тупую часть нужных бидов по нужным людям проподает), до "умного" - пропускать какой то % во внутреннюю бизнес логику, но тех запросов, которые максимально вероятно будут нужны под нужные(и цели, например клик или конверсия) задачи активных кампаний. И этот трафик уже прогонять по бизнес логике.
Как то так)
В нашем случае задача тротлинга иная. Льется куча трафика на нас, порядка 15 000 QPS. Все их прогонять по внутренне бизнес логике DSP приложения аппаратно накладно. Это запрос в Aerospike на сегменты, это расчет вероятсностей по разным предиктам, это расчет градиента на суточную кривую затрат в рамках конкретной РК (скорость и равномерность затрат бюджета), это прогон воронки таргетингов (гео, домен и тд) И это на каждую кампанию, а потом аукцион внутри между компаниями. Суть тротлинга в нашем случае, это снизить количество запросов, которые попадают во внутреннюю логику приложения, чтобы в пустую не греть воздух в ДЦ кучей серверов. И как Лера писала выше, есть разные варианты, от "тупого" - проспускать % от общего трафика в бизнес логику (в таком случае явно умирает нормальный ретаргетинг, так как в тупую часть нужных бидов по нужным людям проподает), до "умного" - пропускать какой то % во внутреннюю бизнес логику, но тех запросов, которые максимально вероятно будут нужны под нужные(и цели, например клик или конверсия) задачи активных кампаний. И этот трафик уже прогонять по бизнес логике.
Как то так)
Валера, ты по поводу 15 000 QPS ничего не путаешь? Да ведь Яндекс с Гуглом это под 50к, если не ошибаюсь.
VK
С нашими Российским 15 000 - 20000 QPS проблема тротлинга не столь критична конечно, но где то в Китае или США или в них вместе взятых 1 000 000 QPS это проблема очень актуальна.
VK
Я доподлинно не знаю сколько дает в сумме Яндекс и Гугл, но мы слушаем не все от них, ограничевая тем же претаргетингом, ибо смысла нет с объемом денег в РФ. 15К QPS более чем достаточно) Например мы в претаргетинге гугла не слушаем не сматченных и тех, которые сматченные, но у нас на них нет сегментов. Ибо нет смысла особо.
Особый случай контекстуальный таргетинг, когда не важно юзер особо, а важно контент. Мы его решаем отдельным проетаргетингом, если очень нужно и не хватает инвентаря в рамках 15К QPS
Особый случай контекстуальный таргетинг, когда не важно юзер особо, а важно контент. Мы его решаем отдельным проетаргетингом, если очень нужно и не хватает инвентаря в рамках 15К QPS
VK
В общем время мериться QPS прошло как мне кажется)
A
Привет всем!
Минуточку внимания!
У нас тут открылась вакансия Групхеда в программатик-департамент.
Слаще условий и представить себе нельзя: прекрасная команда, умные и здравомыслящие клиенты, уютный офис, страховка со стоматологией, множество других плюшек.
Очень хотим найти профессионала высокого уровня, чтобы развивать его дальше в нашей команде всякими интересными задачками :)
Если вам скучно и уныло, если начальство не повышает, если надоела игра "включи кондиционер, нет, выключи кондиционер, нет, включи!", если хочется ваять стратегии и запускать всякие интересные штуки, а вы вместо этого снимаете скриншоты и пишете отчёты (и считаете, что микроскопом гвозди забивать нечестно))), потому что "больше некому", то напишите мне, мы в состоянии предложить вам работу поинтереснее :))))
Минуточку внимания!
У нас тут открылась вакансия Групхеда в программатик-департамент.
Слаще условий и представить себе нельзя: прекрасная команда, умные и здравомыслящие клиенты, уютный офис, страховка со стоматологией, множество других плюшек.
Очень хотим найти профессионала высокого уровня, чтобы развивать его дальше в нашей команде всякими интересными задачками :)
Если вам скучно и уныло, если начальство не повышает, если надоела игра "включи кондиционер, нет, выключи кондиционер, нет, включи!", если хочется ваять стратегии и запускать всякие интересные штуки, а вы вместо этого снимаете скриншоты и пишете отчёты (и считаете, что микроскопом гвозди забивать нечестно))), потому что "больше некому", то напишите мне, мы в состоянии предложить вам работу поинтереснее :))))
DM
если надоела игра "включи кондиционер, нет, выключи кондиционер, нет, включи!"