CRM-аналитика
Как выбрать верные данные при расхождениях между системами
Время чтения: 6 мин
Уровень материала: Для экспертов
Содержание
Клиент меняет email в личном кабинете, а ночью старая выгрузка из магазина возвращает прежний адрес. Или человек выбирает любимую торговую точку, а расчёт по покупкам заменяет её другой. Когда несколько систем записывают сведения об одном клиенте, компании нужны понятные правила разрешения таких расхождений.
Профиль клиента — связанная запись с его контактами, предпочтениями и историей. Поле профиля хранит отдельное значение, например email или дату покупки. Источник данных — система либо процесс, из которого это значение получено. Основным источником для поля считают тот, которому по согласованному правилу доверяют в конкретной задаче.
Одну систему не всегда можно объявить главной для всех данных. Адрес доставки относится к заказу, подтверждённый контакт — к человеку, а интерес к категории может быть предположением модели. У этих сведений разный смысл и разные основания доверять им.
Разберём, как выбирать значения по полям, учитывать время изменения и сохранять происхождение данных. Это позволит объяснить, почему система использовала именно этот адрес или признак.
Сначала проверьте что записи относятся к одному человеку
Расхождение значений может быть следствием ошибочного объединения профилей. Если общим телефоном пользуются два человека, выбор «самого нового email» не исправит модель клиента. Он лишь спрячет конфликт.
Идентификатор, или ID, — код, по которому система различает записи. При объединении данных нужно понять, какие коды из разных источников относятся к одному человеку. Разделите два вопроса. Первый: на каком основании записи связаны? Второй: какое значение использовать в определённой задаче? В Salesforce правила сопоставления и правила согласования значений также являются разными частями identity resolution — процесса сопоставления и объединения записей об одном клиенте. [1]
Для сомнительной связи безопаснее сохранить отдельные записи и отправить случай на проверку, чем автоматически объединить историю. Критерий зависит от продукта и процедуры идентификации, но должен быть определён до массовой обработки.
Почему правило последнего обновления может ошибаться
В 10:00 клиент подтвердил новый email в личном кабинете. В 11:00 старая выгрузка из кассовой системы доставила прошлый адрес. Если ориентироваться на время получения записи, старое значение победит.
Поэтому нужны как минимум время исходного изменения и время поступления в систему. Для некоторых полей потребуется версия записи, статус подтверждения или приоритет источника. Отдельно определите поведение при одинаковых временных метках и несогласованных часах.
Ещё одна проблема — техническое обновление без изменения смысла. Ночной импорт может заново записывать все поля, делая старые значения формально «новыми». Сравнение по дате изменения работает только тогда, когда участники обмена одинаково понимают эту дату.
Матрица правил для профиля
Ниже — условный пример CRM Lab. Он показывает логику согласования, а не обязательную модель для всех компаний.
| Поле | Основной источник | Правило выбора | Что сохранять дополнительно |
|---|---|---|---|
| Контактный email | Процесс подтверждения контакта | Последний допустимо подтверждённый адрес | Время и основание подтверждения |
| Адрес доставки | Конкретный заказ | Значение для этого заказа | ID заказа и получатель |
| Любимый магазин | Явный выбор клиента | Выбор важнее расчётного предположения | Источник и дата выбора |
| Интерес к категории | Модель поведения | Результат с ограниченным сроком актуальности | Версия модели и время расчёта |
| Дата последней покупки | Реестр подходящих заказов | По согласованным статусам с учётом исправлений | ID исходной операции |
| Разрешение на канал | Принятый процесс разрешений | Хронология допустимых действий по нужной области | Канал, бренд, цель и доказательство |
Не храните единственное поле «адрес клиента», если бизнесу одновременно нужны адрес проживания, доставки и последнего заказа. Часть конфликтов исчезает после правильного разделения сущностей.
Как учитывать приоритет источника
Приоритет нужен, когда источники имеют разную надёжность для конкретного поля. Например, явный выбор языка в профиле может быть предпочтительнее предположения по браузеру. Но приоритет нельзя назначать одной системе навсегда для любых данных.
Salesforce документирует правила согласования значений, включая приоритет источника. [2] Практическое применение требует определить область: какое поле, для какой задачи и при каких условиях источник считается предпочтительным.
Также решите, что означает пустое значение. Оно может указывать на отсутствие данных, намеренное удаление или техническую ошибку. Правило «игнорировать пустое» полезно не всегда: оно способно вернуть поле, которое человек попросил убрать. Для удаления нужен явный сигнал и согласованный процесс его распространения.
Разрешения требуют отдельной модели
Не сводите всю историю к одному булеву полю «подписан», которое допускает только два значения: «да» и «нет». Состояние может относиться к определённому каналу, бренду или виду сообщений. Старый импорт положительного значения не должен отменять более поздний применимый отказ.
При этом принцип «любой отказ навсегда сильнее любых будущих действий» тоже слишком груб. Клиент может позднее выполнить корректную процедуру повторного разрешения. Система должна учитывать допустимые действия в правильной последовательности и хранить основание текущего состояния.
Маркетинговый сегмент не должен становиться владельцем разрешения. Если таблица аудитории обновляется раз в сутки, она пригодна для отбора по интересу, но не для отмены оперативного запрета из другого процесса.
Избегайте бесконечной двусторонней перезаписи
Предположим, CRM записывает своё значение в магазин, а магазин каждую ночь возвращает его обратно. При различии правил преобразования поле может колебаться между двумя версиями, создавая лишние события и расходы.
Для каждого поля определите разрешённые направления изменения. Храните источник последнего смыслового изменения и не считайте техническую синхронизацию новым действием клиента. Если несколько систем действительно могут редактировать поле, потребуется общее правило разрешения конфликта и журнал.
Не запускайте маркетинговую цепочку на любое техническое обновление профиля. Событие «клиент изменил предпочтение» должно отличаться от повторной записи того же значения интеграцией.
Условный разбор конфликта
У клиента в программе лояльности выбран магазин A, а модель по трём последним покупкам предполагает магазин B. Вместо перезаписи «любимого магазина» храните два признака: явный выбор A и расчётную предпочтительную точку B.
Для сообщения о персональных условиях используется заявленный выбор. Для аналитики доступности можно исследовать поведение по B. Если бизнес хочет предложить изменить предпочтение, это отдельный сценарий с понятным вопросом клиенту.
Такое разделение сохраняет полезную информацию и предотвращает ситуацию, когда алгоритм незаметно «исправляет» ответ человека. Подход применим и к интересам, языку, размеру одежды — с учётом смысла каждого поля.
Как проверить правила до запуска
Подготовьте последовательности изменений, а не только статические профили: новый подтверждённый контакт и поздний старый импорт; намеренное удаление; два источника с одинаковым временем; отказ и допустимое повторное разрешение; ошибочно связанная запись.
Для каждого случая заранее укажите итоговое значение, причину выбора и данные, которые должны остаться в истории. После прогона проверьте и профиль, и фактическое решение сценария. Верное отображение поля не гарантирует, что уже подготовленная отправка использует именно его.
Результат работы — матрица по полям и воспроизводимые примеры. Она позволяет обсуждать расхождения на языке правил и доказательств, сохраняя информацию, необходимую для исправления ошибок.
Источники
[1] Salesforce. Learn to Create and Manage Identity Resolution Rulesets. Trailhead.
[2] Salesforce. Identity Resolution Reconciliation Rules. Salesforce Help.