Чому оптимізація рекламного бюджету ламається на наскрізній аналітиці
Класичний збій починається на стику систем: рекламна платформа записує конверсію на себе, CRM — на дзвінок менеджера, веб-аналітика — на останній перехід.
Одна покупка враховується тричі, дублювання конверсій завищує підсумок за кожним каналом, а розбіжність атрибуції каналів дає різницю в рази між звітами, яким при цьому вірять одночасно.
Вікна атрибуції та моделі в систем різні, тому навіть підсумкова сума замовлень за період не сходиться.
Оптимізація рекламного бюджету в такій схемі перетворюється на перекладання вкладень вручну: вивантаження зводять у таблицю, зіставляють за датами й на око вирішують, кому додати, а кому урізати.
Поки рішення доходить до кабінету, минає тиждень — аукціон і ставки вже інші, а сигнал застарів. Так закріплюється помилка розподілу вкладень: канал, який перехоплює готовий попит, виглядає найкращим і отримує зростання, а канал, що формує попит, урізають.
Крос-канальна звітність у такому вигляді не відповідає на головне питання — що було б без цього вкладення.
Розбираємо, як це закривається: зводимо канали до єдиної системи координат, відокремлюємо перехоплення від створення попиту й перевіряємо внесок вимірюванням, а не атрибуцією, — лише після цього перерозподіляємо бюджет.
Ефект від єдиної моделі крос-канального планування
Після впровадження єдиної моделі планування змінюється не звіт, а спосіб ухвалювати рішення.
Модель на Marketing Mix Modeling, відкалібрована тестами інкрементальності, бачить перетин аудиторій і перенесення попиту між каналами — тому ефект перерозподілу каналів рахується до запуску, а не пояснюється після.
Частка інкрементальних конверсій стає основною метрикою, а швидкість перезбирання плану падає з кількох днів ручної звірки до кількох годин: новий сценарій проганяється на тих самих даних і порівнюється з базовим.
Що зникає зі звітності
Знімається клас помилок із подвійним обліком: та сама конверсія перестає потрапляти одночасно в платформенну статистику, в атрибуцію та в звіт за нижнім рівнем.
Зникають помилки горизонту — порівняння каналів на різних вікнах конверсії без поправки на затримку між контактом і дією. Закривається й помилка екстраполяції: вага переноситься туди, де віддача виміряна на достатньому обсязі, а не туди, де даних просто більше.
Як вимірюємо ефект без прив'язки до грошей
Рахуємо поведінку, а не вартість: частку інкрементальних конверсій за гео-тестами, частку показів, які модель відносить до свідомо неефективних, і стійкість оцінки каналу між прогонами.
Окрема метрика — швидкість перезбирання плану: скільки часу проходить від нових вхідних даних до готового сценарію з перерахованим розподілом.
Якщо оцінка каналу між прогонами розходиться сильніше за заданий поріг, модель не допускається до перерозподілу — це теж перевірюваний результат, а не обіцянка.
Порівняння підходів: правила, моделі та польові тести
Жоден підхід не є «правильним» сам собою — вибір визначається обсягом накопичених даних, швидкістю змін у каналі та ціною помилки. Нижче — робочі альтернативи, між якими реально обирають під час розподілу вкладень.
| Варіант | Коли підходить | Обмеження |
|---|---|---|
| Евристичні правила розподілу | Каналів небагато, історія коротка, частки переглядаються щотижня | Не бачать насичення: частка зростає, віддача падає, а правило продовжує віддавати в той самий канал |
| Маркетингова модель змішаного ефекту | Є довгий ряд тижневих даних за всіма каналами, потрібна оцінка внеску кожного | Чутлива до зовнішніх факторів, плутає зв'язок із причиною, перенавчається при зміні повідомлень |
| Польовий тест інкрементальності | Великий канал, висока ціна помилки, потрібна перевірка причинності | Триває тижнями, звужує охоплення на час тесту, погано масштабується на десятки дрібних каналів |
Коли достатньо евристичних правил
Якщо вкладень небагато, канали стабільні, а рішення переглядаються часто, достатньо правил із лімітами та стоп-умовами. Їхня сила — прозорість: видно, чому частка каналу змінилася, і правило легко відкотити.
Слабке місце — насичення: правило не помічає, що наступний крок у той самий канал дає менше віддачі.
Коли без польових тестів не обійтися
Там, де модель показує внесок, але невідомо, чи був би результат без вкладення, потрібна перевірка вимкненням на частині аудиторії або географії. Тест дає причинну оцінку й калібрує модель: розбіжність прогнозу та факту показує, які канали вона переоцінює.
На практиці підходи комбінують — правила як каркас, модель для пріоритетів, тест для перевірки великих рішень.
Як ми впроваджуємо модель розподілу: етапи робіт
Робота йде від даних до моделі, а потім до регламенту перерахунку: поки не зібрано зіставний потік подій, оптимізація перетворюється на підгонку під звіт. Тому етапи йдуть строго по порядку, з прийманням на кожному.
Аудит даних і джерел
- Інвентаризація джерел: вивантаження з рекламних кабінетів, лічильники веб-аналітики, CRM, дзвінки, офлайн-продажі. Перевіряємо, де є витрати й цільові дії, а де дані надходять лише добовими агрегатами.
- Схема збору подій: єдиний ідентифікатор користувача, склеювання сесій між пристроями, дедуплікація заявок, коректні часові пояси. Без цього частка зіставних конверсій падає в рази, і модель навчається на шумі.
- Звірка та розмітка: зіставляємо події з витратами за днями, відновлюємо пропуски, позначаємо періоди тестів і простоїв кампаній — інакше вони спотворюють навчання.
Перевірка на історичних даних
- Налаштування моделі: ознаки (канал, креатив, день тижня, сезонність), лаг між показом і покупкою, насичення каналу та регулярність перерахунку.
- Зворотний прогін: модель навчається на минулому, прогноз порівнюється з фактом за кожним каналом. Дивимося не середнє відхилення, а помилку на періодах, коли бюджети змінювалися.
- Калібрування за інкрементальними тестами: піднімаємо контрольні групи й правимо внесок каналів за фактичним приростом, а не за останнім кліком.
- Передача в експлуатацію: розклад перерахунку, пороги оповіщень про аномалії в даних, панель із внеском каналів і регламент, за яким команда сама змінює розподіл.
Що передаємо на руки: артефакти, схеми та регламенти
Роботу здаємо не презентацією, а робочим контуром: після запуску ваша команда сама перераховує модель, підключає нові канали й перевіряє гіпотези. Нижче — що саме залишається у вас у репозиторії, у сховищі та в документації.
Артефакти моделі
- Налаштовані конектори до рекламних кабінетів, веб-аналітики та внутрішнього обліку — дані надходять за розкладом, без ручних вивантажень.
- Схема потоків даних: за кожним показником видно джерело, етап очищення й шар, на якому він потрапляє в модель.
- Правила перерахунку показників: як звіряються розбіжності між кабінетами й обліком, яка версія цифри вважається істиною.
- Код навчання й перерахунку в репозиторії з описом параметрів і еталонних прогонів.
- Контур перевірки внеску каналів: гео-тести й контрольні групи, план вимірювань на кілька періодів уперед.
- Дашборд із розкладанням внеску каналів і звітом про перерозподіл бюджету.
Документація та регламенти
- Документація моделі: передумови, обмеження, чутливість до вхідних даних і типові причини розбіжностей.
- Регламент регулярного перегляду: тригери (зміна ставок, новий канал, сезонний зсув) і порядок дій за кожним.
- Журнал рішень: що змінювалося в моделі, коли й на якій підставі.
- Передача знань команді: спільні розбори, видані доступи, короткі інструкції із запуску та відкату версії.
Кейс: прибрали дублювання конверсій у двох каналах
Рітейлер із двома активними каналами залучення — пошук і соцмережі — зіткнувся з тим, що рішення про бюджет ухвалювалися за звітами, які суперечили одна одній. Ми розібрали ланцюжок атрибуції й розвели зараховані конверсії.
Що було до
Кожен канал вважав ту саму покупку своєю: клієнтський лічильник на сайті та серверна подія з застосунку складалися, а не зіставлялися. У звітності частка завищених конверсій сягала 34%, а оцінки внеску каналів в одні й ті самі продажі розходилися на ±40%.
Щоб звести цифри в одну картину, маркетолог вручну вивантажував дані з AppsFlyer і рекламних кабінетів — на звірку йшло до двох робочих днів на тиждень.
Що стало після
Ми поставили єдиний ідентифікатор користувача на вході й прибрали подвійне зарахування на рівні моделі атрибуції: подія надходить один раз, а канал отримує ознаку «перший» або «підтверджувальний».
Частка завищених конверсій упала до 4%, розбіжність оцінок між каналами звузилася до ±7%, ручна звірка зайняла 40 хвилин замість двох днів.
Бюджет тепер перерозподіляється за даними, а не за тим, чий звіт переконливіший. Інкрементальні тести підтвердили: частина витрат на верхньому рівні воронки працювала на вже прогрітих користувачів — після перерозмітки ці кошти пішли в канали з підтвердженим приростом продажів.
Атрибуція й модель змішаного ефекту розходяться: кому вірити?
Атрибуція останнього кліку й модель змішаного ефекту відповідають на різні питання, тому розбіжність між ними — норма, а не збій.
Атрибуція ділить заслугу всередині урахованих дотиків і завищує частку нижніх каналів: пошук і ретаргетинг отримують кредит за попит, який створили охопні розміщення. Модель змішаного ефекту працює на агрегованих даних і бачить попит, якого атрибуція не враховує.
Проблема починається, коли з розбіжності роблять рішення щодо бюджету: одна оцінка пропонує зрізати верхні канали, друга — нарощувати.
Опорною ми вважаємо оцінку, підтверджену експериментом — вимкненням каналу або гео-тестом із контрольною групою регіонів: лише вимірювання відокремлює приріст від кореляції.
| Джерело оцінки | На яке питання відповідає | Де обмеження |
|---|---|---|
| Атрибуція останнього кліку | Хто був у ланцюжку дотиків | Не бачить зовнішній попит, завищує нижні канали |
| Модель змішаного ефекту | Внесок каналів у продажі | Спирається на кореляцію, чутлива до даних |
| Гео-тест із контрольною групою | Скільки продажів зникне без каналу | Тривала підготовка, мало паралельних перевірок |
Примиряємо це калібруванням: результати вимірювань стають орієнтиром для моделі змішаного ефекту. Відкриті реалізації на кшталт Meridian дають байєсівську оцінку внеску каналів, але й її ми перевіряємо експериментом, а не приймаємо на віру.
Атрибуцію залишаємо для щоденного управління всередині каналу, а бюджет перерозподіляємо за каліброваною моделлю — за інтервалами, а не за точковими числами.
Часті технічні сумніви щодо даних і моделі
Дані з рекламних кабінетів і систем аналітики рідко надходять у модель готовими: десь ряд коротший за потрібний, десь вивантаження відстає на кілька днів, а структура кампаній змінюється швидше, ніж накопичується історія.
Нижче — сумніви, які найчастіше звучать під час передачі моделі, і те, як ми закриваємо їх на рівні підготовки даних і налаштування.
Що робити з неповною історією та пропусками в даних?
Короткий або дірявий ряд не витягує складну модель: обмежуємо кількість параметрів, об'єднуємо близькі канали в групи, пропуски заповнюємо інтерполяцією з окремим прапорцем достовірності.
Якщо історії менше за базовий мінімум, канал виводимо з моделі, а його внесок рахуємо окремими тестами.
Як бути із затримкою вивантажень із кабінетів?
Статистика надходить із лагом, частина атрибуції добудовується пізніше. Модель навчаємо на усталених зрізах, свіжі дні позначаємо як попередні, а після стабілізації даних замінюємо фактом і перераховуємо прогноз.
Чи не переплутає модель сезонність з ефектом реклами?
Сезонність, свята й промо входять у модель окремими ознаками — календар, розпродажі, погодні фактори. Сплеск на свята не приписується бюджету, і внесок реклами оцінюється чесно. Нерозмічений промо-календар відновлюємо за сплесками й узгоджуємо з вами перед навчанням.
Кабінети змінюють структуру кампаній — модель розвалиться?
Прив'язка йде не до кампанії, а до стійких зрізів: канал, тип розміщення, гео, сегмент аудиторії. При злитті або перейменуванні ряд перезбирається за таблицею відповідностей, історія зберігається. Великі перебудови позначаємо як точки розриву й навчаємо модель окремо до та після них.
Як часто перенавчати модель?
Базовий цикл — плановий перерахунок коефіцієнтів і повний перегляд моделі раз на квартал, плюс постійний контроль розбіжності прогнозу з фактом.
Якщо помилка виходить за допустимий коридор кілька періодів поспіль, запускаємо позапланове перенавчання, щоб модель реагувала на зсуви, але не перенавчалася на шумі.
Обговоримо задачу: що потрібно, щоб стартувати
Щоб перша зустріч була по суті, корисно заздалегідь зібрати вхідні дані — не звіт, а те, що вже є в робочих системах. Чим більше контексту на вході, тим точніша оцінка й менше уточнювальних кіл після.
- Постановка задачі: яку мету закриваємо — зростання частки, зниження вартості залучення, перерозподіл між каналами — і за яким показником судите про результат.
- Перелік джерел: рекламні кабінети, веб- та продуктова аналітика, CRM, вивантаження за замовленнями й виручкою; за який період збережена історія.
- Доступи до даних: акаунти з правами лише на читання, доступ до сховища або регулярних вивантажень і контакт людини, яка підтверджує ці права.
- Поточна логіка атрибуції та розподілу бюджету — точка відліку, від якої рахуємо покращення.
- Обмеження: обов'язкові майданчики, брендові кампанії, сезонні піки, рамки для експериментів.
- Ритм ухвалення рішень: раз на тиждень або раз на місяць — від цього залежить частота перерахунку та формат звітності.
Після цього ми повертаємося з оцінкою та планом робіт: склад етапів, хто потрібен з боку замовника, строки до перших перевірюваних результатів. Якщо частини даних немає — скажемо одразу, запропонуємо заміну й покажемо, як це вплине на дизайн перевірки інкрементальності.
