Кросс-канальная оптимизация рекламного бюджета: AI, MMM и incrementality

Рекламный бюджет часто распределяется по прошлому периоду, а не по реальному вкладу каналов. Мы разрабатываем единую модель кросс-канального планирования под ключ: от сверки данных до регламента регулярных пересчётов. Заказчик получает прозрачное распределение и обоснование каждой доли.
Часто задаваемые вопросы

Почему оптимизация рекламного бюджета ломается на сквозной аналитике

Классический сбой начинается на стыке систем: рекламная платформа записывает конверсию на себя, CRM — на звонок менеджера, веб-аналитика — на последний переход. Одна покупка учитывается трижды, дублирование конверсий завышает итог по каждому каналу, а расхождение атрибуции каналов даёт разницу в разы между отчётами, которым при этом верят одновременно. Окна атрибуции и модели у систем разные, поэтому даже итоговая сумма заказов за период не сходится.

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

Кросс-канальная отчётность в таком виде не отвечает на главный вопрос — что было бы без этого вложения. Разбираем, как это закрывается: сводим каналы к единой системе координат, отделяем перехват от создания спроса и проверяем вклад замером, а не атрибуцией, — только после этого перераспределяем бюджет.

Эффект от единой модели кросс-канального планирования

После внедрения единой модели планирования меняется не отчёт, а способ принимать решения. Модель на Marketing Mix Modeling, откалиброванная тестами инкрементальности, видит пересечение аудиторий и перенос спроса между каналами — поэтому эффект перераспределения каналов считается до запуска, а не объясняется после. Доля инкрементальных конверсий становится основной метрикой, а скорость пересборки плана падает с нескольких дней ручной сверки до нескольких часов: новый сценарий прогоняется на тех же данных и сравнивается с базовым.

Что уходит из отчётности

Снимается класс ошибок с двойным учётом: одна и та же конверсия перестаёт попадать одновременно в платформенную статистику, в атрибуцию и в отчёт по нижнему уровню. Уходят ошибки горизонта — сравнение каналов на разных окнах конверсии без поправки на задержку между контактом и действием. Закрывается и ошибка экстраполяции: вес переносится туда, где отдача измерена на достаточном объёме, а не туда, где данных просто больше.

Как измеряем эффект без привязки к деньгам

Считаем поведение, а не стоимость: долю инкрементальных конверсий по гео-тестам, долю показов, которые модель относит к заведомо неэффективным, и устойчивость оценки канала между прогонами. Отдельная метрика — скорость пересборки плана: сколько времени проходит от новой вводной до готового сценария с пересчитанным распределением. Если оценка канала между прогонами расходится сильнее заданного порога, модель не допускается до перераспределения — это тоже проверяемый результат, а не обещание.

Сравнение подходов: правила, модели и полевые тесты

Ни один подход не «правильный» сам по себе — выбор определяется объёмом накопленных данных, скоростью изменений в канале и ценой ошибки. Ниже — рабочие альтернативы, между которыми реально выбирают при распределении вложений.

Вариант Когда подходит Ограничения
Эвристические правила распределения Каналов немного, история короткая, доли пересматриваются еженедельно Не видят насыщения: доля растёт, отдача падает, а правило продолжает отдавать в тот же канал
Маркетинговая модель смешанного эффекта Есть длинный ряд недельных данных по всем каналам, нужна оценка вклада каждого Чувствительна к внешним факторам, путает связь с причиной, переобучается при смене сообщений
Полевой тест инкрементальности Крупный канал, высокая цена ошибки, нужна проверка причинности Идёт неделями, сужает охват на время теста, плохо масштабируется на десятки мелких каналов

Когда хватает эвристических правил

Если вложений немного, каналы стабильны, а решения пересматриваются часто, достаточно правил с лимитами и стоп-условиями. Их сила — прозрачность: видно, почему доля канала изменилась, и правило легко откатить. Слабое место — насыщение: правило не замечает, что следующий шаг в тот же канал даёт меньше отдачи.

Когда без полевых тестов не обойтись

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

Как мы внедряем модель распределения: этапы работ

Работа идёт от данных к модели, а затем к регламенту пересчёта: пока не собран сопоставимый поток событий, оптимизация превращается в подгонку под отчёт. Поэтому этапы идут строго по порядку, с приёмкой на каждом.

Аудит данных и источников

  1. Инвентаризация источников: выгрузки из рекламных кабинетов, счётчики веб-аналитики, CRM, звонки, офлайн-продажи. Проверяем, где есть расходы и целевые действия, а где данные приходят только суточными агрегатами.
  2. Схема сбора событий: единый идентификатор пользователя, склейка сессий между устройствами, дедупликация заявок, корректные часовые пояса. Без этого доля сопоставимых конверсий падает в разы, и модель учится на шуме.
  3. Сверка и разметка: сопоставляем события с расходами по дням, восстанавливаем пропуски, помечаем периоды тестов и простоев кампаний — иначе они искажают обучение.

Проверка на исторических данных

  • Настройка модели: признаки (канал, креатив, день недели, сезонность), лаг между показом и покупкой, насыщение канала и регулярность пересчёта.
  • Обратный прогон: модель обучается на прошлом, прогноз сравнивается с фактом по каждому каналу. Смотрим не среднее отклонение, а ошибку на периодах, когда бюджеты менялись.
  • Калибровка по инкрементальным тестам: поднимаем контрольные группы и правим вклад каналов по фактическому приросту, а не по последнему клику.
  • Передача в эксплуатацию: расписание пересчёта, пороги оповещений об аномалиях в данных, панель с вкладом каналов и регламент, по которому команда сама меняет распределение.

Что передаём на руки: артефакты, схемы и регламенты

Работу сдаём не презентацией, а рабочим контуром: после запуска ваша команда сама пересчитывает модель, подключает новые каналы и проверяет гипотезы. Ниже — что именно остаётся у вас в репозитории, в хранилище и в документации.

Артефакты модели

  • Настроенные коннекторы к рекламным кабинетам, веб-аналитике и внутреннему учёту — данные приходят по расписанию, без ручных выгрузок.
  • Схема потоков данных: по каждому показателю видно источник, этап очистки и слой, на котором он попадает в модель.
  • Правила пересчёта показателей: как сверяются расхождения между кабинетами и учётом, какая версия цифры считается истиной.
  • Код обучения и пересчёта в репозитории с описанием параметров и эталонных прогонов.
  • Контур проверки вклада каналов: гео-тесты и контрольные группы, план замеров на несколько периодов вперёд.
  • Дашборд с разложением вклада каналов и отчётом о перераспределении бюджета.

Документация и регламенты

  • Документация модели: предпосылки, ограничения, чувствительность к входным данным и типовые причины расхождений.
  • Регламент регулярного пересмотра: триггеры (изменение ставок, новый канал, сезонный сдвиг) и порядок действий по каждому.
  • Журнал решений: что менялось в модели, когда и на каком основании.
  • Передача знаний команде: совместные разборы, выданные доступы, короткие инструкции по запуску и откату версии.

Кейс: убрали дублирование конверсий в двух каналах

Ритейлер с двумя активными каналами привлечения — поиск и соцсети — столкнулся с тем, что решения о бюджете принимались по отчётам, которые противоречили друг другу. Мы разобрали цепочку атрибуции и развели засчитанные конверсии.

Что было до

Каждый канал считал одну и ту же покупку своей: клиентский счётчик на сайте и серверное событие из приложения складывались, а не сопоставлялись. В отчётности доля завышенных конверсий доходила до 34%, а оценки вклада каналов в одни и те же продажи расходились на ±40%. Чтобы свести цифры в одну картину, маркетолог вручную выгружал данные из AppsFlyer и рекламных кабинетов — на сверку уходило до двух рабочих дней в неделю.

Что стало после

Мы поставили единый идентификатор пользователя на входе и убрали двойное засчитывание на уровне модели атрибуции: событие приходит один раз, а канал получает признак «первый» или «подтверждающий». Доля завышенных конверсий упала до 4%, расхождение оценок между каналами сузилось до ±7%, ручная сверка заняла 40 минут вместо двух дней.

Бюджет теперь перераспределяется по данным, а не по тому, чей отчёт убедительнее. Инкрементальные тесты подтвердили: часть расходов на верхнем уровне воронки работала на уже прогретых пользователей — после переразметки эти средства ушли в каналы с подтверждённым приростом продаж.

Атрибуция и модель смешанного эффекта расходятся: кому верить?

Атрибуция последнего клика и модель смешанного эффекта отвечают на разные вопросы, поэтому расхождение между ними — норма, а не сбой. Атрибуция делит заслугу внутри учтённых касаний и завышает долю нижних каналов: поиск и ретаргетинг получают кредит за спрос, который создали охватные размещения. Модель смешанного эффекта работает на агрегированных данных и видит спрос, которого атрибуция не учитывает.

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

Источник оценки На какой вопрос отвечает Где ограничение
Атрибуция последнего клика Кто был в цепочке касаний Не видит внешний спрос, завышает нижние каналы
Модель смешанного эффекта Вклад каналов в продажи Опирается на корреляцию, чувствительна к данным
Гео-тест с контрольной группой Сколько продаж исчезнет без канала Долгая подготовка, мало параллельных проверок

Примиряем это калибровкой: результаты замеров становятся ориентиром для модели смешанного эффекта. Открытые реализации вроде Meridian дают байесовскую оценку вклада каналов, но и её мы проверяем экспериментом, а не принимаем на веру. Атрибуцию оставляем для ежедневного управления внутри канала, а бюджет перераспределяем по калиброванной модели — по интервалам, а не по точечным числам.

Частые технические сомнения по данным и модели

Данные из рекламных кабинетов и систем аналитики редко приходят в модель готовыми: где-то ряд короче нужного, где-то выгрузка отстаёт на несколько дней, а структура кампаний меняется быстрее, чем копится история. Ниже — сомнения, которые чаще всего звучат при передаче модели, и то, как мы закрываем их на уровне подготовки данных и настройки.

Что делать с неполной историей и пропусками в данных?

Короткий или дырявый ряд не тянет сложную модель: ограничиваем число параметров, объединяем близкие каналы в группы, пропуски заполняем интерполяцией с отдельным флагом достоверности. Если истории меньше базового минимума, канал выводим из модели, а его вклад считаем отдельными тестами.

Как быть с задержкой выгрузок из кабинетов?

Статистика приходит с лагом, часть атрибуции достраивается позже. Модель обучаем на устоявшихся срезах, свежие дни помечаем как предварительные, а после стабилизации данных заменяем фактом и пересчитываем прогноз.

Не перепутает ли модель сезонность с эффектом рекламы?

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

Кабинеты меняют структуру кампаний — модель развалится?

Привязка идёт не к кампании, а к устойчивым срезам: канал, тип размещения, гео, сегмент аудитории. При слиянии или переименовании ряд пересобирается по таблице соответствий, история сохраняется. Крупные перестройки помечаем как точки разрыва и обучаем модель отдельно до и после них.

Как часто переобучать модель?

Базовый цикл — плановый пересчёт коэффициентов и полный пересмотр модели раз в квартал, плюс постоянный контроль расхождения прогноза с фактом. Если ошибка выходит за допустимый коридор несколько периодов подряд, запускаем внеплановое переобучение, чтобы модель реагировала на сдвиги, но не переучивалась на шуме.

Обсудим задачу: что нужно, чтобы стартовать

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

  • Постановка задачи: какую цель закрываем — рост доли, снижение стоимости привлечения, перераспределение между каналами — и по какому показателю судите о результате.
  • Перечень источников: рекламные кабинеты, веб- и продуктовая аналитика, CRM, выгрузки по заказам и выручке; за какой период сохранена история.
  • Доступы к данным: аккаунты с правами только на чтение, доступ к хранилищу или регулярным выгрузкам и контакт человека, который подтверждает эти права.
  • Текущая логика атрибуции и распределения бюджета — точка отсчёта, от которой считаем улучшение.
  • Ограничения: обязательные площадки, брендовые кампании, сезонные пики, рамки для экспериментов.
  • Ритм принятия решений: раз в неделю или раз в месяц — от этого зависит частота пересчёта и формат отчётности.

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

Направления AI-разработки

Последние работы

  • Разработка сайта компании B2B ADVANCE
    Разработка сайта компании B2B ADVANCE
    1543
  • Разработка веб-приложения для компании FEEDME
    Разработка веб-приложения для компании FEEDME
    1394
  • Разработка веб-сайта для компании БЕЛФИНГРУПП
    Разработка веб-сайта для компании БЕЛФИНГРУПП
    1081
  • Разработка интернет магазина для компании FURNORO
    Разработка интернет магазина для компании FURNORO
    1374
  • Разработка логотипа компании B2B Advance
    Разработка логотипа компании B2B Advance
    816
  • Разработка веб-приложения для компании Enviok
    Разработка веб-приложения для компании Enviok
    1142