CDP = “единое хранилище” и значит “единый клиент”? Нет, это ошибка в постановке задачи

CDP = “единое хранилище” и значит “единый клиент”? Нет, это ошибка в постановке задачи

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

Откуда растёт заблуждение. Его подкармливает маркетинговая упаковка: CDP позиционируют как универсальный коннектор “из CRM, сайта, колл-центра и DWH” в “one customer”. Плюс опыт прошлого цикла: раньше часто хватало витрины под конкретную задачу (например, ремаркетинг по событиям сайта) и всё “вроде сходилось”. В 2026 это не выдерживает проверку: privacy-first атрибуция сдвигается в сторону server-side, инкрементальности (оценка прироста), MMM. И если вы продолжаете мыслить как в эпоху last-click, то “единый клиент” превращается в красивую диаграмму, но не в управляемую модель данных.

Почему это неправда. Во‑первых, “единый профиль” не равен “единственному идентификатору”. Один человек в B2B и e-com почти всегда живёт в нескольких режимах идентификации: device ID → e-mail → учётка → партнёрская организация → контактные лица. Без строгих правил мэппинга и разрешения сущностей (entity resolution) вы получаете “единый контейнер” с множеством дублей и конфликтующими атрибутами. Во‑вторых, CDP не отменяет контекст. CRM-данные “про договор”, web-данные “про поведение”, CS-данные “про жизненный цикл (lifecycle)”. Склейка “как есть” ломает семантику: сегменты начинают требовать ручных исключений, а качество персонализации деградирует. В‑третьих, в privacy-first мире “склеилось/не склеилось” зависит не только от технологии, но и от режима согласий, сроков хранения и политик доступа. Значит, “единый клиент” должен быть объяснимым и проверяемым, а не предположением.

Что вместо него. Смотрите на CDP как на **сервис управления идентичностями и согласованной семантикой**, а не на склад. Минимальная конструкция:
— единая модель событий и статусов (что считаем “лидом”, что “активным”, что “тёплым” — и почему)
— правила resolution: детерминированные (e-mail, customer_id) + вероятностные (с оговорками), с трассировкой уверенности
— политика качества: как вы измеряете долю “неразрешённых”, долю конфликтов, свежесть атрибутов
— дата-сборка под use-case, а не “всё всем”. Для RevOps (выручка как общая ответственность) делайте CDP под сквозную цель: от привлечения до удержания, с проверкой инкрементальности, а не под “универсальные сегменты”.

Итог дисциплины: если в вашей CDP-стратегии нет entity resolution, семантических контрактов и метрик качества, то “единый клиент” — не цель, а риск.

— @CDProomRu