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

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

Reverse ETL нужен, когда данные уже живут в DWH, а маркетингу, sales или CX надо отдавать их обратно в CRM, helpdesk или ads-аккаунты. Проблема обычно не в “доставить”, а в “какую запись считать истиной” и “когда перезаписывать поле”.

Сначала проверьте 3 вещи:
— есть ли стабильный ключ на уровне человека/аккаунта, а не только email;
— не дублируются ли сущности между web, app и CRM;
— можно ли безопасно обновлять поле без затирания ручных правок.

Дальше отделяйте свойства на группы: identity, mutable profile, derived scores. Иначе один плохой батч превращает источник правды в источник хаоса. Для score-полей задавайте TTL или явное правило пересчёта, для contact fields — приоритет источника, для статусов — только одно место, где их меняют.

Самая частая ошибка — пушить в CRM всё подряд. Нужен не “маппинг всех колонок”, а список полей с владельцем, триггером обновления и правилом отката. Если этого нет, reverse ETL быстро превращается в автоматический спам по системам.

Делайте reverse ETL не как трубопровод, а как контракт: кто пишет, что пишет и почему это поле вообще можно менять.