Reverse ETL ломается не в коннекторе, а в схеме и ключах склейки

Reverse ETL ломается не в коннекторе, а в схеме и ключах склейки

Reverse ETL — это не «залить сегменты в CRM», а дисциплина про source of truth. Если в warehouse нет стабильного customer_id, если email меняется чаще, чем статус заказа, а события размазаны по разным таблицам, синхронизация начнёт плодить дубликаты и мусорные аудитории.

Перед запуском проверь 4 вещи:
— один главный ключ для записи клиента и отдельный mapping для email/phone;
— явный приоритет полей: что перезаписывает CRM, а что только дополняет;
— правила дедупликации до активации, а не после;
— ограничение на «грязные» атрибуты: null, пустые строки, тестовые домены, временные телефоны.

Частая ошибка — отправлять в CRM всё подряд. Тогда менеджеры видят разные версии одного клиента, триггеры стреляют повторно, а исключения не работают. Лучше начать с 2–3 полей и одной бизнес-задачи: реактивация, брошенная корзина, post-purchase upsell.

Ещё один грабельный момент — частота. Если reverse ETL синкает слишком часто, вы ловите гонки данных: заказ уже отменён, а сегмент ещё «в покупке». Поэтому сначала фиксируйте SLA между warehouse и CRM, потом наращивайте сценарии. Иначе activation превращается в рандом.

Начинайте с маленькой, но чистой схемы: один ключ, один владелец поля, один понятный use case. Тогда reverse ETL помогает продажам и retention, а не создаёт второй склад ошибок.