# Как объединить офлайн и онлайн данные о клиентах в одну систему > Касса видит один профиль, сайт — другой, приложение — третий. Разбираем, как склеить их в единый клиентский профиль без потери истории. **Рубрика:** Статьи **Дата:** 2026-07-03 Клиент покупает в рознице по карте лояльности, через неделю заходит на сайт с телефона, потом докупает что-то в приложении. Для бизнеса это три разных человека. Касса знает про чеки, но не видит брошенную корзину. Сайт знает про сессии, но не подозревает, что этот же визитер час назад оставил 8 тысяч на кассе. В итоге CRM шлет промокод «вернись, мы скучаем» тому, кто вчера был в магазине. Дыра между офлайном и онлайном стоит денег буквально каждый день: дублирующие рассылки, кривая сегментация, скидки тем, кто и так лоялен. О том, как объединить офлайн и онлайн данные в один профиль и перестать терять выручку на этих стыках, рассказывает Екатерина Чернова, CRM-маркетолог ClientCore — человек, который собирает такие связки руками. > **Читайте также:** [Единый профиль клиента и Customer 360: зачем бизнесу видеть клиента целиком](https://blog.clientcore.ru/articles/edinyy-profil-klienta-i-customer-360-zachem-biznesu-videt-klienta-celikom) ## Почему данные расползаются по трем углам Корень проблемы простой: каждая система заводит клиента по своему ключу. Касса опирается на номер карты лояльности или телефон. Сайт — на cookie и email. Приложение — на device ID и логин. Эти ключи между собой не связаны, пока вы их специально не сшили. Дальше начинается зоопарк. Один и тот же человек живет в базе как три записи. Допустим, в рознице он Иван с телефоном, на сайте — обезличенный анонимный визитер с cookie, в приложении — пользователь с email-ником. Аналитика по LTV врет, потому что считает их по отдельности. Маркетинг работает вслепую. > Самый частый случай — клиент со средним чеком 12 тысяч в рознице получает welcome-цепочку для новичков, потому что на сайте он "новый". Один наш ретейл-проект так годами слал VIP-покупателям скидку 10% на первый заказ. Когда мы склеили профили, выяснилось, что под раздачу попадало около 30% активной базы. > > — Екатерина Чернова, CRM-маркетолог, ClientCore ## Единый идентификатор: с чего начинается склейка Прежде чем что-то объединять, нужно решить, по какому полю вы будете узнавать человека везде. В большинстве проектов рабочий якорь — телефон и email. Телефон собирается на кассе через программу лояльности, email — на сайте и в приложении при регистрации. Идеально, когда оба канала просят одно и то же. Если в рознице кассир заводит карту по телефону, а на сайте логин идет через email и эти два контакта нигде не пересекаются, клиент так и останется двумя записями. Поэтому связку начинают не с интеграций, а с правил сбора контактов. Касса должна уметь спросить email, сайт — мотивировать оставить телефон. **Норма:** **Норма** - единый ключ идентификации определен заранее (телефон + email) - на кассе собирают второй контакт, не только карту - есть правило дедупликации: что делать, если нашлись два профиля с одним телефоном **Red flag** **Red flag:** - в рознице только телефон, на сайте только email, мостика между ними нет - дубли склеиваются вручную раз в квартал выгрузкой в Excel - никто не отвечает за качество контактных данных ## Передача чеков в CDP: главное звено Онлайн-поведение собрать легко — для этого есть пиксели, SDK, веб-трекинг. А вот офлайн-покупки нужно затащить в систему отдельно. Передача чеков в CDP — та операция, которая превращает абстрактного «держателя карты» в человека с понятной историей покупок: что брал, на какую сумму, как часто, в каком магазине. Технически это поток из кассового ПО или товароучетной системы в платформу данных. Чек уходит с привязкой к идентификатору клиента — тому самому телефону или номеру карты. Дальше CDP (например, Mindbox) матчит чек с профилем и дописывает покупку в историю. Важно гнать не агрегаты вроде «потратил за месяц 40 тысяч», а сырые позиции: SKU, количество, цена, скидка. Иначе товарные рекомендации и сегменты по категориям работать не будут. > Передачу чеков почти всегда недооценивают по детализации. Приходят с задачей "лить сумму чека" — а потом хотят сегмент "покупал детское питание за последние 60 дней" и упираются в стену. Мы закладываем построчную передачу сразу, даже если товарные сценарии пока не в плане. Доделать парсинг позиций потом стоит втрое дороже, чем заложить структуру на старте. > > — Екатерина Чернова, CRM-маркетолог, ClientCore Отдельная боль — задержки и пропуски. Если чеки доезжают раз в сутки пачкой, реактивные сценарии после покупки опаздывают. А если webhook иногда падает молча, в истории появляются дыры, которые никто не замечает, пока не поедет вся аналитика по выручке. ## Идентификация клиента на сайте: как поймать анонима С офлайном разобрались, теперь самая скользкая часть. Большая часть трафика на сайте обезличена. Человек ходит, смотрит, кладет в корзину — а вы не знаете, кто он, пока он не залогинится или не оформит заказ. Идентификация клиента на сайте решает именно эту задачу: связать анонимную сессию с конкретным профилем в базе. Механика стандартная. Пока визитер аноним, его поведение копится на cookie или анонимный ID. В момент, когда он вводит email, авторизуется или переходит по ссылке из письма (там зашит его идентификатор), система склеивает накопленную историю с реальным профилем. Все, что он смотрел до этого, ретроспективно привязывается к человеку. Ссылки из писем и пушей — недооцененный канал идентификации. Клиент кликает по персональной ссылке, и сайт сразу узнает его, даже без логина. Это работает, если в письмах проставлены параметры с зашитым ID, а трекер на сайте их читает. Многие проекты теряют здесь половину матчей просто потому, что email-платформа и веб-трекер не договорились о формате метки. **Норма:** **Норма** - анонимная история подтягивается к профилю после первой же идентификации - переход по ссылке из письма узнает клиента без повторного логина - cookie и device ID не теряются при смене страницы или возврате через неделю **Red flag** **Red flag:** - после авторизации вся допрошлая история визита обнуляется - на сайте и в приложении один человек — это два разных клиента - веб-события не доезжают в профиль, аналитика живет в отдельном Google Analytics ## Сборка единого профиля: где все встречается Когда офлайн-чеки, веб-поведение и данные приложения текут в одну платформу под единым ключом, рождается то, ради чего все затевалось — единый клиентский профиль. В нем видно цельную картину: человек смотрел кроссовки на сайте в обед, вечером купил их в магазине, через месяц зашел в приложение за уходом для обуви. Эта картина меняет маркетинг по существу. Сегментация перестает врать. Сценарии учитывают полный контекст: не шлем промокод на товар, который клиент купил вчера офлайн. Считаем настоящий LTV по всем каналам, а не по обрывкам. Каналы коммуникации выбираем по реальной активности, а не по тому, где случайно остался контакт. > После склейки у одного fashion-клиента средняя выручка с триггерных рассылок выросла примерно на 20% за квартал. Не за счет новых сценариев — старые наконец перестали стрелять мимо. Сценарий "брошенный просмотр" работал только онлайн, а теперь дотягивает тех, кто посмотрел на сайте и не дошел до кассы. > > — Екатерина Чернова, CRM-маркетолог, ClientCore Важный момент про дедупликацию. Когда сводите источники, всплывают конфликты: два профиля с одним телефоном, но разными email. Нужны правила, какой профиль считать главным и как мержить историю. Без этого склейка превращается в новую кашу, где данные не потеряны, но перепутаны. ## Порядок действий: с чего начать на практике Соблазн велик — подключить все источники разом и утонуть в интеграциях. На практике двигаются итерациями, иначе проект растягивается на год и теряет смысл. Сначала фиксируете единый идентификатор и наводите порядок в сборе контактов. Потом подключаете самый ценный офлайн-источник — обычно это касса с построчными чеками. Дальше настраиваете идентификацию на сайте и сшиваете анонимный трафик. Приложение и прочие точки добавляете, когда базовая связка уже дает результат. И только после этого строите сценарии поверх объединенных данных. **Норма:** **Норма** - этапы разнесены, каждый дает измеримый результат до перехода к следующему - перед запуском сценариев проверяют качество и полноту склейки - есть мониторинг потоков: упал webhook — узнали в тот же день, не через месяц **Red flag** **Red flag:** - все интеграции запускают параллельно и без контроля качества - сценарии строят на данных, в которых 20% профилей — дубли - никто не сверяет выручку из CDP с реальными продажами из учетной системы --- [Открыть статью на сайте](https://blog.clientcore.ru/articles/kak-obedinit-oflayn-i-onlayn-dannye-o-klientah-v-odnu-sistemu)