CDP ломается не на выборе вендора, а на грязных событиях и кривом identity graph

CDP ломается не на выборе вендора, а на грязных событиях и кривом identity graph

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

Перед запуском проверьте три вещи:
• единый нейминг событий и свойств, без дублей типа order_paid / purchase_success
• стабильный идентификатор: user_id, а не только cookie или device_id
• правила для anonymous-to-known: когда и как склеивать гостя с профилем

Частая ошибка — пытаться «активировать всё». В итоге в CDP летят сырые клики, техсобытия и бизнес-события в одной каше. Разведите слои: raw events для хранилища, curated events для CDP, а в activation отдавайте только те поля, которые реально нужны маркетингу и саппорту.

Ещё один грабль — отсутствие data contract. Если продукт поменял название свойства, а downstream-команды узнали об этом через сломанный сегмент, значит схемы нет. Нужны владельцы событий, список обязательных полей и проверка на пустые/аномальные значения.

CDP окупается не за счёт количества коннекторов, а когда у вас есть дисциплина в схеме, identity и quality checks.