Reverse ETL ломается не в API, а в схеме: 5 правил, чтобы не кормить CRM мусором

Reverse ETL ломается не в API, а в схеме: 5 правил, чтобы не кормить CRM мусором

Reverse ETL — это не «залить сегмент в Salesforce», а доставить в CRM уже чистый, пригодный к действию признак. Если в warehouse лежат дубли, пустые поля и конфликтующие ключи, activation быстро превращается в спам-автоматизацию.

Перед синком проверьте базу: один стабильный customer_id; понятные правила дедупликации; timestamp для выбора «последнего» значения; отдельные поля для source_of_truth, если один атрибут приходит из разных систем. Без этого один и тот же клиент может стать тремя разными лидами.

Дальше — фильтры. Не тащите в CRM сырые события, если у них нет бизнес-смысла: «visited_page» мало кому нужен, а «trial_started», «checkout_abandoned», «high_ltv_tier» уже можно использовать. Для каждого поля заранее определите: кто владелец, как часто обновляется и что делать при null.

Ещё одна типовая ошибка — синкать всё подряд в один объект. Разведите справочник профиля, поведенческие теги и транзакционные атрибуты по разным сущностям или таблицам маппинга. Так проще отлаживать, меньше конфликтов в CRM и ниже шанс сломать ручные процессы sales/CS.

Если reverse ETL не отвечает на вопрос «какое действие изменится у команды?», он не нужен. Начинайте с 3–5 полей, которые реально запускают сегмент, задачу или триггер, и только потом расширяйте схему.