Как откатить миграцию CDP без повторных рассылок

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

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

План отката нужно подготовить до переключения. Он должен отвечать, какие сведения вернутся назад, кто станет единственным отправителем и какие последствия уже невозможно отменить.

Определите условия отката заранее

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

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

В Google SRE описан подход blue-green, при котором трафик переключают между двумя подготовленными средами. Для CRM такой принцип полезен как организация переключения, но не обеспечивает автоматического возврата изменившихся клиентских данных и уже отправленных сообщений. Это отдельные задачи.

Сохраняйте то что потребуется вернуть

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

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

Назначьте одного владельца отправки

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

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

Состояние «отправка неизвестна» требует отдельного разбора. Если провайдер принял запрос, а ответ потерялся, повтор в старой системе может создать дубликат. Используйте общий журнал действий и доступные механизмы сверки, а не предположение, что отсутствие локального статуса означает отсутствие отправки.

Условный пример возврата через два часа

В 10:00 новой платформе передали сценарий повторной покупки. К 12:00 обнаружилась ошибка исключений. За два часа 800 клиентов получили сообщения, 30 отписались, 120 совершили подходящие покупки и 15 изменили телефон. Все числа условные; группы могут пересекаться.

Перед возвратом старая система должна получить актуальные запреты, контакты, покупки и историю выполненных отправок. Иначе она повторит часть 800 сообщений, проигнорирует 30 отказов или обратится на прежние номера.

После сверки выбирают только актуальные будущие действия. Старую очередь, подготовленную до 10:00, нельзя просто запустить целиком. Её кандидаты проходят повторную проверку по текущему состоянию.

Учитывайте необратимые изменения

Уже полученное письмо нельзя отменить. Использованный купон, списанные бонусы и показ чужих данных требуют собственного разбора. Возврат платформы не удаляет эти последствия из реального клиентского опыта.

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

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

Сохраните соответствие идентификаторов

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

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

Сопоставление требуется и для кампаний, сообщений, бонусных операций. Один и тот же бизнес-шаг под разными техническими ID легко выглядит как новая задача. Общий ключ действия помогает сохранить фактическую историю при смене исполнителя и не начать цепочку заново.

Отрепетируйте откат

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

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

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

Источники

Google. Canarying Releases. The Site Reliability Workbook. Раздел Blue/Green Deployment. Проверено 22.09.2026.