Reverse-ETL ломается не в коннекторе, а в схеме и сегментации.

Reverse-ETL ломается не в коннекторе, а в схеме и сегментации.

Reverse-ETL — это не «залить сегмент в CRM». Это доставка уже подготовленных атрибутов из DWH в рабочие системы: email, ads, support, product. Если в warehouse мусор, дубликаты и плавающие ключи, в activation уедет тот же мусор, только быстрее.

Перед запуском проверь 4 вещи:
• один стабильный ключ на сущность: user_id / account_id / order_id;
• правила дедупликации и приоритет полей;
• частоту обновления: кому нужен near-real-time, а кому достаточно батча;
• обратную совместимость: новый столбец не должен ломать старые маппинги.

Самая частая ошибка — тащить в destination сырые таблицы «как есть». В CRM начинают жить NULL вместо значений, в ads-кабинете создаются лишние аудитории, а у sales появляется «актуальный» статус, который конфликтует с support. Reverse-ETL работает только там, где есть слой бизнес-атрибутов, а не просто витрина фактов.

Хорошая практика: сначала описать, какие действия должен запускать каждый атрибут, и только потом строить sync. Если поле не ведёт к триггеру, сегменту или решению, ему не место в активации.