Ключевые выводы
- Entity resolution — процесс автоматической склейки разрозненных карточек одного клиента в единый профиль. Без него сегментация и триггеры работают с мусорными данными
- Два подхода: детерминистическое сопоставление (по точному ключу — 100% точность) и вероятностное (по нечётким совпадениям — 85-92% точность)
- Комбинация обоих подходов покрывает 90-95% клиентской базы — оставшиеся 5-10% требуют ручной верификации
- В on-prem CDP правила склейки настраиваются под конкретный бизнес — в SaaS-решениях они часто зашиты в платформу
Один клиент — пять карточек в пяти системах. Знакомая ситуация для любого enterprise с базой 100+ тысяч клиентов. CRM хранит «Иванова И.И.», email-платформа знает «ivan@company.ru», call-центр работает с номером +7-999-123-45-67, сайт видит cookie, а приложение — device ID. Пять фрагментов одного человека, которые никогда не встретятся без entity resolution.
Эта статья — для CTO и архитекторов, которые оценивают CDP-платформы и хотят понять, как именно работает склейка профилей. Не на уровне маркетинговых слайдов, а на уровне архитектуры.
Почему entity resolution — фундамент, а не «фича»
В CDP-платформе данные проходят цепочку: сбор → склейка → сегментация → триггеры → коммуникации. Entity resolution стоит вторым звеном. Если оно сломано — всё, что идёт после, работает с грязными данными.
Конкретные последствия некачественной склейки:
- Сегментация врёт. Клиент, разнесённый на 3 карточки, попадает в разные сегменты. Одна карточка — «активный», другая — «спящий», третья — «новый»
- Триггеры дублируют. Три карточки — три приветственных письма одному человеку
- Аналитика искажена. LTV одного клиента размазывается по трём профилям. Средний чек занижен, количество клиентов завышено
- Compliance под угрозой. Клиент отозвал consent в одной карточке — но две других продолжают получать рассылки
Поэтому entity resolution — не «приятная возможность», а архитектурный фундамент. Без него CDP превращается в дорогую базу данных с теми же проблемами, что и до внедрения.
Два подхода к склейке: детерминистический и вероятностный
Все CDP-платформы используют один из двух подходов или их комбинацию. Разница — в точности, покрытии и сложности настройки.
Детерминистическое сопоставление
Принцип: если два профиля имеют одинаковый уникальный ключ (телефон, email, номер карты лояльности) — это один человек.
| Параметр | Значение |
|---|---|
| Точность | 100% (при валидных данных) |
| Покрытие | 60-75% клиентской базы |
| Требования к данным | Общий идентификатор в обоих источниках |
| Скорость | Высокая (простое сравнение ключей) |
| Ложные объединения | Минимальные |
Детерминистический подход работает надёжно, когда у клиента есть хотя бы один общий идентификатор в нескольких системах. Однако покрытие ограничено: 25-40% клиентов не имеют общего ключа между источниками. Например, cookie на сайте и номер карты лояльности в офлайне никак не связаны напрямую.
Вероятностное сопоставление
Принцип: если два профиля похожи по набору атрибутов (ФИО + дата рождения + город) с вероятностью выше порога — это, скорее всего, один человек.
| Параметр | Значение |
|---|---|
| Точность | 85-92% (зависит от порога) |
| Покрытие | 85-95% клиентской базы |
| Требования к данным | 3+ атрибутов для сравнения |
| Скорость | Средняя (нечёткое сравнение строк) |
| Ложные объединения | 2-5% (требуют мониторинга) |
Вероятностный подход закрывает оставшиеся 25-40%, но вносит риск ложных объединений. Два «Иванова Ивана» из Москвы с похожими датами рождения — это один человек или два? Порог определяет баланс между покрытием и точностью.
Комбинированный подход — стандарт enterprise CDP
На практике зрелые CDP-платформы используют двухэтапную схему:
- Первый проход — детерминистический. Склейка по точным ключам (email, телефон, ID карты). Результат: 60-75% базы объединено с нулевым процентом ошибок
- Второй проход — вероятностный. Для оставшихся 25-40% — нечёткое сопоставление по ФИО + дата рождения + адрес. Пары с вероятностью ниже порога отправляются на ручную верификацию
Итоговое покрытие: 90-95%. Оставшиеся 5-10% — это профили без достаточных данных для уверенной склейки. Они остаются отдельными записями до появления нового идентификатора.
Как entity resolution работает под капотом
Для архитекторов и технических директоров — схема обработки на уровне компонентов:
- Ingestion. Данные поступают из источников (CRM, сайт, приложение, call-центр) через API, webhook или batch-импорт
- Нормализация. Телефон приводится к формату +7XXXXXXXXXX, email — к lowercase, ФИО — к единому регистру. Без нормализации «+7 (999) 123-45-67» и «89991234567» — это «разные» клиенты
- Matching. Детерминистический проход по ключам, затем вероятностный по атрибутам. Результат — граф связей между профилями
- Merge. Создание «золотого» профиля: мастер-запись с лучшими данными из всех источников. Приоритет определяется правилами (CRM-данные приоритетнее cookie-данных)
- Linking. Исходные карточки сохраняются как linked identities. Видно, откуда пришли данные и когда
Весь процесс занимает 50-200 миллисекунд на профиль при детерминистическом подходе и 500-2000 миллисекунд при вероятностном. Для batch-обработки базы в 500 тысяч профилей — это 2-4 часа первичной склейки и секунды на каждое новое событие.
Подводные камни: когда entity resolution ломается
Entity resolution — не «настроил и забыл». Есть сценарии, в которых даже хорошо настроенная система даёт сбои:
Ложные объединения (false positives)
Два разных «Иванова Ивана Ивановича» из Москвы с похожими датами рождения склеиваются в один профиль. Результат: один из них получает чужие рассылки, второй теряет историю покупок. В базе 500+ тысяч клиентов таких случаев может быть 2-5 тысяч при агрессивных порогах.
Решение: консервативные пороги для вероятностного сопоставления + очередь на ручную верификацию для пограничных случаев.
Изменение идентификаторов
Клиент сменил номер телефона или email. Старые события привязаны к одному ключу, новые — к другому. Без обработки этого сценария профиль «разваливается» на два.
Решение: история идентификаторов с привязкой к временным меткам. Новый идентификатор не заменяет старый, а добавляется к графу связей.
Общие идентификаторы
Семья использует один email для заказов. Корпоративный телефон привязан к нескольким сотрудникам. В этих случаях детерминистическая склейка по ключу даёт ложные объединения.
Решение: «горячие» ключи — идентификаторы, привязанные к 10+ профилям, исключаются из автоматической склейки и обрабатываются отдельно.
Entity resolution в on-prem CDP: контроль над правилами
В SaaS-CDP правила склейки часто зашиты в платформу. Вы видите результат — «профиль объединён» — но не можете настроить порог, приоритет источников или обработку edge cases.
On-prem CDP даёт полный контроль:
- Конфигурация ключей. Какие поля считать идентификаторами, в каком приоритете
- Настройка порогов. Баланс точность/покрытие под конкретную базу
- Правила слияния. Какой источник приоритетнее при конфликте данных (CRM vs сайт)
- Мониторинг качества. Dashboard с метриками: % склеенных профилей, очередь верификации, ложные объединения
- Аудит-лог. Кто изменил правило, когда, что было до и после — для compliance
Подробнее о преимуществах on-prem подхода — в материале On-prem CDP платформа для enterprise.
Итого
Entity resolution — это не «фича» в списке возможностей CDP. Это архитектурный фундамент, от качества которого зависит вся цепочка: сегментация, триггеры, аналитика, compliance. Без надёжной склейки профилей CDP превращается в ещё одну базу данных с дубликатами.
Комбинация детерминистического и вероятностного подходов покрывает 90-95% клиентской базы. Оставшиеся 5-10% — зона ручной верификации и тонкой настройки. В on-prem CDP эти правила полностью под вашим контролем.
Хотите увидеть, как entity resolution работает на реальных данных вашей компании? Запишитесь на архитектурную консультацию — покажем процесс на пилотной выборке из вашей базы.
FAQ о entity resolution
Что такое entity resolution простыми словами?
Это процесс, при котором CDP определяет, что Иванов И.И. из CRM, ivan@mail.ru из email-рассылки и +7-999-123-45-67 из call-центра — один и тот же человек. На выходе — один профиль вместо трёх карточек. Автоматически, без ручной работы менеджера.
Какую точность даёт entity resolution в CDP?
Детерминистическое сопоставление (по точному ключу — телефон, email) даёт 100% точность. Вероятностное (по нечётким совпадениям) — 85-92% при правильной настройке. Комбинация обоих подходов покрывает 90-95% клиентской базы.
Можно ли настроить entity resolution без data science команды?
Детерминистические правила — да, это конфигурация: какие поля считать ключевыми, какие приоритетнее. Вероятностное сопоставление требует настройки порогов и тестирования на реальных данных — здесь помогает команда внедрения. В on-prem CDP обычно предлагают готовые пресеты для типовых сценариев.
Что происходит с дубликатами после entity resolution?
CDP создаёт «золотой» профиль — мастер-запись с лучшими данными из всех источников. Исходные карточки сохраняются как linked identities: видно, откуда пришли данные. При появлении нового события (покупка, звонок) CDP автоматически привязывает его к мастер-профилю.