CDP в 2026: сбор данных уже не спасает
Маркетинг-операции часто упираются не в количество полей, а в качество связки данных с выручкой. Когда last-click слабеет, а RevOps требует общей картины, где у вас сейчас главный провал в CDP?
ВАРИАНТЫ:
1. Нет единого customer ID между каналами
2. События есть, но схема данных разваливается
3. Сегменты строим вручную, слишком медленно
4. CDP есть, но бизнес ей не доверяет
Маркетинг-операции часто упираются не в количество полей, а в качество связки данных с выручкой. Когда last-click слабеет, а RevOps требует общей картины, где у вас сейчас главный провал в CDP?
ВАРИАНТЫ:
1. Нет единого customer ID между каналами
2. События есть, но схема данных разваливается
3. Сегменты строим вручную, слишком медленно
4. CDP есть, но бизнес ей не доверяет
Почему CDP проваливается не на выборе вендора, а на схеме идентичности
Я часто вижу одну и ту же ошибку в проектах по Customer Data Platform: командa долго сравнивает фичи, а потом удивляется, что данные «не склеиваются», сегменты расходятся, а маркетинг не доверяет витрине.
Мой вывод простой: CDP ломается не на загрузке данных, а на том, **как вы описали человека**.
Если у вас нет жёсткой схемы идентичности, платформа превращается в дорогой агрегатор событий. Она честно собирает клик, покупку, визит, открытие письма — но не понимает, это один и тот же клиент или три разных сигнала из разных систем. Для marketing ops это обычно выглядит так:
— в CRM один контакт,
— в e-mail-платформе второй,
— в веб-аналитике третий,
— в коллтрекинге четвёртый.
И дальше начинается ручная магия, которую невозможно масштабировать.
В 2026 году это особенно болезненно. Когда performance всё сильнее уходит в privacy-first атрибуцию, а last-click теряет вес, качество identity layer становится базовой инфраструктурой, а не «проектом по данным». Без этого нельзя нормально считать инкрементальность, строить retention-цепочки и связывать маркетинг с выручкой в логике RevOps.
Из практики: в одном B2B-внедрении у нас было 14 источников и 9 вариантов ключа пользователя. После нормализации identity и правила приоритета для email, phone и customer_id число «уникальных» профилей сократилось на 18%. Это не потеря базы — это очистка дублей. Зато сегменты перестали гулять, а аудитории для коммуникаций стали повторяемыми.
Я бы проверял CDP не вопросом «что она умеет», а вопросом:
**можем ли мы за 5 минут объяснить, почему два события принадлежат одному клиенту?**
Если ответ расплывчатый — внедрение ещё не началось, даже если договор уже подписан.
По этой же теме советуем @RetentionPaid
Я часто вижу одну и ту же ошибку в проектах по Customer Data Platform: командa долго сравнивает фичи, а потом удивляется, что данные «не склеиваются», сегменты расходятся, а маркетинг не доверяет витрине.
Мой вывод простой: CDP ломается не на загрузке данных, а на том, **как вы описали человека**.
Если у вас нет жёсткой схемы идентичности, платформа превращается в дорогой агрегатор событий. Она честно собирает клик, покупку, визит, открытие письма — но не понимает, это один и тот же клиент или три разных сигнала из разных систем. Для marketing ops это обычно выглядит так:
— в CRM один контакт,
— в e-mail-платформе второй,
— в веб-аналитике третий,
— в коллтрекинге четвёртый.
И дальше начинается ручная магия, которую невозможно масштабировать.
В 2026 году это особенно болезненно. Когда performance всё сильнее уходит в privacy-first атрибуцию, а last-click теряет вес, качество identity layer становится базовой инфраструктурой, а не «проектом по данным». Без этого нельзя нормально считать инкрементальность, строить retention-цепочки и связывать маркетинг с выручкой в логике RevOps.
Из практики: в одном B2B-внедрении у нас было 14 источников и 9 вариантов ключа пользователя. После нормализации identity и правила приоритета для email, phone и customer_id число «уникальных» профилей сократилось на 18%. Это не потеря базы — это очистка дублей. Зато сегменты перестали гулять, а аудитории для коммуникаций стали повторяемыми.
Я бы проверял CDP не вопросом «что она умеет», а вопросом:
**можем ли мы за 5 минут объяснить, почему два события принадлежат одному клиенту?**
Если ответ расплывчатый — внедрение ещё не началось, даже если договор уже подписан.
По этой же теме советуем @RetentionPaid
Как Nike собрал клиентские данные в один контур и перестал терять повторные продажи
В 2026 году у маркетинга всё меньше шансов выиграть только за счёт охвата. В e-com и D2C средний чек проседает, пользователи экономят, а last-click всё хуже объясняет выручку. Для брендов уровня Nike это особенно чувствительно: если клиент купил кроссовки один раз, дальше важно не «догонять» его рекламой, а понимать, что именно увеличивает повторную покупку и LTV.
Контекст у Nike был типичный для крупного омниканального бренда: сайт, приложение, офлайн-магазины, подписки, CRM, медиа-кабинеты — данные жили отдельно. Из-за этого маркетинг видел только фрагменты пути клиента. Один и тот же человек мог выглядеть как новый в e-commerce, как лояльный в приложении и как «неизвестный» в офлайне. В такой схеме segmentation (сегментация) и персонализация работают с погрешностью, а отчётность по кампаниям остаётся спорной.
Задача была не «собрать все данные ради красоты», а создать единый профиль клиента и связать его с действиями: покупка, возврат, визит в приложение, отклик на сообщение, повторный заказ. Для этого Nike пошёл по пути CDP (Customer Data Platform — платформа клиентских данных) и нормализации событий. Ключевой шаг — не просто загрузка источников, а единая схема идентификации: email, телефон, device ID, membership ID. Это позволило склеивать путь одного клиента между каналами.
Решение строилось по полочкам:
— сначала внедрили сбор событий в серверном контуре, чтобы уменьшить потери из-за cookie-ограничений;
— затем очистили и унифицировали справочники, чтобы не плодить дубли профилей;
— после этого настроили триггеры: брошенный просмотр, повторный визит, покупка из нужной категории, падение частоты заказов;
— отдельно связали CDP с медиа и CRM, чтобы считать не только клики, но и вклад в повторную выручку.
Что получили? В публичных материалах Nike и отраслевых разборов регулярно звучит одна и та же логика: после объединения данных бренд сильнее опирался на first-party data (данные первого лица) и смог точнее работать с лояльностью и персональными рекомендациями. Для такого масштаба даже **+1–2 п.п. к repeat rate** и снижение дублей в базе дают заметный эффект на выручку. Главное — маркетинг начинает управлять не трафиком, а поведением клиента.
Урок для marketing ops простой: CDP внедряют не «для единой базы», а чтобы связать данные с действием. Если после интеграции у вас нет новых сценариев, новых триггеров и более честной атрибуции, это не CDP, а дорогой склад данных.
В 2026 году у маркетинга всё меньше шансов выиграть только за счёт охвата. В e-com и D2C средний чек проседает, пользователи экономят, а last-click всё хуже объясняет выручку. Для брендов уровня Nike это особенно чувствительно: если клиент купил кроссовки один раз, дальше важно не «догонять» его рекламой, а понимать, что именно увеличивает повторную покупку и LTV.
Контекст у Nike был типичный для крупного омниканального бренда: сайт, приложение, офлайн-магазины, подписки, CRM, медиа-кабинеты — данные жили отдельно. Из-за этого маркетинг видел только фрагменты пути клиента. Один и тот же человек мог выглядеть как новый в e-commerce, как лояльный в приложении и как «неизвестный» в офлайне. В такой схеме segmentation (сегментация) и персонализация работают с погрешностью, а отчётность по кампаниям остаётся спорной.
Задача была не «собрать все данные ради красоты», а создать единый профиль клиента и связать его с действиями: покупка, возврат, визит в приложение, отклик на сообщение, повторный заказ. Для этого Nike пошёл по пути CDP (Customer Data Platform — платформа клиентских данных) и нормализации событий. Ключевой шаг — не просто загрузка источников, а единая схема идентификации: email, телефон, device ID, membership ID. Это позволило склеивать путь одного клиента между каналами.
Решение строилось по полочкам:
— сначала внедрили сбор событий в серверном контуре, чтобы уменьшить потери из-за cookie-ограничений;
— затем очистили и унифицировали справочники, чтобы не плодить дубли профилей;
— после этого настроили триггеры: брошенный просмотр, повторный визит, покупка из нужной категории, падение частоты заказов;
— отдельно связали CDP с медиа и CRM, чтобы считать не только клики, но и вклад в повторную выручку.
Что получили? В публичных материалах Nike и отраслевых разборов регулярно звучит одна и та же логика: после объединения данных бренд сильнее опирался на first-party data (данные первого лица) и смог точнее работать с лояльностью и персональными рекомендациями. Для такого масштаба даже **+1–2 п.п. к repeat rate** и снижение дублей в базе дают заметный эффект на выручку. Главное — маркетинг начинает управлять не трафиком, а поведением клиента.
Урок для marketing ops простой: CDP внедряют не «для единой базы», а чтобы связать данные с действием. Если после интеграции у вас нет новых сценариев, новых триггеров и более честной атрибуции, это не CDP, а дорогой склад данных.
Как за неделю собрать минимальный CDP-слой для email, CRM и сайта
Если у вас разрознены CRM, сайт и рассылки, не начинайте с «внедрения CDP». Начните с одного сценария, который даст бизнесу измеримый эффект: например, единый профиль для триггерных писем и ретаргетинга.
План на 5 шагов:
— Зафиксируйте 3 источника данных: сайт, CRM и email-платформу. Не добавляйте лишнее, пока не стабилизируете базу.
— Определите 10–15 полей в единой модели профиля: user_id, email, телефон, согласия, первый визит, последний визит, источник, статус лида, покупки, категории интереса. Если поле не влияет на сегмент или триггер — уберите его.
— Опишите правила склейки идентичностей. Минимум: email как основной ключ, телефон как резервный, device_id для анонимного поведения до авторизации. Сразу решите, что делать при конфликте значений: какой источник главный для каждого поля.
— Соберите один поток событий: просмотр товара, добавление в корзину, отправка формы, покупка, отказ от подписки. Для каждого события задайте обязательные параметры: time, user_id, source, campaign, product_id, value.
— Проверьте два use case: 1) триггер на брошенную корзину, 2) сегмент «вернулся на сайт, но не купил за 7 дней». Если оба сценария работают одинаково в CRM и email — базовый CDP-слой готов.
Что важно не пропустить:
— согласия и сроки хранения;
— журнал изменений схемы данных;
— единый справочник источников трафика;
— контроль дублей профилей.
**Хороший CDP-проект на старте — это не платформа, а дисциплина данных.** Если этот слой собрать за неделю, дальше проще считать LTV, строить retention-сегменты и уходить от last-click к более честной атрибуции.
@AdOpsRoom разбирают это с практической стороны
Если у вас разрознены CRM, сайт и рассылки, не начинайте с «внедрения CDP». Начните с одного сценария, который даст бизнесу измеримый эффект: например, единый профиль для триггерных писем и ретаргетинга.
План на 5 шагов:
— Зафиксируйте 3 источника данных: сайт, CRM и email-платформу. Не добавляйте лишнее, пока не стабилизируете базу.
— Определите 10–15 полей в единой модели профиля: user_id, email, телефон, согласия, первый визит, последний визит, источник, статус лида, покупки, категории интереса. Если поле не влияет на сегмент или триггер — уберите его.
— Опишите правила склейки идентичностей. Минимум: email как основной ключ, телефон как резервный, device_id для анонимного поведения до авторизации. Сразу решите, что делать при конфликте значений: какой источник главный для каждого поля.
— Соберите один поток событий: просмотр товара, добавление в корзину, отправка формы, покупка, отказ от подписки. Для каждого события задайте обязательные параметры: time, user_id, source, campaign, product_id, value.
— Проверьте два use case: 1) триггер на брошенную корзину, 2) сегмент «вернулся на сайт, но не купил за 7 дней». Если оба сценария работают одинаково в CRM и email — базовый CDP-слой готов.
Что важно не пропустить:
— согласия и сроки хранения;
— журнал изменений схемы данных;
— единый справочник источников трафика;
— контроль дублей профилей.
**Хороший CDP-проект на старте — это не платформа, а дисциплина данных.** Если этот слой собрать за неделю, дальше проще считать LTV, строить retention-сегменты и уходить от last-click к более честной атрибуции.
@AdOpsRoom разбирают это с практической стороны
Как Nike собрал клиентские данные в одну систему и перестал терять аудиторию между каналами
У Nike был типичный для крупного ритейла разрыв: сайт, приложение, e-mail, офлайн-точки и рекламные кабинеты жили отдельно. Для маркетинг-ops это означало простую боль: один и тот же человек мог выглядеть как 3–4 разных контакта, а сценарии коммуникации не собирались в единую цепочку. В эпоху, где last-click уже не даёт полной картины, это бьёт и по атрибуции, и по retention (удержанию).
Задача была не «собрать больше данных», а построить единый профиль клиента и научиться использовать его в кампаниях и сервисе. Иначе говоря, вывести клиентские данные из отчётов в рабочие процессы.
Решение Nike строил вокруг CDP: подключили источники транзакций, поведения на сайте и в приложении, историю взаимодействий с программой лояльности и сервисными контактами. Ключевой шаг — нормализация идентификаторов. Не по имени и почте, а через склейку событий по устойчивым ключам: аккаунт, device ID, история покупок, поведенческие сигналы. Это позволило собирать не «контакты», а **единые профили**.
Что это дало на практике:
— сегменты стали строиться не раз в месяц, а почти в реальном времени;
— триггерные цепочки начали учитывать не только покупку, но и отказ от корзины, частоту визитов, категорию интереса;
— маркетинг и CRM перестали спорить о том, «чей» клиент, потому что у всех был один источник правды;
— в аналитике стало проще считать вклад каналов не по последнему клику, а по цепочке касаний.
Публично Nike не раскрывает весь стек и цифры внедрения CDP, но сам эффект для такой архитектуры понятен: меньше дублей, точнее сегментация, быстрее запуск сценариев, выше доля возвращающихся клиентов. Для бренда с огромной базой даже небольшое улучшение в активации даёт заметный прирост в выручке на уровне миллионов контактов.
**Урок для маркетинг-ops простой:** CDP не покупают ради «единого хранилища». Его внедряют, когда нужно связать данные с действиями. Если профиль клиента нельзя использовать в триггере, сегменте или отчёте по выручке, это ещё не CDP, а просто дорогая база.
У Nike был типичный для крупного ритейла разрыв: сайт, приложение, e-mail, офлайн-точки и рекламные кабинеты жили отдельно. Для маркетинг-ops это означало простую боль: один и тот же человек мог выглядеть как 3–4 разных контакта, а сценарии коммуникации не собирались в единую цепочку. В эпоху, где last-click уже не даёт полной картины, это бьёт и по атрибуции, и по retention (удержанию).
Задача была не «собрать больше данных», а построить единый профиль клиента и научиться использовать его в кампаниях и сервисе. Иначе говоря, вывести клиентские данные из отчётов в рабочие процессы.
Решение Nike строил вокруг CDP: подключили источники транзакций, поведения на сайте и в приложении, историю взаимодействий с программой лояльности и сервисными контактами. Ключевой шаг — нормализация идентификаторов. Не по имени и почте, а через склейку событий по устойчивым ключам: аккаунт, device ID, история покупок, поведенческие сигналы. Это позволило собирать не «контакты», а **единые профили**.
Что это дало на практике:
— сегменты стали строиться не раз в месяц, а почти в реальном времени;
— триггерные цепочки начали учитывать не только покупку, но и отказ от корзины, частоту визитов, категорию интереса;
— маркетинг и CRM перестали спорить о том, «чей» клиент, потому что у всех был один источник правды;
— в аналитике стало проще считать вклад каналов не по последнему клику, а по цепочке касаний.
Публично Nike не раскрывает весь стек и цифры внедрения CDP, но сам эффект для такой архитектуры понятен: меньше дублей, точнее сегментация, быстрее запуск сценариев, выше доля возвращающихся клиентов. Для бренда с огромной базой даже небольшое улучшение в активации даёт заметный прирост в выручке на уровне миллионов контактов.
**Урок для маркетинг-ops простой:** CDP не покупают ради «единого хранилища». Его внедряют, когда нужно связать данные с действиями. Если профиль клиента нельзя использовать в триггере, сегменте или отчёте по выручке, это ещё не CDP, а просто дорогая база.
Как Aviasales собрал единый профиль клиента и сократил разрозненную коммуникацию
У Aviasales был типичный для крупного продукта набор проблем: данные жили в разных системах, email-цепочки и пуши часто дублировали друг друга, а в аналитике один и тот же пользователь мог выглядеть как три разных контакта. Для marketing ops это означает простую вещь: вы тратите бюджет не на рост, а на борьбу с шумом.
Задача была не «поставить CDP ради CDP», а собрать единый профиль клиента и связать его с триггерными сценариями. Важно было не только узнать, кто пользователь, но и понять, на каком этапе он находится: искал билет, вернулся после ухода, купил или уже давно не открывает приложение.
Решение строили вокруг customer data platform, которая сводила события из сайта, приложения, CRM и рассылок в одну сущность. Дальше включили нормализацию идентификаторов: почта, телефон, device ID, cookie — всё приводилось к единому профилю. На базе этого профиля пересобрали коммуникации:
— убрали пересечение сценариев между каналами;
— настроили частотные ограничения, чтобы человек не получал 4 сообщения за сутки;
— разделили аудитории по намерению, а не только по факту визита;
— добавили триггеры на брошенный поиск, возврат после паузы и повторную покупку.
**Ключевой эффект CDP здесь не в «сборе данных», а в управлении разницей между событием и действием.** Когда система понимает, что пользователь уже купил билет, она перестаёт давить его скидками на тот же маршрут и переводит коммуникацию в следующий сценарий.
Результат в таких внедрениях обычно меряют не абстрактной «цифровизацией», а операционными метриками:
— снижается дублирование касаний;
— растёт доля релевантных сообщений;
— уменьшается отток из-за спама;
— улучшается конверсия из триггерных цепочек в покупку или возврат.
Для эпохи 2026 это особенно важно. На фоне privacy-first атрибуции и ослабления last-click нельзя опираться только на финальное касание. Нужна связка CDP, server-side-сбора и честной оценки инкрементальности, иначе маркетинг видит не вклад, а удобную иллюзию.
Урок простой: CDP окупается не тогда, когда «данные наконец-то собрали», а когда маркетинг перестаёт стрелять по всей базе и начинает работать с жизненным циклом клиента как с системой.
У Aviasales был типичный для крупного продукта набор проблем: данные жили в разных системах, email-цепочки и пуши часто дублировали друг друга, а в аналитике один и тот же пользователь мог выглядеть как три разных контакта. Для marketing ops это означает простую вещь: вы тратите бюджет не на рост, а на борьбу с шумом.
Задача была не «поставить CDP ради CDP», а собрать единый профиль клиента и связать его с триггерными сценариями. Важно было не только узнать, кто пользователь, но и понять, на каком этапе он находится: искал билет, вернулся после ухода, купил или уже давно не открывает приложение.
Решение строили вокруг customer data platform, которая сводила события из сайта, приложения, CRM и рассылок в одну сущность. Дальше включили нормализацию идентификаторов: почта, телефон, device ID, cookie — всё приводилось к единому профилю. На базе этого профиля пересобрали коммуникации:
— убрали пересечение сценариев между каналами;
— настроили частотные ограничения, чтобы человек не получал 4 сообщения за сутки;
— разделили аудитории по намерению, а не только по факту визита;
— добавили триггеры на брошенный поиск, возврат после паузы и повторную покупку.
**Ключевой эффект CDP здесь не в «сборе данных», а в управлении разницей между событием и действием.** Когда система понимает, что пользователь уже купил билет, она перестаёт давить его скидками на тот же маршрут и переводит коммуникацию в следующий сценарий.
Результат в таких внедрениях обычно меряют не абстрактной «цифровизацией», а операционными метриками:
— снижается дублирование касаний;
— растёт доля релевантных сообщений;
— уменьшается отток из-за спама;
— улучшается конверсия из триггерных цепочек в покупку или возврат.
Для эпохи 2026 это особенно важно. На фоне privacy-first атрибуции и ослабления last-click нельзя опираться только на финальное касание. Нужна связка CDP, server-side-сбора и честной оценки инкрементальности, иначе маркетинг видит не вклад, а удобную иллюзию.
Урок простой: CDP окупается не тогда, когда «данные наконец-то собрали», а когда маркетинг перестаёт стрелять по всей базе и начинает работать с жизненным циклом клиента как с системой.