Обединени клиентски профили

Проблемът: един клиент, много записа

В типичен marketing stack един клиент на име Alice съществува като:

• 1 CRM контакт (по имейл)
• 1 Email tool абонат (по имейл)
• 1-3 анонимни CDP сесии (преди да се регистрира)
• 1 identified CDP профил (след регистрация)
• 1 support ticket (по имейл, отделна система)

Това са 5-7 записа за 1 реален човек. Всяка система има частични данни. Cross-referencing-ът е ръчен.

Какво прави Monfri

Monfri поддържа един профил на реален човек през всичките 4 услуги (CRM, Push, CDP, Automation). Всяко действие — CRM бележка, email отваряне, web event, push клик — се прикача към същия базов профил.

Identity resolution — как работи merging-ът

1. Детерминистичен merge (най-силен, 99%+ увереност)

Същият имейл = същият човек. Същият user_id = същият човек. Това са изрични идентификатори, които потребителят е предоставил.

2. Anonymous-to-identified свързване

Когато потребител се регистрира, гледаме анонимния му session ID (tracked чрез persistent cookie) и мержваме цялата pre-signup активност в новия authenticated профил. Нулева загуба на данни.

3. Cross-device свързване за authenticated потребители

Alice влиза от лаптоп И телефон. Двете device активности се сливат в един профил чрез user_id.

4. Confidence-scored вероятностен merge

За анонимни потребители през устройства оценяваме confidence на база: device fingerprint корелация, session timing, geolocation близост, referral път. Merge-ове се изпълняват при confidence > 85%. Можеш да настроиш прага или да изключиш вероятностния merging изцяло.

5. Manual merge UI

За edge case-ове (typo в имейл, потребителят има два генуинно отделни акаунта, които иска да обедини), admin-ите могат да мержват профили ръчно. Пълен audit trail.

Типове идентификатори, които обработваме

• Email адрес (primary + aliases)
• User ID (от auth системата ти)
• Anonymous ID (cookie-based)
• Device fingerprint (browser + device комбинация, hashed)
• Phone number (hashed)
• External ID (твоят вътрешен идентификатор от други системи)
• Push subscription endpoint

Всички идентификатори се съхраняват като SHA256 hashes. Никога не запазваме сурови phone/email отвъд активни операции.

Какво отключва обединен профил

Cross-channel сегментиране

Строй audiences като "посетил pricing страницата И отворил последния имейл И има отворена сделка И не е влизал от 14 дни" — един query, real-time.

Точна атрибуция

Всеки touchpoint е на един timeline. Можеш да отговориш "кои кампании доведоха до тази сделка" с увереност.

Suppression логика, която работи

"Не пращай abandoned cart имейл ако вече са купили" — работи, защото purchase event е на същия профил.

Персонализация през канали

Имейл казва "Здравей Alice, продължи настройката" с контекст от последната й product сесия. Push известие казва същото. Без stale данни.

Merge история и audit

Всеки profile merge се логва с:

• Source profile ID-та (какво е мержнато)
• Survive-нат profile ID (какво остава)
• Merge сигнали (какво е задействало merge-а)
• Timestamp и admin (ако е ръчно)

Merge-овете са reversible за 30 дни. Ако нашето confidence scoring е сгрешило, можеш да unmerge-неш през admin UI.