Я хочу здесь описать кейс с одним из лучших (на мой взгляд) способов управления лимитами дневных бюджетов для контекстных рекламных кампаний. Мне кажется подобная схема может подойти компаниям с не прямой монетизацией трафика, например для досок объявлений (classifieds), в тематике авто, недвижимости и всего-на-свете. Возможно не только им.

Это мой первый опыт написания публичных статей, так что сорри, если что не так. Буду рад конструктивным комментариям.

Почему с не прямой монетизацией?


Потому что компании у которых монетизация прямая и достаточно хорошо вычисляется ROI могут себе позволить инвестировать в рекламный источник до предела его емкости, до тех пор пока инвестиции окупаются. А вот сайты типа досок объявлений зачастую не могут себе этого позволить. Т.к. не имеют жесткой связи с возвратом инвестиций, т.к. сами не продают товары и услуги, а работают по рекламной модели. Проще говоря: сегодня можно потратить очень много денег в контексте, но завтра от этого у classified сайта не появится больше рекламных контрактов.

Поэтому для таких сайтов привлеченный из контекстной рекламы трафик монетизируется косвенно, с временной задержкой, и только часть трафика имеет прямую монетизацию, скажем в звонки.

темы для отдельного разговора
Темы медиапланирования, важности и способов построения сильного бренда, способы оценки влияния имиджевых РК на Performance кампании здесь стоит упомянуть, но они не будут затронуты.

В рамках данного эссе предположим, что нас уже есть медиаплан с бюджетом на следующий месяц и работающие рекламные аккаунты. Что дальше?

Как обычно выглядят рекламные аккаунты таких компаний?


  1. Скорее всего рекламных аккаунтов будет минимум два. Яндекс Директ и Google Ads и в этом плане нам сильно повезло, потому что конкуренция всегда лучше ее отсутствия, и это прекрасное поле для здоровой оптимизации
  2. Возможно рекламных аккаунтов будет еще больше, например из-за того что по разным аккаунтам разделены кампании по принципу целевого действия, проекту, команде сопровождения или по другому признаку
  3. Внутри каждого рекламного аккаунта будет набор рекламных кампании (РК), допустим их названия будут указывать на некоторый способ классификации кампаний (например, по регионам, по проектам, по типам размещения, по платформе)

В общем совершенно нормальной оказывается ситуация, когда количество всех рекламных кампаний довольно большое, скажем порядка нескольких тысяч. Конечно они как-то кластеризуются и там как правило присутствует логика, по которой можно выбрать то или иное подмножество кампаний, чтобы посмотреть статистику или провести ревизию настроек, или внести массовое изменение.

тема для отдельного разговора: когда делить кампании
Хочу отметить, лично мне гораздо приятнее работать с аккаунтами, в которых есть «симметрия настроек». Я понимаю под симметрией следующее: если какой-то тип кампании заведен для одного из городов/проектов, то аналог этой кампании есть для всех регионов/проектов. Хорошо когда заведены максимально близкие по смыслу и настройкам кампании в Яндекс и Google. Такую развесистую систему немного тяжелее сопровождать, необходимо отслеживать чтобы обновления в РК приезжали симметрично, даже если они на паузе, но когда возникает необходимость их включить, то не приходится в панике заводить синхронизировать все настройки и вспоминать весь опыт уже аккумулированный в рабочих кампаниях.

С таким большим набором РК довольно сложно назначить дневные бюджеты. Этим мы и постараемся заняться.

Взглянем в медиаплан на следующий месяц


Давайте узлом медиаплана назовем сочетание всех признаков классификации, для которых задан бюджет на следующий месяц. Допустим определены (регион, продукт, и тип сделки, скажем аренда или продажа) и указан бюджет.

Скорее всего для узла в МП будет задан не только бюджет, но и целевые показатели по стоимости конверсии. Позволю себе, на мой взгляд, важное замечание:
Для назначения дневных бюджетов и попадания в МП по бюджету, целевые показатели стоимости конверсии совершенно не важны. Поэтому просто не смотрим на них сейчас. В дальнейшем я постараюсь объяснить почему.

тема для отдельного разговора: целевые показатели по медиаплану
Темами для отдельного разговора будут способы назначения ставок, встроенные автостратегии Яндекс и Google, кастомные биддеры. Ставки и автостратегии один из важных рычагов достижения целей по стоимости конверсии. При этом не единственный.


Постановка задачи


Мало ли что в этом мире бывает, но я почти 100% уверен в следующем утверждении:
Количество узлов медиаплана будет всегда меньше или равно количеству рекламных кампаний во всех аккаунтах.
После введения этой леммы мы можем говорить об объединении рекламных кампаний в пакеты, таким образом чтобы пакет соответствовал узлу медиаплана. Теперь наша задача будет формулироваться следующим образом:
Необходимо распределить бюджет по кампаниям в пакете таким образом чтобы максимизировать количество закупленных конверсий на заданный бюджет.
Вот и все! на этом можно было бы закончить.
Поясню. Мы пришли к формулировке классической задачи о рюкзаке. В качестве объема рюкзака выступает размер бюджета, в качестве ценности камней выступают данные о стоимости конверсии. Жадный алгоритм — основа решения подобных задач. Рекомендую погуглить и почитать про задачу о рюкзаке подробнее.

В двух словах: кампании в пакете должны выстраиваться по возрастанию фактической стоимости конверсии (конверсия м.б. составная с назначенными ценностями). Тем кампаниям, которые могут потратить больше и находятся наверху списка должна такая возможность предоставляться. Те кампании, которые оказываются внизу списка в случае дефицита бюджета должны сокращаться в первую очередь.

Таким образом происходит отбор самых дешевых РК на указанный бюджет в пакете. Поэтому как я указывал ранее, целевые показатели по стоимости применительно к этой задаче не важны (при этом они конечно важны в целом, но учитываются скорее при управлении ставками). Важно просто набрать максимум конверсий на указанный бюджет.

Сильные стороны подхода


  • Не важно из-за чего отдельная рекламная кампания стала вести себя лучше или хуже, как там поменялись настройки, ставки или рынок. Если такой бюджетировщик проходит по аккаунтам несколько раз в неделю со временем показатели такой кампании будут взвешены относительно других кампаний в пакете и ей будет назначен справедливый дневной бюджет.
  • Можно перестать думать о бюджетировании кампаний совсем и сосредоточить фокус внимания на заведении новых качественных РК и на сопровождении старых (по гайдам, креативно, с периодическим обновлением и т.п.)
  • Реализуется конкуренция между кампаниями Яндекс и Google. :)

Слабые стороны подхода


  • Скорость сходимости решения изо дня в день к оптимуму не мгновенная. Частично можно уменьшить этот эффект задавая вручную нужный бюджет в течении нескольких иттераций перебюджетировщика. Далее он подхватит тренд на основании накопленной статистики. Но нужно руководствоваться здравым смыслом
  • Когда в пакете мало РК нет пространства для оптимизации
  • Когда в пакете много РК может накапливаться перетрата, т.к. возможен эффект суммирования небольших перетрат на множестве РК, в случае если бюджет для них ограничен
  • Жадный алгоритм находит локальный оптимум
  • Стоимость конверсии в общем случае не является константой. Это как если бы ценность камня в задаче о рюкзаке не была бы константой.

Особенности


  • бюджеты между пакетами (узлами медиаплана) не перетекают

Комментарии по реализации


  1. очевидно по кампаниям должен происходить ежедневный сбор статистики из аккаунтов контекстной рекламы и из систем счетчиков, например Google Analytics или Яндекс Метрика
  2. результирующий отчет должен где-то храниться, в данном случае подходит любая БД, но удобнее всего на мой вкус Google BigQuery
  3. Для анализа данных и построения отчетов можно использовать Jupyter блокнот. Так же на мой вкус лучше Google Colab, т.к. легко организуется совместная работа в команде (как в Google Docs)
  4. Нужен сервер, на котором будет периодически запускать перебюджетировщик и происходить сбор статистики, обычно для такой задачи достаточно почти любого стандартного облачного сервера AWS или Google Cloud

Пока у меня все.

Спасибо за внимание.