Customer data ломается не в BI, а на входе: 5 правил, которые спасают схему

Customer data ломается не в BI, а на входе: 5 правил, которые спасают схему

Если customer data собрать как попало, дальше уже не поможет ни CDP, ни reverse-ETL. Боль обычно одна и та же: событие назвали по-разному в web и app, часть свойств приходит пустой, а user_id живёт отдельно от email и phone. В итоге сегменты кривые, атрибуция шумит, а активация льёт не туда.

• Делайте одну базовую схему событий: просмотр, add_to_cart, checkout, purchase. Не плодите синонимы.
• Для каждого события фиксируйте обязательные поля: user_id, anonymous_id, timestamp, source, device, currency.
• Отдельно храните identity-ключи и не смешивайте их в одном поле.
• Валидируйте типы: цена — число, дата — дата, статус — enum, а не строка “ok”.
• Все кастомные свойства — через список разрешённых полей, иначе зоопарк вернётся через месяц.

Для customer data важнее не объём, а предсказуемость. Если аналитик не может по схеме понять, что придёт в payload, маркетинг не сможет нормально сегментировать аудиторию, а CDP начнёт разносить мусор по CRM и рекламным кабинетам. Это особенно заметно, когда один и тот же человек приходит с web, app и офлайна.

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