Введение
Современная маркетинговая инфраструктура компании, как правило, состоит из нескольких независимых систем. CRM хранит данные о клиентах и сделках, веб-аналитика фиксирует поведение на сайте, коллтрекинг отслеживает телефонные обращения, мессенджеры накапливают историю переписки. Каждая из этих систем оперирует собственными идентификаторами и не имеет встроенных механизмов связи с остальными.
В результате один и тот же клиент представлен в данных как несколько независимых сущностей: анонимный cookie в Яндекс.Метрике, запись с телефоном в CRM, username в Telegram. Это приводит к искажению аналитики, дублированию коммуникаций и невозможности построения корректной атрибуции.
Решением данной проблемы служит концепция Customer 360 — формирование единого клиентского профиля на основе данных из всех источников. При этом реализация такого решения не обязательно требует приобретения дорогостоящих CDP-платформ.
- Дорогие читатели и пользователи платформы StreamMyData! Хотим пригласить вас в наш телеграм канал, в котором публикуются важные новости, обновления, статьи и кейсы.
Концепция Customer 360: единый клиентский профиль
Customer 360 представляет собой подход к организации данных, при котором информация о клиенте из различных систем объединяется в единую запись посредством идентификаторов-ключей. Принципиальное отличие от простой консолидации данных в хранилище заключается в установлении связей между записями разных источников.
На рынке представлены готовые Customer Data Platform, которые решают задачу построения единого клиентского профиля «из коробки». К преимуществам таких решений относятся: быстрое внедрение, готовые интеграции с популярными источниками данных, визуальный интерфейс для сегментации и построения аудиторий. Однако существуют и значительные ограничения. Во-первых, высокая стоимость ежемесячной подписки — от нескольких сотен тысяч рублей. В результате подобные решения становятся недоступными для среднего бизнеса. Во-вторых, отсутствие гибкости, адаптация под специфику бизнеса ограничена. В-третьих, зависимость от поставщика: данные хранятся на стороне платформы, миграция на другое решение сопряжена с существенными затратами.
Разработка собственного решения целесообразна при наличии следующих условий:
- существующая инфраструктура хранения данных (ClickHouse, BigQuery, PostgreSQL);
- специалисты с компетенциями в SQL и ETL;
- нестандартные источники данных, не поддерживаемые CDP из коробки;
- бюджетные ограничения на приобретение коммерческих платформ.
Для создания CDP необходим простой набор инструментов:
- Хранилище данных (DWH) — для хранения сырых, предобработанных и объединенных данных;
- ETL коннекторы — для выгрузки сырых данных. Вы можете использовать готовые коннекторы StreamMyData.
- Инструмент, запускающий скрипты обработки и объединения данных, такой как Airflow.
Основная сложность заключается не в выборе инструментов, а в проектировании архитектуры.
Типы идентификаторов клиентов
Ключевым элементом Customer 360 являются идентификаторы — атрибуты, позволяющие установить принадлежность записей из разных систем одному клиенту.
Идентификаторы веб-аналитики
ga_client_id (Google Analytics) и ym_client_id (Яндекс.Метрика) — это анонимные cookie-идентификаторы браузера. Они не содержат персональных данных пользователя и представляют собой случайно сгенерированные строки, которые присваиваются каждому посетителю сайта.
Плюсы и минусы client_id:
- Доступны «из коробки» — не требуют дополнительной настройки, автоматически присваиваются всем посетителям
- Максимальный охват — идентифицируют даже анонимных пользователей, которые не проходили регистрацию
- Привязка к конкретному устройству и браузеру — один и тот же человек с разных устройств будет выглядеть как разные посетители
- Ограниченный срок жизни cookie
- Обнуляются в режиме инкогнито или при очистке cookies
user_id — внутренний идентификатор авторизованного пользователя. Также является анонимным: передаётся не логин или email, а внутренний ID из вашей системы.
Плюсы и минусы user_id :
- Высокая кроссплатформенность — позволяет определить одного и того же пользователя с любого устройства и браузера
- Не зависит от срока жизни cookies и настроек приватности браузера
- Для внедрения требуется участие разработчиков
- Необходим работающий механизм авторизации на сайте или в приложении
- Охват ограничен долей авторизованных пользователей
Идентификаторы CRM
Телефонный номер — наиболее надежный идентификатор клиента. Номера меняются редко, а связь «один номер — один человек» соблюдается в большинстве случаев (исключение — корпоративные номера, которыми могут пользоваться несколько сотрудников).
Главная сложность работы с телефонами — нормализация, то есть приведение к единому формату. Один и тот же номер может быть записан в CRM по-разному:
| Как записано | После нормализации |
| +7 (495) 123-45-67 | 74951234567 |
| 8-495-123-45-67 | 74951234567 |
| 84951234567 | 74951234567 |
| 495 123 45 67 | 74951234567 |
Без нормализации система будет воспринимать эти записи как четырёх разных клиентов. Поэтому перед объединением данных необходимо очистить номер от всех символов кроме цифр и привести к единому формату (например, 11 цифр, начиная с «7»).
Email-адрес обладает средней надежностью: у одного клиента может быть несколько почтовых ящиков (личный, рабочий, «мусорный» для рассылок).
Здесь тоже важна нормализация:
- Приведение к нижнему регистру:
Ivan.Petrov@Mail.RU → ivan.petrov@mail.ru - Учёт особенностей Gmail: адреса
ivan.petrov@gmail.com и ivanpetrov@gmail.com принадлежат одному пользователю (Gmail игнорирует точки)
При объединении профилей email лучше использовать как вспомогательный идентификатор в связке с телефоном, а не как основной ключ.
Рекламные идентификаторы
Click ID рекламных систем (gclid, yclid, fbclid) связывают рекламный клик с сессией на сайте. Срок жизни ограничен одним визитом.
Для мобильных приложений используются device_id: IDFA (iOS), GAID (Android). Следует учитывать, что после введения App Tracking Transparency на iOS доступность IDFA существенно снизилась.
Идентификаторы внешних систем
Коллтрекинг генерирует call_id и обеспечивает связь звонка с веб-сессией через подменный номер, время и источник перехода.
Мессенджеры предоставляют собственные идентификаторы (telegram_id, whatsapp_id). Связь с остальными данными возможна только при получении телефона или email в процессе коммуникации.
Сравнительная характеристика идентификаторов
| Идентификатор | Надёжность | Охват | Кросс-девайс |
| phone | Высокая | Средний | Да |
| Средняя | Средний | Да | |
| user_id | Высокая | Низкий | Да |
| ga_client_id | Низкая | Высокий | Нет |
| gclid/yclid | Средняя | Низкий | Нет |
| telegram_id | Высокая | Низкий | Да |
Архитектура хранения данных
Для объединения клиентских данных из разных источников рекомендуется использовать структуру из трёх связанных таблиц: таблица клиентов, таблица идентификаторов (мостовая) и таблица событий.
Таблица клиентов
Главная таблица, где каждая строка — это один уникальный клиент. Каждому клиенту присваивается суррогатный ключ — это искусственный идентификатор, который генерирует сама система (не телефон и не email, а случайный уникальный код). Зачем он нужен? Телефон или email могут измениться, а суррогатный ключ остаётся навсегда.
| customer_id | phone_main | email_main | first_seen_at | last_seen_at |
| c001 | 79151234567 | ivan@mail.ru | 2024-01-15 | 2024-03-20 |
| c002 | 79269876543 | anna.k@gmail.com | 2024-02-03 | 2024-03-18 |
| c003 | 79031112233 | — | 2024-03-01 | 2024-03-21 |
Таблица идентификаторов (мостовая)
Мостовая таблица — это связующее звено между клиентом и всеми его идентификаторами из разных систем. Один клиент может иметь множество идентификаторов: несколько cookie, телефон, email, ID из CRM и т.д.
| customer_id | id_type | id_value | source_system | confidence |
| c001 | phone | 79151234567 | bitrix | 0.95 |
| c001 | ivan@mail.ru | bitrix | 0.85 | |
| c001 | ga_client_id | 1234567890.1609459200 | google_analytics | 0.30 |
| c001 | ym_client_id | 9876543210 | yandex_metrika | 0.30 |
| c002 | phone | 79269876543 | amo | 0.95 |
| c002 | ga_client_id | 1122334455.1612137600 | google_analytics | 0.30 |
Поле confidence (достоверность) показывает, насколько надёжна связь. Телефон даёт высокую достоверность (0.95), а cookie-идентификатор — низкую (0.30), потому что cookies могут очиститься или принадлежать другому члену семьи.
Таблица событий
Здесь хранятся все действия клиентов: визиты на сайт, звонки, заявки, покупки.
| event_id | customer_id | event_type | event_at | source_system | properties |
| e001 | c001 | page_view | 2024-03-20 10:15 | google_analytics | {«url»: «/catalog»} |
| e002 | c001 | call | 2024-03-20 10:32 | calltouch | {«duration»: 180} |
| e003 | c001 | purchase | 2024-03-20 11:05 | bitrix | {«amount»: 15000} |
| e004 | c002 | form_submit | 2024-03-18 14:22 | tilda | {«form»: «callback»} |
Как таблицы связаны между собой
Все три таблицы связаны через единый ключ клиента (customer_id). Это позволяет в любой момент «собрать» полную картину: от списка всех идентификаторов клиента до истории его действий во всех каналах.
Пример: как найти все действия клиента
Допустим, в систему поступил звонок с номера 79151234567. Как получить полную историю этого клиента?
Шаг 1. В таблице идентификаторов ищем строку, где id_type = phone и id_value = 79151234567. Находим customer_id = c001.
Шаг 2. В таблице событий выбираем все строки, где customer_id = c001
Результат – полная картина взаимодействий:
| Время | Событие | Источник | Детали |
| 2024-03-20 10:15 | Просмотр страницы | Google Analytics | /catalog |
| 2024-03-20 10:32 | Звонок | Calltouch | 3 минуты |
| 2024-03-20 11:05 | Покупка | Bitrix | 15 000 ₽ |
Рекомендации по хранению
При небольших объемах (до сотен тысяч событий) все таблицы можно хранить в одной базе данных (PostgreSQL, MySQL).
При высоких нагрузках (миллионы событий в день) таблицу событий лучше вынести в специализированную аналитическую базу данных (например, ClickHouse) с партиционированием — это разбиение данных на части по дате. Например, события за каждый месяц хранятся отдельно, что ускоряет запросы в десятки раз.
Алгоритмы объединения записей (Identity Resolution)
Мы разобрались, какие идентификаторы можно собирать и как организовать их хранение. Теперь ключевой вопрос: как понять, что записи из разных систем принадлежат одному и тому же человеку? Этот процесс называется Identity Resolution — разрешение идентичности. Рассмотрим три основных подхода: от простого к сложному.
Детерминистический матчинг
Основан на точном совпадении по надёжным ключам. При поступлении заявки с телефоном выполняется поиск в базе клиентов; при обнаружении совпадения записи связываются.
Иерархия приоритетов ключей: phone > email > user_id > ga_client_id. Совпадение по телефону считается достаточным основанием для объединения профилей. Совпадение только по ga_client_id требует дополнительной верификации.
Транзитивное замыкание
При наличии цепочки связей выполняется объединение: если профиль A связан с профилем B через телефон, а профиль B связан с профилем C через email, профили A, B и C объединяются.
Данный подход требует механизмов защиты от ложных объединений. Корпоративные или общие email-адреса могут привести к ошибочному схлопыванию несвязанных профилей. Необходимы правила исключений и процедура ручной модерации спорных случаев.
Вероятностный матчинг
Применяется при отсутствии точных ключей. Совокупность косвенных признаков (совпадение IP-адреса, User-Agent, временная близость событий) позволяет установить вероятностную связь. Метод применим для аналитических задач, но не рекомендуется для автоматического объединения профилей.
Рекомендуемая практика: детерминистический матчинг выполняется автоматически с записью результатов в базу; вероятностные связи помещаются в очередь на ручную проверку.
Практическое применение
Расширенная сегментация
Единый профиль позволяет формировать сегменты, ранее недоступные из-за разрозненности данных.
Сегмент «Обращение без конверсии»:
SELECT DISTINCT c.customer_id, c.phone_main
FROM dim_customer c
JOIN fact_events e ON e.customer_id = c.customer_id
WHERE e.event_type = 'call'
AND e.event_at > NOW() - INTERVAL '30 days'
AND c.customer_id NOT IN (
SELECT customer_id FROM fact_events
WHERE event_type = 'purchase'
);
Что вы получите: список клиентов с телефонами, которые обращались к вам за последние 30 дней (звонили, писали в чат, оставляли заявку), но так и не совершили покупку.
Как использовать:
- Передать список в отдел продаж для повторного прозвона;
- Загрузить телефоны в рекламный кабинет и запустить ретаргетинг;
- Отправить SMS или сообщение в мессенджер с персональным предложением.
Это один из самых ценных сегментов — люди уже проявили интерес, их не нужно «прогревать» с нуля.
Дополнительные примеры сегментов:
- активность в мессенджере при отсутствии визитов на сайт;
- звонок в компанию после просмотра рекламы, но без перехода на сайт;
- добавление товара в корзину с мобильного устройства и завершение покупки с десктопа;
- высокая частота визитов без совершения целевых действий (звонков, заявок, покупок).
Оптимизация ремаркетинга
Единый профиль обеспечивает формирование полных списков исключений для рекламных кампаний. Клиенты, совершившие покупку через любой канал, исключаются из показа рекламы соответствующего товара.
Выгрузка сегментов в рекламные системы (Яндекс.Аудитории, Google Customer Match, VK) выполняется через нормализованные списки телефонов и email-адресов.
Персонализация коммуникаций
Консолидированные данные позволяют учитывать полную историю взаимодействий во всех точках контакта: веб-поведение при подготовке к телефонному разговору, историю переписки в мессенджерах при формировании email-рассылок.
Корректная атрибуция
Типичная последовательность касаний: рекламный переход → визит на сайт → повторный визит из органического поиска → телефонный звонок → офлайн-покупка. При отсутствии единого профиля данная последовательность представлена как четыре независимых сущности. При наличии профиля формируется единая цепочка, позволяющая корректно распределить вклад каждого касания.
Заключение
Построение единого клиентского профиля представляет собой решаемую инженерную задачу: структура таблиц в базе данных, ETL-процессы для загрузки данных из источников, алгоритмы матчинга для связывания записей.
Основные сложности носят организационный характер: стандартизация форматов идентификаторов, настройка интеграций с системами-источниками, разработка процедур обработки конфликтов. Это не разовый проект, а процесс, требующий постоянной поддержки.
Рекомендуемый подход к внедрению — поэтапное расширение: начальная интеграция CRM и веб-аналитики через user_id, добавление телефонов из заявок, подключение коллтрекинга. Каждый новый источник расширяет профиль и повышает точность маркетинговых решений.
Стек инструментов для самостоятельной реализации: ClickHouse или PostgreSQL для хранения, Airflow для оркестрации ETL, dbt для трансформаций. Приобретение коммерческих CDP-платформ не является обязательным условием для решения данной задачи.
