Dilshat Rakhimov
July 2026 · 11 min read

«Мы выбираем CDP» приходило мне в почту трижды за этот год — и означало три разные вещи: у нас каша в событиях, мы не можем связать пользователя приложения с карточкой в CRM, и маркетинг не может запустить кампанию без аналитика. Задача CDP — только одна из трёх.

Я уже писал, что центром стека должно быть хранилище — это приквел к этому тексту. А это его неудобное продолжение: когда хранилище на месте, большую часть того, что продаёт CDP, вы либо уже имеете, либо можете купить за долю от контракта. Ниже — как я это разбираю и где живёт честное «да».

Вам правда нужна CDP cover

Что на самом деле упаковано в CDP

Если убрать маркетинг, CDP — это пять возможностей, проданных как одна:

  1. Сбор — SDK и серверные библиотеки, которые снимают событие один раз и разводят его по получателям.
  2. Идентификация — сшивка анонимных id, авторизованных id, почт и устройств в один профиль.
  3. Сегментация — сборка аудиторий без SQL.
  4. Активация — отправка этих аудиторий в рекламные кабинеты, email, push, CRM.
  5. Governance — контроль схемы, работа с PII, состояние согласий.

Продуктом является именно связка. Ловушка в том, что команды покупают все пять, чтобы починить одну, — и та одна обычно как раз та, которую CDP за них починить не может.

Одна упакованная платформа рядом со стеком отдельных composable-слоёв

Тест 1: это точно не проблема таксономии?

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

Мне достался аналитический контур страхового бизнеса банка, где летело 200+ типов событий под 18+ префиксами, с вложенными объектами свойств, тридцатью с лишним вариациями одного платёжного события и generic-событием payment на 154 000 раз в месяц рядом со случайным revenue_amount на 94 000. Пересборка свела это к 35 событиям: одно screen_viewed, одно technical_error с severity и source в свойствах, одно серверное payment_completed после колбэка платёжного шлюза с revenue внутри и обязательный product_type с каталогом из 23 значений, через который все продуктовые линейки идут по одной схеме.

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

Тест 2: это проблема идентификации?

Симптомы: «мы не можем связать поведение в приложении с карточкой в CRM», «мы не знаем, один ли это человек в вебе и в приложении».

Эта проблема настоящая — и всё равно обычно не про CDP. Паттерн, который я внедряю, — конверт идентичности:

СлойЧто хранитУ кого доступ
Продуктовая аналитикаUUID, поведение, UTM, слойаналитики, маркетинг
CRM / внутренняя БДUUID → ИИН, ФИО, телефон, emailтолько авторизованные сотрудники
BI / хранилищеджойн этих двух под RBACаналитики, read-only

Аналитический инструмент вообще не видит персональных данных — он получает UUID, сгенерированный один раз при первой авторизации. Связку держит CRM. Любой вопрос, которому нужны обе стороны («что делал конкретный клиент перед оттоком»), закрывается джойном в BI, за ролевым доступом, с аудитом выгрузок.

Это проектное решение плюс несколько дней работы: выпустить UUID, санитизировать свойства событий до отправки с клиента, снять уже накопившийся PII через identify API инструмента, собрать lookup-вьюху и выдать её тем ролям, которым положено. По казахстанскому закону о персональных данных — и по GDPR для всех, кто продаёт в ЕС — это не факультативная гигиена, а именно то, что проверяют. CDP с радостью сделает идентификацию за вас, но делает она это, храня персональные данные у себя, а для регулируемого финансового продукта это разговор с комплаенсом сложнее, а не проще.

Покупка CDP ради идентификации означает перенос вашего PII ещё одному вендору. Для банка это обычно аргумент против, а не за.

Тест 3: это проблема активации?

Симптомы: «данные лежат в BigQuery, и никто ничего не может с ними сделать».

Активация чётко делится надвое, и обе половины сегодня дёшевы.

Рекламная активация — это server-side теггирование плюс conversion API. В пересборке CAPI для страхового продукта диагноз состоял из четырёх чисел: покрытие click id на Purchase — 0,07%, Event Match Quality — 6,8 из 10, external id на 40,8% покупок, email — на 1,1%. Причина была архитектурной: пиксель грузился после гидратации, а плагин очистки URL срезал click id раньше, чем их кто-либо успевал прочитать. Лечение — first-party серверный контейнер на собственном поддомене клиента плюс перехват click id инлайн-скриптом в head до того, как отработает роутер. Хостинг server-side GTM в тех развёртываниях, что я вёл, стоит примерно $20–200/мес в зависимости от тарифа и power-ups; self-managed Cloud Run попадает в тот же диапазон, если честно считать постоянно поднятые инстансы.

Lifecycle-активация — это reverse ETL: собрать сегмент SQL-моделью в хранилище и синкнуть его в Klaviyo, CRM или audience API рекламной платформы. Бесплатный тариф Hightouch даёт два активных синка с неограниченным числом получателей и мест — достаточно, чтобы проверить паттерн до того, как кто-то что-то подпишет.

Вместе эти две вещи закрывают ту активацию, ради которой большинство команд и собирались покупать CDP, — за пару сотен долларов в месяц.

Тест 4: это про реальное время и нетехнического пользователя?

Вот здесь ответ переворачивается в «да».

Покупайте CDP, когда одновременно верно всё перечисленное:

  • Маркетологи должны собирать и запускать аудитории сами, без SQL и без очереди к аналитику.
  • Активация должна происходить за секунды, а не по расписанию синков — персонализация внутри сессии, брошенная корзина в живом сценарии, next-best-action на звонке.
  • Источников много (десяток с лишним SaaS-инструментов, а не три), а инженерных рук на поддержку пайплайнов между ними нет.
  • Нужно единообразно соблюдать согласия и списки исключений во всех получателях, с аудиторским следом, потому что вы работаете в нескольких юрисдикциях.

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

Обратите внимание, чего в списке нет: «у нас много данных» и «у конкурентов есть». Это не причины.

Дешёвая архитектура, в порядке сборки

Если тесты 1–3 не прошли, а тест 4 не сработал, стройте вот это — и порядок важен, потому что каждый слой бесполезен без предыдущего.

  1. Таксономия. Одна схема, плоские свойства, объявленные типы, владелец. Денежные события — серверные, с ключом идемпотентности. Governance включён: плановые события, алерты на внеплановые, автоматическая блокировка всего, что попадает под PII-паттерн.
  2. Хранилище. Сырые события, записи CRM и рекламный расход в одном месте — BigQuery по умолчанию, если вы уже на GA4. Это единственный слой, который, скорее всего, будет жив через пять лет.
  3. Идентификация. UUID в аналитических инструментах, PII в CRM, одна таблица связки под RBAC. Ключи определяются до того, как поверх что-то строится.
  4. Активация. Серверный контейнер плюс conversion API для рекламы; reverse ETL для CRM, email и push. Оба читают из хранилища; ни один не становится вторым источником правды.
  5. Согласия. Состояние согласия течёт с клиента в серверный контейнер и едет вместе с событием. Переход на server-side теггирование не снимает требование по согласиям — заблуждение, которое я исправляю практически на каждом проекте.

Форма расходов: потребление хранилища, $20–200/мес за серверный контейнер, бесплатный или usage-based тариф reverse ETL. Сравните с CDP-концом, где крупные вендоры цены вообще не публикуют: тарифы Segment на CDP выдаются только по запросу и считаются по monthly tracked users — метрике, которая растёт независимо от того, приносят ли вам эти пользователи хоть что-то.

Итог

Большинство разговоров «нам нужна CDP» — это одна из трёх более дешёвых проблем в костюме CDP: таксономия, которая не означает ничего постоянного; модель идентификации, которую никто не спроектировал; или разрыв в активации, который закрывается серверным контейнером и синком reverse ETL за пару сотен долларов в месяц. Пройдите четыре теста честно. Если маркетологам нужны самостоятельные аудитории, активируемые за секунды, по десятку источников, с соблюдением согласий везде — покупайте, и покупайте нормально. Если нет — стройте таксономию → хранилище → идентификацию → активацию → согласия именно в этом порядке и сохраняйте право передумать про любого вендора выше уровня хранилища.

Если вы прямо сейчас в такой оценке, полезный первый шаг сильно меньше тендера: посчитать типы событий, проверить, не лежат ли персональные данные в аналитическом инструменте, и измерить реальное покрытие click id на покупках. Три числа, работы на полдня. Они и покажут, какой из четырёх тестов вы на самом деле не проходите, — и по моему опыту это редко бывает четвёртый.

Источники