Одна и та же продуктовая ошибка может всплыть дважды, если команда слишком буквально копирует рынок. Бизнес- и системный аналитик рассказала, как при первой разработке CDP неверно устроила работу сценариев, а во втором проекте заложила механику без этого сбоя.
Проблема была не в редакторе, а в логике изменений
Речь о CDP — платформе, которая собирает клиентские данные и помогает маркетингу сегментировать аудиторию, запускать кампании и управлять коммуникациями. В таких продуктах легко увлечься интерфейсом и списком функций, но реальный риск обычно прячется глубже: в том, как система ведет себя после изменения уже работающих сценариев.
Именно это и стало слабым местом первого проекта. Команда сделала визуальный редактор сценариев с блоками действий и условий, но не до конца продумала, что произойдет, если менять активный сценарий на ходу.
Первая версия ломала клиентский путь
На практике изменение действующего сценария влияло на пользователей, которые уже находились внутри цепочки. Если компания, например, меняла условия программы лояльности, клиент мог внезапно оказаться в новой логике без понятного перехода. Для маркетинга это выглядит как гибкость, для пользователя — как «правила снова переписали по дороге».
Позже команда просто запретила часть правок в активных сценариях. Это снизило риск, но проблему не решило: архитектура осталась хрупкой, а любое полноценное исправление требовало бы заметных затрат времени и ресурсов.
Во втором проекте сценарии разделили по версиям
Во второй разработке аналитик уже исходила не из того, как делают конкуренты, а из того, где именно ломается пользовательский путь. Систему спроектировали так, чтобы старые и новые условия могли сосуществовать без конфликта. Проще говоря, изменения перестали «переписывать прошлое» для тех, кто уже находится внутри сценария.
Такой подход делает поведение платформы предсказуемее: новые правила получают новые пользователи, а текущие завершают путь по прежней логике. Для CDP это не косметическая доработка, а базовое требование, если продукт работает с лояльностью, персональными предложениями и длинными цепочками коммуникаций.
Практический вывод для продуктовых команд
История полезна не только аналитикам, но и всем, кто строит сложные B2B-продукты для маркетинга, CRM и автоматизации. Смотреть на конкурентов полезно, но копировать их поведение без проверки опасно: вместе с удачными паттернами легко унаследовать чужие архитектурные ошибки. Для российских команд вывод простой: тестировать нужно не только интерфейс, но и жизненный цикл сущности после запуска в прод.
Следующий логичный шаг в такой системе — автоматические проверки сценариев и миграций, чтобы каждое изменение не превращалось в ручную проверку на живых пользователях.