Итерационный план для обновления атрибуции в performance: с server-side, incrementality и MMM на одной карте

Итерационный план для обновления атрибуции в performance: с server-side, incrementality и MMM на одной карте

После пары недель «было лучше — стало хуже» большинство команд упираются не в креатив и не в ставки, а в то, что платформа и ваши измерения больше не сходятся. На этой неделе цель простая: привести в порядок связку “что считаем → чем подтверждаем → как оптимизируем” без попытки сделать идеальную модель за один спринт.

Шаги (делайте по порядку, это можно закрыть за 3–5 рабочих дней):

1) Сведите текущие источники истины в один короткий список
— Перечислите 5–7 основных событий (например: просмотр страницы, добавление в корзину, submit формы, лид, покупка/оплата).
— Укажите, где они сейчас измеряются: платформа (pixel/конверсии), сервер (server-side), CRM (факт MQL/SQL/оплата), продуктовая аналитика.
— Отдельно отметьте “критические” события для оптимизации и “проверочные” (которые вам нужны для разницы в моделях, но не обязательно для автостратегий).

2) Запустите “сверку” по инкрементальным правилам на 1–2 кампаниях
Задача — не угадать вклад, а увидеть, есть ли перекос last-click (последнего клика) или post-view (после просмотра).
— Выберите 1 брендовый сегмент и 1 non-brand (не-брендовый) — или 2 аудитории с разной историей.
— На уровне платформы включите ограничение на атрибуцию/окна конверсий так, чтобы можно было сравнивать (например, короткое vs длинное окно; или first-touch vs last-touch, если доступно).
— Сравните: что меняется в объёме конверсий при одинаковом бюджете и креативной ротации. Если разница “скачет” больше, чем ожидаемая сезонность, значит измерение нестабильно, а не спрос.

3) Пересоберите server-side отправку под “хорошие поля”, а не под “как раньше”
В privacy-first эпохе серверные события легко портятся из‑за неполных параметров.
— Зафиксируйте обязательные поля для каждого события: идентификатор пользователя (или согласованный surrogate), timestamp, тип события, value (если релевантно), источник кампании (utm/параметры), consent status (если у вас это заведено).
— Проверьте соответствие: одинаковая ли схема названий событий в сервере и в платформе (часто конверсии “переименовываются” — и платформа оптимизирует не то).
— Введите правило: если событие отправлено повторно (replay), оно не должно “дублировать” оптимизируемую конверсию.

4) Обновите цели оптимизации: разделите “что оптимизирует” и “что измеряет ценность”
У большинства команд сейчас проблема: платформа оптимизирует конверсии, которые не равны выручке (особенно в B2B и e-com).
— Для e-com: оптимизация первой покупки почти всегда хуже по LTV после просадки среднего чека; переключайте приоритет на событие, коррелирующее с повтором/оплатой более высокого качества (например, оплату после подтверждения, “доставка/успешная оплата”, если бизнес-логика позволяет).
— Для B2B: перестаньте давать “форму” как единственный якорь. Создайте 2 уровня: событие для обучения (быстрое и стабильное) и событие для учёта (MQL/SQL/выручка в CRM). Платформе отдавайте то, что реально стабильно сигналит.

5) Соберите мини-MMM-рамку на 2 недели, даже если MMM “потом”
MMM не нужно делать “идеальным”. Нужно выстроить контрольный коридор.
— Возьмите 6–10 недель данных: затраты по каналам и наблюдаемую выручку (или её прокси, если вы ещё на пути).
— Сделайте быстрый контроль: какой вклад “по деньгам” даёт каждый канал при сглаживании. Это поможет выявить разрыв между платформенными конверсиями и реальной выручкой.
— Зафиксируйте вывод в одном документе: “канал Х рисует конверсии, но не даёт ожидаемой выручки” или наоборот.

6) Введите еженедельный ритуал “3 цифры + 1 решение”
Каждую неделю (начиная с этой) обновляйте только три метрики и одно решение:
— Метрика 1: расхождение platform конверсии vs CRM (или оплата) для ключевого события.
— Метрика 2: стабильность server-side отправок (доля событий без обязательных полей / доля дублей).
— Метрика 3: инкрементальный сигнал (хотя бы через сравнение кампаний/аудиторий и окна атрибуции).
— Решение: что меняем на следующей неделе — событие оптимизации, правила атрибуции, состав аудиторий или порядок распред
…