Customer Data Platform: дизайн с нуля

Действуй как data platform architect, который уже строил CDP в B2C на десятки миллионов пользователей. Спроектируй CDP с нуля.

Контекст:

• Объём: {{volume}}
• Use cases: {{use_cases}}
• Подход: {{buy_vs_build}}

Шаг 1. Когда вам реально нужен CDP

CDP заполняет gap между:

• CRM (sales-centric, manual records, slow updates) — знает про deals, не про поведение
• DWH / Warehouse (analytical, batch, не для активации в real-time) — знает всё, но read-only для маркетинга
• Product DB (transactional, no marketing context) — знает заказы, не знает кампании

CDP нужен, если хотя бы 2 из 3:

• Маркетинг руками копирует CSV из BI в инструменты активации (email, ads, push)
• Identity размазана: один user — 5 анонимных id в analytics, 1 email в CRM, 1 device id в push, склейки нет
• Personalization упирается в "не знаем что человек делал на сайте за пределами last_session"

Если только один — попробуй reverse ETL поверх warehouse (Hightouch/Census), не разворачивай полный CDP.

Шаг 2. Пять строительных блоков

1. Ingestion — SDK (web/iOS/Android/server), webhooks от tools (Stripe/Shopify/Intercom), batch import из warehouse
2. Identity resolution — склейка anonymous_id → user_id → email/phone/device
3. Storage — event log (append-only) + user profiles (snapshot) + computed traits (derived)
4. Activation — sync в destinations (email/ads/push/CS) по событию или сегменту
5. Governance — PII vault, consent flags, audit trail, RBAC

Нарисуй каждый блок с inputs/outputs и SLA (latency, freshness, throughput).

Шаг 3. Identity resolution — самая сложная часть

Deterministic (точная склейка):

• anonymous_id + login event → user_id (известный момент склейки)
• email match → merge profiles
• device_id + login → device → user binding

Probabilistic (вероятностная, использовать с осторожностью):

• IP + user agent + behaviour pattern — для cross-device без логина
• Confidence score обязательно, не сливать профили при <0.95

Golden record:

• Какие поля побеждают при конфликте? (last-write-wins / source priority / manual review)
• Email из Stripe важнее email из form submit? (обычно да — Stripe verified)
• Конфликт = очередь на ручной разбор, а не silent merge

Anti-merge кейсы:

• Shared device (семья на одном iPad) — не сливать по device_id одному
• Email change → старый профиль архивируется, не удаляется

Шаг 4. Schema design

Events (immutable, append-only):

• Тонкая taxonomy: 30-50 event types max, не 500
• Naming: object_action (product_viewed, checkout_started)
• Properties: typed, документированы в schema registry
• Versioning: v field, не ломай старое

Profiles (mutable snapshot):

• Identifiers (user_id, emails[], phones[], device_ids[])
• Demographics (consent-gated)
• Last-N-events для быстрого доступа

Computed traits (derived, recompute on event):

• ltv_90d, days_since_last_purchase, predicted_churn
• Считай в стриминге (Flink/ksqlDB) или batch (dbt + scheduled refresh)

Шаг 5. Real-time vs batch trade-offs

Правило: real-time только там, где latency = revenue. Всё остальное — micro-batch (5-15 min) или daily.

Шаг 6. Activation patterns

• Reverse ETL — warehouse → tools (Hightouch/Census), batch, для сегментов
• Server-side webhooks — событие → destination (для real-time triggers)
• Edge API — profile lookup из CDN (для onsite personalization)
• Destinations as code — конфиги синков в git, не в UI

Шаг 7. Governance & compliance

• PII vault — email/phone в отдельной таблице, в events только pseudonym
• Consent management — флаги marketing/analytics/personalization, проверять на каждый sync
• GDPR/CCPA — DSR endpoints (export/delete) за 30 дней, audit trail
• Audit logs — кто, когда, какие данные смотрел/экспортировал
• Data retention — events 25 мес, profiles вечно (но с PII redaction после deletion)

Шаг 8. Buy vs build decision tree

• Объём <100M events/мес, команды <2 data engineers → buy (Segment/RudderStack)
• Нужен полный контроль над identity logic + custom storage → build на Kafka + ClickHouse/Snowflake
• RudderStack open-source = средний путь (self-host, но не с нуля)
• Никогда не buy без spec — иначе vendor решит модель данных за тебя

Output: blueprint document

## CDP Blueprint v0.1

### Use cases (priority)
1. ...

### Architecture (block diagram)
ingestion → identity → storage → activation
                         ↓
                    governance

### Identity strategy
- Deterministic: ...
- Probabilistic: ...
- Conflict resolution: ...

### Schema (top events + profile fields)
...

### Real-time vs batch matrix
...

### Activation map (source → destination)
...

### Governance plan
- PII: ...
- Consent: ...
- Retention: ...

### Buy vs build decision
Choice: ... Reason: ...

### 90-day roadmap
- Month 1: ingestion + identity stub
- Month 2: profile API + первый sync
- Month 3: governance + второй use case

Anti-patterns

• ❌ CDP как "ещё одно хранилище" → дублирование с warehouse, дрифт схем. CDP не source of truth для analytics, а activation layer
• ❌ Identity resolution через email только → теряешь anonymous → known journey, не видишь top-of-funnel behaviour
• ❌ Без governance → PII течёт в инструменты которые не должны её видеть, штрафы GDPR
• ❌ Real-time на всё → x10 cost без impact. Большинство use cases переживут 15-минутный лаг
• ❌ Buy решение без spec → vendor lock-in на их модель данных, миграция через 3 года = переписать половину