CRM-аналитика
Как изменить событие и сохранить работающие сценарии
Время чтения: 6 мин
Уровень материала: Для экспертов
Содержание
Разработчик переименовал purchase в order_paid, чтобы название стало понятнее. На сайте всё работает, ошибок обмена нет, а CRM перестала запускать послепокупочную цепочку. Для получателя данных имя события является частью интерфейса: смена названия может оказаться таким же изменением, как удаление поля.
Схема события описывает его поля, типы и обязательность. Контракт данных добавляет смысл: когда событие возникает, что означает сумма, как определяется клиент и какие изменения допустимы. Совместимость означает, что отправитель и получатель продолжают правильно понимать друг друга после обновления.
Безопасное изменение начинается с перечня потребителей и плана перехода. Одной договорённости между разработчиком магазина и администратором CDP обычно недостаточно.
Проверьте меняется ли только название
Слова purchase и order_paid могут обозначать разные факты. Если раньше событие создавалось при оформлении заказа, а теперь после оплаты, это изменение поведения, даже если набор полей тот же.
Сначала сравните смысл старой и новой версии: момент возникновения, единицу суммы, состав позиций, учёт скидок, идентификаторы и время. Отдельно решите, что делать с историческими данными. Новое определение нельзя молча распространить на записи, собранные по старому.
Документация Confluent различает совместимость в разных направлениях: новый потребитель читает старые данные или старый потребитель читает новые. Практический вывод для CRM — проверять обе стороны перехода и отдельно историю, которую потребуется повторно обрабатывать.
Найдите всех потребителей события
Потребитель — система или правило, использующее событие. Это не только триггер. На него могут опираться сегмент, исключение, отчёт, начисление бонусов, выгрузка рекламы и мониторинг.
Составьте реестр зависимостей с владельцами. Для каждой укажите, что произойдёт, если событие перестанет приходить или сменит смысл. Особое внимание — правилам остановки: поломка запуска заметна по нулю сообщений, а поломка исключения может увеличить отправки и выглядеть как успешная работа.
| Зависимость | Проверка до перехода | Подтверждение после |
|---|---|---|
| Послепокупочная цепочка | Новый формат запускает нужную ветку | Есть ожидаемые входы без дублей |
| Остановка корзины | Обе версии прекращают нужное напоминание | Нет отправки после доступной покупки |
| Отчёт | Суммы и статусы сопоставимы | Сходятся ID и итоговые значения |
| Бонусы | Повтор не создаёт начисление | Одна операция на одно основание |
| Мониторинг | Следит за новой версией | Сигнал не исчез после переименования |
Выберите способ перехода
Если смысл не меняется, можно использовать адаптер — промежуточное преобразование нового формата в прежний для ещё не обновлённых потребителей. Тогда переход выполняют постепенно и контролируют оставшиеся зависимости.
Если смысл изменился, полезнее явная новая версия с отдельной документацией. Например, v2 добавляет обязательное указание валюты или меняет событие создания заказа на подтверждение оплаты. Номер версии сам по себе не обеспечивает совместимость: проверяется фактический формат и поведение.
Одновременная отправка двух версий допустима только при защите от двойного действия. Нельзя включить обе в рабочую цепочку и надеяться, что платформа догадается об общей покупке. Лучше направить новую версию в теневой расчёт, где решения записываются, но сообщения не отправляются.
Согласуйте ключ бизнес-действия
У версий одного факта могут быть разные event ID. Поэтому устранение дублей по ID транспортного события не всегда защитит от двух начислений или двух писем.
Для действия нужен устойчивый ключ, соответствующий его смыслу: например, ID заказа и тип подтверждённого перехода. Если действие может повторяться законно, в ключ включают конкретную операцию или позицию. Не используйте один order ID для всех уведомлений заказа: он ошибочно заблокирует разные полезные сообщения.
Идемпотентность означает, что повтор одной и той же операции не создаёт дополнительного результата. Длительность хранения ключа должна покрывать ожидаемые повторы и возможное восстановление истории.
Условный план смены события
Магазин переходит с purchase на order_paid. Выясняется, что старое событие запускалось при создании заказа, поэтому простое переименование отменяют. Команда сохраняет событие оформления и вводит отдельный факт оплаты.
Цепочку помощи с неоплаченным заказом останавливает подтверждение оплаты. Приветствие после первого оформленного заказа остаётся на прежнем основании, если это соответствует задаче. Финансовый отчёт получает новую метрику оплаченных заказов с понятной датой начала сопоставимого ряда.
До включения сообщений новая логика работает без отправки на тестовых данных и затем в теневом режиме на разрешённом потоке. Команда сравнивает конкретные решения, включая частичную оплату, отмену и позднее событие.
Проверяйте смысл даже при успешной проверке формата
Схема может подтвердить, что поле amount является числом, но не заметить переход с рублей на копейки. Аналогично валидная дата не объясняет, стала ли она временем создания, оплаты или загрузки заказа.
Добавьте примеры с ожидаемым результатом: один заказ, частичная оплата, возврат, нулевая сумма и неизвестная валюта. Для каждой версии укажите, что должен рассчитать получатель. Такие проверки защищают смысл интерфейса, который не выражается только типами полей.
Проверьте старые версии мобильного приложения: они могут передавать прежнее событие ещё долго после обновления сервера. Период совместной поддержки выбирают по реальному использованию и политике поддержки приложения. Отключение старой версии по календарной дате без такой проверки способно незаметно исключить часть клиентов из CRM-процессов.
Назначьте условия завершения и отката
Старую версию отключают после подтверждения всех владельцев, проверки ожидаемой задержки старых клиентов приложения и истечения согласованного периода повторной передачи. Фраза «неделю никто не жаловался» не заменяет реестр оставшихся потребителей.
Откат должен восстанавливать не только прежнее имя события, но и правила обработки уже полученных новых записей. Если часть сообщений отправлена, их журнал сохраняется, чтобы возвращённая версия не повторила действие.
В задаче на изменение остаются две версии контракта, список зависимостей, результаты тестов и ответственный за переключение. Тогда небольшое улучшение названия действительно улучшает систему, а не создаёт скрытый разрыв в CRM-процессах.
Источники
Confluent. Schema Evolution and Compatibility for Schema Registry on Confluent Platform. Техническая документация. Разделы Schema evolution и Compatibility types. Проверено 22.09.2026.