Инкрементальность push-сообщений: почему «мы повысили конверсию» часто ничего не значит

Инкрементальность push-сообщений: почему «мы повысили конверсию» часто ничего не значит

В 2026 я всё чаще вижу одну и ту же картину в командах: после запуска серии web/mobile push-лифтят метрики — CTR, клики, иногда даже выручку в приписке — и на этом ставят точку. Но как редактор и как человек, который руками собирает эксперименты в мобильном росте, я убеждаюсь: без инкрементальности (то есть измерения добавочного эффекта сверх естественного поведения) вы можете оптимизировать не рост, а «совпадение с рынком».

Почему это происходит? Последовательность обычно такая:
— включили кампанию
— алгоритмы (или пользователи) начали вести себя иначе
— атрибуция показала lift
— вывод: «push работает»

Проблема в том, что lift может быть вызван факторами, которые не контролируются: сезонность, обновление сайта, рассылки параллельно, изменения в приложении, даже изменения в рекламных активностях. В privacy-first мире last-click всё хуже, а server-side и модели MMM/инкрементации не всегда дотянуты до уровня дисциплины «делаем выводы только по добавочному эффекту».

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

Практическое наблюдение из проектов (без привязки к бренду): когда мы верифицировали эффект push по holdout-группам (часть аудитории не получала сообщение) и сравнили с контрольной когортой, примерно в половине случаев «рост по приписке» не подтверждался. Где-то метрика была завышена из-за пересечений с другими касаниями, где-то реальный эффект съедала автоматическая доставка (например, когда пользователи всё равно открывали сценарий в тот же день). В итоге решения по креативам и частоте пришлось пересобрать, потому что оптимизация шла по сигналу, который не отражал прирост.

Как я предлагаю проверять инкрементальность для web push / mobile push / in-app, чтобы не гадать:

1) Делайте holdout, а не «оценку по факту»
— хотя бы 5–10% аудитории исключайте из отправки на равный период
— сравнивайте не CTR, а поведение до ключевого события: заказ/оплата/целевое действие, и лучше — в окне, которое соответствует вашему циклу (например, 24–72 часа)

2) Разводите по времени и канальным пересечениям
— если параллельно идёт email и in-app в те же часы, вы получите «взаимное влияние»
— минимальная дисциплина: синхронизация планов или отдельные тесты по очереди

3) Оценивайте частоту как риск, а не как переменную оптимизации «до упора»
— push легко монетизируется в краткосроке, но часто даёт побочный эффект: рост отписок/глушения/ухудшение реакции на следующее сообщение
— контрольная группа показывает, как меняется общий спрос, а не только отклик на конкретную рассылку

4) Не путайте атрибуцию с причиной
— если вы видите рост выручки в приписке, это ещё не доказательство, что push её создал
— в 2026 я бы считал обязательным минимум: сравнение с контрольной когортизацией плюс проверка «до/после» на стабильном периоде

Если хочется сделать это быстро и без перегруза аналитикой, начните с одного: выберите один сегмент и один use-case (например, реактивация после сессии без покупки или напоминание о брошенной корзине) и проведите A/B с контрольной группой. Дальше вы сможете уже спорить предметно: какие триггеры реально добавляют инкремент, а какие лишь подсвечивают пользователей, которые и так бы купили.

Моё главное допущение для команды: **если мы не меряем добавочный эффект, мы не имеем права утверждать, что push — это performance.** Мы можем говорить только, что канал «доставляет сообщение» и «сдвигает поведение по приписке». А это слишком слабое основание для решений в CRM/lifecycle, где цена ошибки — потеря LTV через утомление и отписки.

— @PushCraftRu