Как ритейлеру связать данные о покупателе из разных каналов: что обязательно нужно сделать и какие ошибки не допустить

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

Почему один покупатель превращается в несколько записей

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

Важный вопрос — где находится аудитория компании, какова ее численность и как она распределяется между каналами. Нужно понять, сколько покупателей идентифицируются через программу лояльности, пользуются приложением и сайтом, покупают только в рознице, какая часть остается анонимной и насколько эти группы пересекаются. Такой разбор особенно нужен на рынке, где значительная доля онлайн-покупок проходит за пределами собственных площадок бренда. По данным Data Insight, в 2025 году 81% российских онлайн-заказов пришлось на маркетплейсы.

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

С какой задачи начинать

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

Насколько сильно отсутствие такой связки искажает картину, показывает кейс сети «Колесо.ру».

Покупатель мог перейти на сайт из онлайн-рекламы, выбрать товар, а купить его уже в физическом магазине. В веб-аналитике он при этом выглядел как потерянный клиент. Компания стала передавать данные об офлайн-покупках в CDP (Customer Data Platform, платформу клиентских данных), где номер телефона сопоставлялся с Client ID из Яндекс Метрики. В результате визит на сайт и последующая покупка в магазине стали частью одной цепочки. После того как ретаргетинг начали оптимизировать с учетом онлайн- и офлайн-конверсий, в осенний сезон компания получила на 16% больше покупок год к году и дополнительно снизила стоимость целевого действия (CPA, Cost per Action) на 14%. Этот пример наглядно демонстрирует, почему начинать стоит не с попытки собрать максимум данных, а с конкретного вопроса. Для «Колесо.ру» такой задачей стало выяснить, что происходит с людьми, которых реклама привела на сайт, но которые не оформили заказ онлайн.

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

Как собрать единый профиль клиента

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

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

1. Определите состав профиля и источники данных

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

Следующий шаг — определить, где хранится эта информация. Обычно данные распределены между CRM, кассовыми системами, интернет-магазином, мобильным приложением, программой лояльности и службой поддержки. Для B2B-компаний к ним добавляются сведения о контрагентах, договорах, участниках принятия решений и истории переговоров. При этом не нужно стремиться сразу подключить все источники. Гораздо полезнее собрать информацию, которая необходима для решения выбранной задачи, проверить ее качество и только затем расширять профиль.

2. Приведите данные к единому виду и настройте идентификацию

Одна из главных сложностей — понять, какие записи относятся к одному человеку. Например, в CRM покупатель значится как «Алексей Иванов», в интернет-магазине — «Алексей И.», а в мессенджере его знают только по номеру телефона. Без правил сопоставления система может воспринимать его как трех разных клиентов.

Перед объединением данные необходимо привести к общему формату: унифицировать номера телефонов, адреса электронной почты и написание имен, исправить ошибки, выявить дубликаты. Затем определить признаки, по которым система будет связывать записи.

Наиболее надежный вариант — единый внутренний идентификатор клиента, который используется в разных сервисах. Однако на практике чаще приходится сопоставлять несколько признаков: номер участника программы лояльности, телефон, email или ID аккаунта на сайте. Совпадение имени и фамилии само по себе не может считаться достаточным основанием для объединения.

3. Установите правила объединения записей

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

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

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

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

4. Свяжите профиль с историей покупок и взаимодействий

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

Это позволяет использовать информацию в конкретных бизнес-процессах. Например, если клиент регулярно покупает расходные материалы каждые 40–45 дней, система может заранее напомнить менеджеру о вероятной следующей покупке. А если покупатель несколько раз просматривал определенный товар, сравнивал модели и затем обратился за консультацией, сотрудник сможет сразу перейти к обсуждению интересующего продукта.

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

Как это работает на практике

Задачу создания единого профиля клиента решал X5 через X5ID. Компания собрала и очистила более 60 млн клиентских профилей и связала через единую авторизацию мобильные приложения, сайты, магазины, чат-боты и другие сервисы. Число активных пользователей единого профиля превысило 10 млн в день, а использование аналитики внутри компании выросло более чем вдвое. Для компании меньшего масштаба логика та же: сначала соединить точки контакта, которые нужны для текущей задачи, и только потом расширять профиль.

Единый профиль нужен не только аналитикам. В мебельной сети LAZURIT обращения из звонков, чатов, сайта, мессенджеров и других каналов объединили в одном клиентском контуре. Покупатель может начать разговор с консультантом в салоне, продолжить его в мессенджере, а завершить покупку через кол-центр. При этом менеджер видит предыдущие переписки, звонки и историю заказов и не заставляет человека заново объяснять свой запрос. По данным кейса, 74% входящих заказов доходят до оплаты, а каждое четвертое обращение в кол-центр конвертируется в продажу.

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

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

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

Что мешает единому профилю работать

Самая очевидная проблема — ошибки идентификации. Поэтому сначала данные нормализуют: телефоны приводят к единому формату, email — к одному регистру, устраняют очевидные опечатки и технические значения. После этого ищут точные совпадения по надежным идентификаторам.

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

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

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

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

Такую работу лучше выстраивать не как разовый проект, а как постоянный процесс. За конкретные клиентские данные назначаются владельцы со стороны бизнеса: например, маркетинг может отвечать за правила работы с программой лояльности и согласиями на коммуникации, e-commerce — за данные интернет-заказов, розница — за сведения из магазинов. ИТ при этом отвечает за передачу, хранение и техническую обработку данных, но не должно самостоятельно решать, какой из двух конфликтующих бизнес-показателей считать правильным.

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

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

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

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

Где в этой схеме нужен искусственный интеллект

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

По исследованию Б1 и Redis Business Class «Ритейл-барометр 2025» , более 90% опрошенных ритейлеров либо уже использовали искусственный интеллект, либо планировали его внедрение. В маркетинге ИИ применяли 76% компаний, в клиентском сервисе — 67%, в ИТ — 43%. Академия ритейла в 2026 году насчитала у более чем ста представителей отрасли свыше 70 работающих сценариев и еще 56 пилотов.

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

Хорошо видно, что дает такая база, на примере «ВкусВилла». Компания создала собственную CDP, которая учитывает историю и каналы покупок, поведение и предпочтения клиентов. Один из сценариев был рассчитан на наиболее лояльных покупателей: на основе частоты потребления и устойчивых предпочтений им отправляли сообщения о новинках в любимых категориях и альтернативах привычным товарам. По сравнению с контрольной группой такая персонализация дала 12% дополнительной выручки, а ROI по чистой марже превысил 3,8. Причем эффект получили без скидок, а только за счет более точного предложения.

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

Данные должны складываться в одну историю

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

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

Источник: Oborot.ru