В двух источниках один и тот же клиент имеет разные идентификаторы. Как построить единый ключ сущности для аналитики?
Нужно отделить идентификаторы источников от единого ключа сущности и поддерживать таблицу соответствий между ними. Такая таблица связывает пару источник–идентификатор с каноническим идентификатором клиента, а правила сопоставления должны контролировать неоднозначные совпадения и сохранять историю изменений.
Операционные системы обычно создаются независимо: каждая выбирает собственный формат идентификаторов и границы данных. Поэтому один клиент может иметь разные идентификаторы в CRM, интернет-магазине, программе лояльности и платёжной системе.
Для аналитики этого недостаточно: простое объединение по имени, адресу или электронной почте даёт дубликаты и ошибочные связи. Подход управления мастер-данными появился как способ отделить локальные представления сущности от её устойчивой бизнес-идентичности.
Если объединять записи только по локальному идентификатору, один клиент будет считаться несколькими сущностями. Если сопоставлять записи по неуникальным атрибутам, например по имени и городу, разные люди могут ошибочно объединиться.
Ошибочное разделение и ошибочное слияние имеют разные последствия. Первое дробит выручку и активность клиента, а второе приписывает операции одной сущности другому клиенту, что может повлиять на отчётность, рекомендации, лимиты и требования к конфиденциальности.
Вводится канонический идентификатор клиента, независимый от исходных систем. В аналитической модели факты обычно сохраняют ссылку на этот идентификатор, а исходные идентификаторы помещаются в таблицу соответствий с атрибутами источника, временем действия, статусом сопоставления и уровнем уверенности.
Сопоставление выполняется по уровням. Надёжнее всего использовать подтверждённые связи, например внешний идентификатор, выданный общей системой идентификации. Далее могут применяться нормализованные комбинации атрибутов, а вероятностное сопоставление должно либо проходить порог уверенности, либо направляться на ручную проверку.
Нужно различать минимум три состояния: уверенное совпадение, уверенное отсутствие совпадения и неоднозначный случай. Неоднозначную запись безопаснее временно оставить несопоставленной, чем автоматически объединить её с неправильным клиентом.
Таблица соответствий должна быть версионируемой. Если атрибут клиента изменился или прежнее сопоставление признано ошибочным, новые загрузки используют актуальную связь, а исторические факты сохраняют связь, действовавшую в соответствующий момент, если бизнес-требование требует исторической воспроизводимости.
Ключ не должен зависеть от изменяемого атрибута вроде электронной почты. Электронная почта может быть признаком для сопоставления, но не должна выступать устойчивым каноническим идентификатором: она может измениться, быть переиспользована или принадлежать нескольким пользователям.
Практический компромисс состоит между полнотой объединения и точностью. Агрессивные правила повышают долю сопоставленных записей, но риск ложного слияния обычно дороже, поэтому правила, пороги уверенности и спорные случаи следует контролировать отдельно.
Интернет-магазин и программа лояльности передавали данные о покупателях. В магазине использовался идентификатор аккаунта, а в программе лояльности — номер карты; часть клиентов указывала разные адреса электронной почты.
Рассматривались три варианта. Объединение только по электронной почте было простым, но давало пропуски и риск неверных совпадений. Полное вероятностное сопоставление покрывало больше записей, но требовало контроля качества и объяснимости решений. Отказ от объединения сохранял точность локальных данных, но делал невозможным анализ клиента целиком.
Выбрали канонический идентификатор и таблицу соответствий. Подтверждённые связи применялись автоматически, совпадения по нескольким атрибутам проходили порог уверенности, а спорные записи помещались в очередь проверки. В результате аналитика получила единый срез клиента без принудительного объединения сомнительных записей, а каждую связь можно было объяснить и пересмотреть.
Канонический идентификатор представляет сущность в общем контуре и не должен зависеть от конкретной операционной системы. Идентификатор источника стабилен только в пределах своей системы, поэтому его нельзя напрямую использовать как общий ключ аналитического клиента.
Таблица соответствий позволяет сохранить оба значения: источник–идентификатор для трассировки и канонический ключ для объединения фактов. Это также упрощает подключение нового источника без изменения уже загруженных аналитических данных.
Нельзя молча заменить ключ во всех исторических наборах без фиксации причины и времени изменения. Нужно зарегистрировать операцию разделения сущности, определить затронутые факты и пересчитать зависимые витрины по формализованному правилу.
Если отчётность должна быть воспроизводимой, следует хранить версии соответствий и знать, какое сопоставление использовалось при построении конкретного набора. Иначе повторная загрузка тех же исходных данных может дать другой результат без видимой причины.
Отсутствие совпадения может быть следствием неполных или устаревших атрибутов, задержки поступления справочника либо ошибки нормализации. Поэтому запись часто сначала получает состояние неизвестной или неподтверждённой сущности.
Позднее появившееся подтверждение может связать её с существующим каноническим клиентом. Аналитическая система должна поддерживать такой пересмотр без потери происхождения исходной записи и с понятным правилом обновления агрегатов.