Frequency cap на подписку: где push чаще теряет CR, чем экономит бюджет

Frequency cap на подписку: где push чаще теряет CR, чем экономит бюджет

Cap на subscription-кампании не равен cap на продажу. Цель — не «дожать» юзера, а поймать окно, где он ещё реагирует на нативный системный запрос и не режет уведомления на уровне браузера.

Чек-лист перед запуском:
— отдельный cap для first touch и повторного показа;
— разнос по зонам/паблишерам, а не один cap на всё гео;
— исключение юзеров после успешной подписки через postback;
— лимит на in-page отдельно от классического push;
— проверка, не конфликтует ли cap сети с cap трекера.

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

Для теста держу минимум три среза: зона, время между показами, статус подписки. Если источник даёт клики без подписок — сначала смотрю частоту и задержку, потом уже blacklist.

Хороший cap не максимизирует показы. Он убирает повторный шум и оставляет достаточно данных, чтобы whitelist/blacklist был по качеству источника, а не по кривой частоте.