Reverse-ETL ломается не в SQL, а в трёх местах: кто, что и как часто лить в CRM

Reverse-ETL ломается не в SQL, а в трёх местах: кто, что и как часто лить в CRM

Reverse-ETL — это не “перекинуть сегмент из DWH в HubSpot”. Это слой активации: из warehouse в рекламные кабинеты, CRM, email, support и sales tools. Если схема сырая, вы быстро получаете дубли, грязные сегменты и рассинхрон между источником и тем, что видит маркетинг.

Первый чек: у каждого поля должен быть владелец. Не “в таблице есть first_purchase_date”, а кто его считает, из каких событий, и когда оно считается устаревшим. Второй чек: у сегмента есть правило стабильности. Если пользователь прыгает между группами каждую ночь, downstream-инструменты начинают спамить триггерами и ломать частоту коммуникаций.

Третий чек: готовьте не только аудиторию, но и режим синхронизации. Для CRM часто нужен не полный рефреш, а инкремент + защита от перезаписи ручных полей. Для paid media — отдельные списки по жизненному циклу, иначе вы зальёте в ретаргетинг людей, которых уже надо исключить. И да, любую обратную выгрузку нужно уметь откатить: с логом изменений и понятным ключом матчинга 🔧

Если reverse-ETL не описан как контракт, он превращается в “магический экспорт” и начинает врать бизнесу. Сначала фиксируйте схему, потом правила обновления, потом только подключайте активацию.