Если в рекомендациях органической ленты посты ранжируются по, грубо говоря, p(click), то рекламодатель платит деньги за размещение, причём каждый по-своему. У каждого свой желаемый результат. Как их уравнять между собой?
Advertiser Value = p(event) * bidНачнём с первого.
p(event) = 1 в единственном случае - когда платят за показ. Это самая отстойная реклама, потому что рекламодатель просто хочет заплатить деньги и накормить пользователей говном. Часто, это так называемый brand advertisement, и этим занимаются крупные компании, потому что паразиты-менеджеры таким образом осваивают бюджеты. Реклама газпрома или макдональдса по телеку - в принципе то же самое.Чуть выше в иерархии находится
event=click. Если в предыдущем случае условному макдональдсу всё равно, кто увидит их пост, то здесь уже появляется намёк на релевантность и становится нужна модель, которая предскажет p(click). У рекламодателя появляется стимул сделать рекламу более интересной и кликабельной, в то же время пользователь перестаёт видеть совсем уж нерелевантный мусор. Главная беда кликов - они не равны интересу к покупке. Люди будут кликать на самую абсурдную рекламу потому что им любопытно. Смотреть на рекламу с самым высоким CTR это отдельный вид развлечения.Самое лучшее - это когда рекламодатель платит за событие на сайте, к примеру,
event=purchase. С предсказанием p(purchase) главная проблема - это, собственно, получение данных. Существует опция Conversion API - рекламодатель отчитывается о покупках сам, дёргая специальную ручку. Что он вам там наприсылает и как этому верить - вопрос отдельный. Более традиционным подходом является так называемый пиксель. Рекламодатель добавляет на страницы своего сайта чужой JS-код, например, meta или яндекса, и он сам занимается отправкой данных на сервера рекламной платформы. Потом это кое-как джойнится к показам.Итак, переходим к
bid - это ставка за событие. Это не то, что должен выбирать сам рекламодатель. В идеальном мире, он лишь задаёт общее ограничение на бюджет - скажем, 1000$ в день. Bid выбирается автоматически с помощью компоненты под названием Pacing. Её смысл простой - если рекламодатель тратит свои деньги медленнее, чем выставлен его бюджет, то bid растёт. Если быстрее, то падает. Клиентам по понятным причинам нравится, когда бюджет тратится равномерно и полностью.В таком сетапе любая, даже самая хуёвая реклама, будет откручиваться на все деньги, но показ хуёвой рекламы выйдет сильно дороже, бюджета хватит на меньшее число показов, и пользователи будут меньше от неё страдать. Такой само-балансирующийся рыночек получается.
Если клиенту дают выбрать bid самостоятельно, это в любом случае неоптимально - он либо просадит свои деньги слишком быстро, показывая всем подряд, либо наоборот не покажет никому. Но может быть клиент не хочет тратить бюджет, если дешёво не получается. Хозяин - барин.
Начинаем аукцион. Собираем со всех рекламодателей их ставки, получаем
p(event) от модели (или =1 в случае показа). Для каждого считаем Advertiser Value. Выбираем победителя, но расчёт стоимости события делаем согласно Advertiser Value второго места, а не его собственного. Но почему?Теория игр даём нам довольно интересный результат касательно First Price Auction vs Second Price Auction.
У First Price Auction есть неочевидная проблема - для вас, как участника, оптимальная стратегия зависит не только от вашей личной выгоды от выигрыша, но и от стратегии оппонента. Вам выгодно угадать ставку второго места и поставить чуть больше неё, Если вы знаете, что все ставят мало, вы будете занижать ставку, и наоборот.
В то же время, в Second Price Auction существует одна оптимальная стратегия, которая не зависит от ставок других игроков - каждому выгодно ставить максимальную сумму, которую готовы заплатить. Вот здесь небольшое видео на эту тему.
Вот такого упрощённого ядра системы достаточно для работающей рекламы. Когда шипнули, осталось за малым - починить баги. А там уже и на пенсию.
@knowledge_accumulator