Проблема “данных ради данных”: почему CDP в 2026 надо начинать не с сборки, а с воронки ценности

Проблема “данных ради данных”: почему CDP в 2026 надо начинать не с сборки, а с воронки ценности

Я все чаще вижу одну и ту же ошибку в проектах CDP: команда начинает с источников (“подключим CRM, логи, app, сайт, call-центр”) и только потом пытается ответить, зачем это бизнесу. В 2026 такой подход обычно ломается сразу в двух местах: во-первых, privacy-first атрибуция вытесняет last-click, и маркетинг перестает “верить в единственный трек”; во-вторых, в B2B и RevOps ответственность за выручку распределяется между маркетингом, продажами и customer success, а значит CDP должна поддерживать процессы, а не просто хранить события.

Моя позиция простая: **CDP-система — это слой принятия решений, а не склад.** Поэтому проект надо запускать с вопроса “какое решение мы хотим улучшить?”, а уже затем — выбирать модель данных и интеграций. Иначе вы получите красивую витрину аудиторий, которая не влияет на цикл сделки или удержание.

Как это выглядит на практике. Мы брали кейс компании с длинным циклом продаж: лиды приходили из разных каналов, часть данных терялась между marketing → sales → support, и в результате каждое подразделение жило в своей правде. Когда начали разбирать, оказалось, что “качество данных” измеряют неправильно: считают заполненность полей, совпадение идентификаторов и долю событий, а не последствия. Исправили постановку метрик: посчитали, как часто корректно определяется следующий шаг в воронке (например, назначение контакта нужной команде и своевременность follow-up). После увязки customer-journey с CRM-статусами доля неверно маршрутизированных лидов просела с 18% до 9% (внутренний показатель, который быстро отражается на скорости обработки и конверсии в MQL/SQL — с оговоркой, что определения качества нужно согласовать между отделами).

Почему это важно именно для CDP
— CDP обычно “обещают” унификацию профиля. Но в RevOps ценность появляется только тогда, когда профиль отвечает на бизнес-вопрос: кому и что показывать/предлагать и когда.
— В эпоху topikal authority и AI-overviews “нулевая” потребность пользователя закрывается контентом с экспертизой, но путь к покупке все равно проходит через конкретные действия. Если CDP не встроена в контроль этих действий (а не только в сбор событий), она не становится частью механики выручки.
— В e-com, где средний чек снижается на 5–8% (покупатели экономят), CDP чаще нужна для retention и LTV, а не для повторения “первая покупка любой ценой”. Там без связки поведения с жизненным циклом клиента вы получите рост ремаркетинговых сегментов, но не рост выручки на пользователя.

Как бы я начинал CDP-проект заново (короткий чек-лист)
— Выберите один “решающий” процесс на 6–10 недель: маршрутизация лидов, персонализация онбординга, предиктивное удержание, контроль причин оттока.
— Зафиксируйте критерии успеха в терминах процесса (доля корректных next step, снижение времени реакции, рост доли возвращающихся) — не в терминах качества полей.
— Только потом проектируйте схему данных и правила идентификации. И да: согласуйте определения статусов между маркетингом и продажами, иначе CDP будет “правильной”, но бессмысленной.

Если свести все в одну мысль: **CDP не должна доказывать, что вы умеете объединять данные — она должна доказывать, что вы умеете менять исходы.** И чем раньше вы начнете с воронки ценности, тем меньше шансов, что проект закончится “витриной для отчетов”, а не инструментом RevOps.

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

— @CDPcompareRu