Реактивация базы через ретаргет по разным «типам затухания»: схема, метрики и настройки

Реактивация базы через ретаргет по разным «типам затухания»: схема, метрики и настройки

Если реактивация в вашем аккаунте “не едет”, причина почти всегда одна: вы одинаково таргетите людей с разной историей контактов и разной вероятностью покупки. В 2026 выигрывает сегментация по затуханию (recency-лестница) + инкрементальность (доказываем, что возвращаем выручку, а не просто пересобираем аудиторию).

Ниже — практическая инструкция, которую можно внедрить на этой неделе.

1) Разделите базу не по демо, а по поведению затухания
Выгрузите из CRM/аналитики аудитории за последние 6–12 месяцев и постройте 4–6 сегментов по двум осям:
— Recency: сколько времени прошло с последнего значимого события (покупка/лид/заявка/посещение checkout)
— Важность события: “покупатель” vs “почти покупатель” (например, начал оформление, но не дошёл)

Пример структуры (адаптируйте под ваш цикл):
— P0: купил за 0–30 дней (контроль/апсейл, а не реактивация)
— R1: купил 31–90 дней назад
— R2: купил 91–180 дней назад
— L1: был на этапе покупки 31–180 дней назад, покупки не было
— L2: оставил заявку/контакт 31–180 дней назад, сделки не случилось
— Z: “холодные” контакты 180–365 дней назад (часто нужен другой оффер и формат)

2) Под каждый сегмент сделайте отдельные рекламные группы и логику креатива
Правило юнит-экономики: **в реактивации прибыль определяется не CTR, а долей до покупки и маржинальным валом**. Поэтому не делайте один креатив “для всех”.

Сделайте минимум 2–3 сообщения:
— Для R1/R2 (бывшие покупатели): удерживающий оффер (напоминание + выгода) и соц.доказательство (“заказывали раньше”)
— Для L1 (почти покупатели): сообщение “дожимающее” (помощь, FAQ, закрытие возражения, ограничение по шагам)
— Для L2/Z (давно молчали): реактивация через ценность (гайд, чек-лист, консультация/демо для B2B) без обещаний скидки “в лоб”

Если вы в e-com и чек снижается, закладывайте, что возражение “дорого” сильнее: лучше продаётся ценность (срок службы, комплектация, экономия по владению), а скидка — точечно.

3) Настройте частоту и окно экспозиции, чтобы не сжечь маржу
Для реактивации частота — главный скрытый убийца ROMI (окупаемости расходов) из-за повторных показов тем, кто и так “не купит сейчас”.

Рекомендованный порядок:
— В каждом сегменте задайте окно ретаргета по времени после последнего события (например, показывать R2 только в течение 14–21 дня, затем обновлять состав)
— Ограничьте частоту на пользователя (cap) и следите за снижением CTR/ростом CPM
— Не используйте длинный всегда-активный ретаргет “навсегда”: он съедает бюджет в Zero-click эпоху, где часть контактов не создаёт нового намерения

4) Сделайте контроль через инкрементальность: lift вместо “оптимизации по кликам”
Вы не сможете полагаться только на last-click (последний клик). Минимум, что нужно на неделе:
— Разделите аудиторию в тесте на две части: тест (таргет по сегментам) и контроль (похожие параметры, но без показов именно вашей реактивации)
— Оцените не только ROAS, а инкрементальную выручку: (выручка теста − выручка контроля) / расходы теста
— Если контроль не получается технически: делайте раздельный анализ “до/после” с группой сравнения (например, похожие пользователи по поведенческим признакам, но без участия в ретаргете)

5) Отдельно настройте атрибуцию и источники конверсий
В 2026 важен серверный учёт и корректная дедупликация:
— Передавайте события в строгой схеме: view → add_to_cart → begin_checkout → purchase (или lead → qualified)
— Убедитесь, что одно и то же событие не дублируется разными источниками
— Подключите offsite-конверсии и call-to-action события (заявка/форма/созвон) к одному идентификатору пользователя/сессии

6) Метрики, по которым вы решаете “масштабировать/убрать”
Для каждого сегмента заведите KPI-таблицу:
— Маржинальная выручка / расходы (не просто ROAS)
— Доля конверсий до покупки/лида и скорость (time-to-convert)
— Доля повторных покупок/повторных заявок (чтобы понять, это реактивация или “переотправка”)
— Частота и её влияние на вал

— @RetentionPaid

Есть схожая тема в @ProductAnalyticsMK, рекомендуем