Как сравнить две CDP при параллельном расчёте

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

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

Сравнивать нужно несколько уровней — от исходных фактов до выбранного сообщения. Для каждого заранее задают допустимые расхождения и способ расследования.

Сначала выровняйте условия сравнения

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

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

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

Проверяйте данные по ключам

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

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

Сравнивайте состав сегмента

Если старая система выбрала множество A, а новая B, найдите общую часть, записи только в A и только в B. Для каждого различия получите объяснение на конкретном клиенте.

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

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

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

Обе платформы выбрали по 10 000 клиентов. Общими оказались 9 600, только в старой — 400, только в новой — 400. Итого объединение содержит 10 400 клиентов, доля совпадения составляет примерно 92,3 процента.

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

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

Сохраните одного владельца отправки

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

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

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

Сравните причины решения

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

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

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

Задайте условия завершения

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

В решении о переключении укажите нерешённые расхождения, их последствия и ответственных. Если расхождение по запретам или принадлежности данных не объяснено, общий высокий процент совпадения не является достаточным основанием запуска.

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

Источники

Amazon Web Services. AWS DMS data validation. AWS Database Migration Service User Guide. Проверка строк источника и назначения и затраты ресурсов. Проверено 22.09.2026.