15.10.2026
8 минут

Identity Resolution в CDP: как объединить данные о клиенте без потери точности

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

Связать эти следы в один профиль помогает процесс Identity Resolution. В статье разберём, какими способами CDP может склеивать идентификаторы и как проверить, что объединение работает правильно.

Зарегистрируйтесь
И попробуйте Sendsay бесплатно

Что такое Identity Resolution

Identity Resolution (в переводе с английского — «сопоставление идентификаторов») — это процесс, который связывает разрозненные идентификаторы одного человека в единый профиль. Проводить Identity Resolution можно, например, внутри платформы клиентских данных (Customer Data Platform, CDP).

Распознать человека можно по идентификаторам — цифровым следам, которые он оставляет в интернете. Они делятся на две группы:

  • Сильные (hard ID) — уникальные данные, которые однозначно указывают на человека. Это могут быть email, номер телефона, номер карты лояльности, логин на сайте. Например, если электронный адрес совпадает в двух источниках, почти наверняка он относится к одному человеку.
  • Слабые (soft ID) — косвенные признаки, по которым можно определить пользователя. Сюда относятся cookie, идентификатор браузера или устройства, IP-адрес. Они показывают обезличенную информацию, которую тем не менее можно использовать в маркетинговых целях.
Сложность в том, что у одного человека таких идентификаторов много, и они разные. 

Он может заходить на сайт с разных устройств, оставлять разные контакты в разных каналах — и поэтому в каждой системе будет записан по-своему. Например, в CRM есть его номер телефона, а в платформе для отправки рассылок — только email. Задача бизнеса состоит в том, чтобы связать эти цифровые следы и определить, что они принадлежат одному человеку, а не двум разным. Это поможет в дальнейшем выстроить коммуникацию с клиентом, основанную на его реальных действиях и интересах, которые связаны между собой.

Как связываются идентификаторы

Разберём несколько базовых способов.

Детерминированный матчинг — это сопоставление hard ID. Система определяет, что данные относятся к одному человеку, если совпадают надёжные идентификаторы. Например, если пользователь оставил номер телефона на сайте и потом сам с него позвонил в компанию, CDP поймёт, что это один и тот же человек, а не два разных.

У этого способа высокая точность, но он сработает только там, где человек оставил сильный идентификатор — анонимного посетителя без логина детерминированный матчинг не определит.

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

Плюс этого метода в том, что можно работать с анонимной информацией, но высок риск ошибки. Например, два человека, которые пользуются одной сетью Wi-Fi, могут слиться в один профиль.

Гибридный подход — сочетает оба метода: детерминированный матчинг работает по подтверждённым идентификаторам, а вероятностный — расширяет охват на анонимов.

Из чего состоит архитектура Identity Resolution

Граф идентичностей (Identity Graph). Это структура данных, которая показывает связи между разными идентификаторами одного человека и помогает собрать из разрозненных следов единый профиль клиента.

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

Граф идентичностей показывает, как по-разному пользователь взаимодействует с брендом на разных устройствах. Без графа эти действия выглядят как действия нескольких человек.

Правила объединения (Matching Rules). Это набор условий, по которым система решает, считать несколько записей как идентификаторы одного человека или разных пользователей. Именно эти правила определяют, когда срабатывает детерминированный матчинг, а когда — вероятностный, и какие сигналы брать в расчёт. 

Real‑time и batch‑обработка — это два принципиально разных подхода к работе с данными. При real‑time каждое событие обрабатывается сразу, как только оно произошло. Например, человек мог долго не реагировать на рассылки, но спустя какое-то время открыл письмо от компании. После этого действия он в реальном времени перейдёт из сегмента «спящих» контактов в сегмент «активных». При batch‑обработке данные накапливаются за период (например, сутки), а потом обрабатываются одной большой порцией. 

Как повысить точность объединения данных

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

Поэтому данные нужно чистить и приводить к одному стандарту, а также можно отслеживать, чтобы hard ID собирались корректно. Например, форма подписки «не примет» email, если он написан с ошибкой после @, или в номере телефона не хватает цифры.

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

Как масштабировать объединение данных

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

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

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

Удобный инструмент для работы — это CDP, которая может собирать и хранить данные, проводить Identity Resolution, показывать аналитику и даёт возможность отправлять маркетинговые коммуникации по разным сегментам пользователей. 

Зарегистрируйтесь
И попробуйте Sendsay бесплатно

Объединение данных и 152-ФЗ

Для Identity Resolution необходимы в том числе персональные данные — а значит, российскому бизнесу стоит опираться на 152-ФЗ «О персональных данных».

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

На практике это означает три требования:

  • Согласие клиента на обработку данных должно быть понятным и прозрачным для каждого пользователя.
  • Данные должны храниться на серверах в России. 
  • Прямые идентификаторы стоит заменять на внутренние ID.

Как использовать Identity Resolution на практике

В разных отраслях фрагментация выглядит по-разному, но задача всегда одна — узнать человека за разрозненными следами. Разберём на примере нескольких сфер бизнеса.

В e-commerce. Представим, что человек изучает товар с телефона, а покупку завершает с ноутбука. Без объединения ему продолжит показываться реклама того товара, который он уже купил. После Identity Resolution оба устройства сойдутся в один профиль клиента.

В финтехе. Часть услуг клиент получает онлайн в приложении (например, переводит деньги), а часть — офлайн (допустим, приходит в отделение банка, чтобы подтвердить закрытие кредитки). Identity Resolution поможет связать эти события в историю одного профиля. 

В омниканальном ритейле. Покупки в офлайн-точке и заказы в приложении сойдутся в общую историю с помощью Identity Resolution. Поэтому в дальнейшем рекомендации в онлайне не будут показывать клиенту тот товар, который он купил в офлайне.

Ошибки при объединении данных

Допустить коллапс графа. Самая опасная из ошибок и при этом незаметная: один общий идентификатор стягивает в один профиль десятки чужих, а всплывает это, только когда в базе появляется «покупатель» с сотней email-адресов и бессвязной историей. 

Игнорировать качество данных. Если в базу попадают номера телефонов в разных форматах, дубли, опечатки — в матчинге будут прогрессировать ошибки. 

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

Как оценить качество объединения данных

Чтобы понять, всё ли работает как надо, результат нужно измерять. Можно опираться на четыре основным показателя:

  • Доля склеенных записей (Match Rate) — какая часть записей удалось связать с профилями: чем больше совпадений находит граф, тем она выше.
  • Точность (Accuracy). Показывает, какой процент склеек прошёл верно. 
  • Доля дубликатов — это отношение количества дублирующихся записей к общему числу записей в наборе. Результат зависит от того, как бизнес определил, что считать дубликатом. Поэтому перед посчётом доли нужно привести данные к единому стандарту, иначе есть риск пропустить реальные дубли или посчитать за них случайные совпадения.

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

Ответы на частые вопросы

Как CDP предотвращает дублирование профилей при сборе данных из разных источников?
Через правила матчинга и иерархию идентификаторов. При поступлении нового события платформа ищет в графе совпадение по сильным идентификаторам (email, номер телефона, логин). Если нашла — привязывает событие к существующему профилю. Если нет — заводит новый.
Как часто нужно пересчитывать граф идентичностей?
Зависит от задачи. Для триггерных сценариев (брошенная корзина, приветственная серия) граф должен обновляться в реальном времени. Для плановых рассылок и аналитических отчётов достаточно ежесуточного пересчёта. Важно не допускать ситуации, когда граф обновляется редко: за это время накопятся неучтённые склейки и ошибки, которые исказят сегменты и метрики.
Можно ли полностью автоматизировать Identity Resolution?
Большую часть процесса — да: матчинг, нормализацию, слияние профилей. Но полностью убрать ручную работу не получится. Правила матчинга нужно настраивать под конкретный бизнес.
Похожие статьи
Единый профиль: как объединить все данные о клиенте на одной платформе
12.08.2026
Профиль клиента 360 – как он поможет маркетологу
CDP и юнит-экономика: как платформа клиентских данных влияет на LTV, CAC и окупаемость маркетинга
28.09.2026
Как CDP помогает брендам больше знать о своих клиентах и зачем это нужно
Над статьёй работали:
Следите за нами
Присоединяйтесь к нам в соцсетях