Ретеншн ломается в одном месте: «неправильная» идентичность клиента в loyalty-проекте

Ретеншн ломается в одном месте: «неправильная» идентичность клиента в loyalty-проекте

В 2026 я всё чаще вижу одну и ту же причину провала retention-петель в loyalty-программах. Проблема не в механиках баллов и не в том, что «мы мало сделали коммуникаций». Проблема в идентичности клиента: программа платит преимущества “правильному” человеку на бумаге, но “не того” узнаёт в системах, когда наступает момент начисления, выбора оффера или проверки статуса.

Как это выглядит на практике (и почему я называю это единственным местом, которое ломает всё):
— Пользователь вошёл по одному email в приложении, но совершал покупки как гость/через другой канал.
— CRM считает его двумя разными профилями, а loyalty — третьим (например, по номеру телефона).
— В email/CRM-цепочках вы видите “активность есть”, а в программе — “статус не достигнут”, потому что триггер обновляется с задержкой или по другой ключевой сущности.
— В итоге человек получает не персонализацию, а шум: промокод “на следующую покупку” вместо бонуса за достижение уровня, или наоборот.

В моей практике точка невозврата почти всегда наступает после запуска: в первые недели команда тестирует витрину (личный кабинет, механика), но никто не проверяет сквозной путь “клиент → начисление → статус → оффер → применение выгоды”. Для белых loyalty-проектов это must-have.

Один простой контроль, который я внедряю как редактор и проектный куратор механик:
возьмите 50 реальных покупателей за период, где у вас должна работать ключевая механика (например, прогресс до уровня или накопление активности), и прогоните для каждого:
— какой идентификатор в CDP/CRM стал “истиной”;
— в какой момент и по какому событию начислены баллы;
— какой статус пришёл в сегмент для рассылки;
— применил ли пользователь выгоду без ручных скидочных исключений.

Если хотя бы у 10% людей статус в коммуникации расходится со статусом в начислении (по времени или по ключу), вы не “плохие маркетологи”, вы строите loyalty на ненадёжной модели идентичности. Это бьёт по LTV напрямую: человек чувствует несправедливость (даже если она скрыта от взгляда), и следующая покупка откладывается.

Что делать на уровне дизайна программы (не на уровне “настроек”):
1) Зафиксируйте единый ключ лояльности (что считается главным идентификатором: email, телефон, customer_id) и правила “склеивания” профилей.
2) Разделите витрину и расчёт: статусы для офферов должны приходить из расчётного слоя, а не из обновлённого пользовательского интерфейса.
3) Добавьте “event contracts” для loyalty: любое начисление должно иметь точное событие-основание и таймстемп, чтобы триггеры в lifecycle-цепочках не спорили друг с другом.

В эпоху privacy-first атрибуции и роста Topical Authority (когда люди выбирают бренды по доверию, а не по “последнему клику”) loyalty становится не про частоту писем, а про точность обещания. Механика может быть идеальной на слайде — но если клиент в разных системах “разный”, вы гарантированно кормите пользователя ошибками. А ошибки в лояльности всегда стоят дороже, чем кажется на старте.