Где хранить правила CRM и кто должен ими управлять

Маркетолог меняет условие повторной покупки, аналитик рассчитывает его по старой формуле, а магазин передаёт собственный признак «активный клиент» — значение, которое отмечает соответствие человека выбранному условию активности. В итоге одна и та же база даёт разные аудитории. Исполнитель видит настройки, но не может уверенно объяснить, почему конкретный человек получил письмо.

Правило CRM — договорённость, по которой данные превращаются в действие. Например: если с подходящей покупки прошло 30 дней и нового заказа нет, предложить пополнение. Несколько связанных правил образуют сценарий: условия входа клиента, выбор сообщения, время отправки и остановку после покупки. Владелец правила определяет его смысл и согласует изменения; он не обязательно сам пишет код.

Такие правила могут выполняться в магазине, аналитическом хранилище, куда собирают данные для расчётов, или CDP — платформе, которая объединяет клиентские данные. Расположение зависит от исходных данных и скорости, с которой нужен ответ. Проблема появляется, когда одно решение независимо реализовано в нескольких местах и эти версии постепенно расходятся.

Разберём, как распределить расчёты и проверки, назначить ответственных и сохранить возможность объяснить каждую отправку.

Разделите факты и решения

Факт описывает произошедшее: заказ оплачен, товар возвращён, клиент изменил адрес. Решение использует эти факты: прекратить напоминание, предложить повторную покупку, включить в сегмент. Исходная система отвечает за достоверность факта, а владелец правила — за способ его применения.

Например, магазин определяет статус заказа. Хранилище рассчитывает число подходящих покупок за 180 дней. CRM использует этот признак при выборе сценария. Если маркетолог меняет окно со 180 на 120 дней, это изменение определения признака, а не исправление заказа.

Полезно отдельно хранить причины решения. «Исключён из кампании» мало помогает при разборе. «Исключён из-за покупки категории X после даты входа» позволяет проверить логику и исходные данные.

Выбирайте место правила по четырём вопросам

Первый вопрос — где находятся необходимые исходные данные. Если расчёт требует всей истории заказов и возвратов, удобнее выполнять его рядом с этой историей, а не дублировать сложную обработку в нескольких каналах.

Второй — как быстро нужен ответ. Оценка LTV — ожидаемой финансовой ценности клиента за заданный период отношений — для квартального планирования и проверка доступного остатка перед предложением имеют разные требования. Для LTV нужно отдельно определить, считаются выручка или вклад после выбранных затрат. Третий — кто меняет правило и как проверяется изменение. Четвёртый — сколько систем должно использовать одинаковый результат.

Если правило общее для сайта, приложения и рассылок, его независимые копии увеличивают риск расхождения. Часто разумнее предоставлять общий результат или сервис проверки. Но такой сервис тоже становится зависимостью: нужно заранее определить, что делать при его недоступности.

Матрица размещения логики

Ниже — редакционный пример для ретейла. Названия конкретных систем могут отличаться; существенны их функции и ответственность.

«Владелец» здесь означает того, кто определяет смысл и принимает изменения. Разработчик может реализовать расчёт, но не должен самостоятельно решать, считать ли отменённый заказ покупкой.

Условный разбор конфликтующего сценария

Клиент купил пылесос утром, а вечером получил предложение со скидкой на такой же товар. Маркетолог видит покупку в профиле и подозревает ошибку платформы.

Разбор показывает: аудитория была рассчитана ночью в хранилище. В CDP покупка появилась вовремя, но сценарий использовал только признак из ночной таблицы и не проверял более свежие заказы. Каждая система выполнила свою настройку; общего правила остановки не было.

Исправление состоит из двух частей. Хранилище продолжает готовить плановую аудиторию. Перед отправкой сценарий исключает клиентов с подходящей покупкой после времени расчёта. В журнале сохраняются версия сегмента, время его подготовки и причина итогового решения.

Если даже оперативные покупки приходят с большой задержкой, последняя проверка не устранит проблему полностью. Тогда нужно исправлять источник или приостанавливать зависимые отправки при нарушении допустимой свежести.

Управляйте порядком проверок

Перед отправкой система последовательно отвечает на несколько вопросов: разрешён ли канал, актуален ли сценарий, не достигнута ли уже цель, доступно ли предложение, не превышена ли частота. Конкретный порядок зависит от архитектуры, но критичный запрет должен исключать отправку независимо от остальных условий.

При параллельных сценариях простого чтения счётчика частоты может не хватить. Две цепочки одновременно увидят «отправок сегодня нет» и обе отправят сообщение. Для общего ограничения требуется механизм, который согласованно резервирует возможность отправки и учитывает отмену или отказ провайдера. Это задача реализации, которую следует явно включить в требования.

Нужно также определить, какой момент считается контактом для лимита: постановка в очередь, передача провайдеру или подтверждённая доставка. У каждого варианта есть последствия. Например, повторные технические попытки не должны автоматически считаться новыми самостоятельными коммуникациями.

Сохраняйте версию правила вместе с результатом

Если правило изменилось, прошлые решения должны оставаться объяснимыми. Храните дату действия версии и описание изменений. Версия позволяет отличить правило до изменения от правила после него и установить, какое из них сработало. Для расчётного признака полезны версия модели и время обновления; для сценария — версия опубликованной конфигурации.

Некоторые платформы предлагают отдельные среды и процедуры переноса изменений. Hightouch, например, документирует environments — отдельные среды с настройками — и deployments, то есть перенос подготовленной версии настроек в нужную среду. Это инструмент управления изменениями, но он не заменяет бизнес-проверку определения сегмента.

Перед публикацией новой версии сравните её со старой на одинаковых тестовых профилях клиентов с заранее известными данными. Найдите тех, чьё решение изменилось, и объясните причину. Массовое неожиданное изменение аудитории — основание разобраться до отправки.

Как договориться о границах ответственности

Для спорного правила подготовьте короткую запись: его смысл, исходные данные, место расчёта, допустимая давность, владелец, потребители и поведение при ошибке. Добавьте два-три примера, включая случай, когда правило не должно сработать.

После этого вопрос «почему не запускается кампания» получает конкретного адресата. CRM-команда отвечает за сценарий, команда источника — за факт покупки, владелец модели — за рассчитанный признак. Общая схема связывает эти части и позволяет изменять процесс без появления нескольких несовместимых версий одного решения.

Источники

Hightouch. Environments and deployments. Техническая документация.