Как исключать выбывших клиентов через Hightouch

Аналитик собрал в хранилище сегмент «не покупали 90 дней», а Hightouch передал его в платформу рассылок. Через неделю часть людей сделала заказ и исчезла из выборки из хранилища. Однако в рассылочном списке они остались и получили ненужную реактивацию. Добавление новых участников работало, но исключение выбывших не было частью проверенного процесса.

Hightouch помогает передавать данные из хранилища в рабочие сервисы. Такой подход часто называют Reverse ETL: подготовленные данные попадают из аналитической среды обратно в CRM, рекламные кабинеты и другие инструменты. Sync — отдельная настроенная синхронизация между моделью данных и получателем. Модель задаёт выборку, которую нужно передать.

Для корректной аудитории нужно управлять полным циклом членства: появился, изменился, вышел и вернулся. Ниже — тест-план CRM Lab, который помогает проверить этот цикл до массового запуска.

Разделите профиль и участие в сегменте

Профиль клиента и его членство в списке — разные сущности. Если человек перестал соответствовать условию реактивации, обычно нужно убрать его из этой аудитории, сохранив покупки и другие полезные данные. Удаление профиля целиком может затронуть несвязанные сценарии.

Hightouch различает тип синхронизируемых данных и режим записи. Доступные сочетания зависят от системы назначения: это могут быть объекты, события или участие в аудиториях. Режим Insert добавляет новые строки, Update обновляет существующие, Upsert сочетает оба действия. Обработка исчезнувших строк настраивается отдельно. [1]

Поэтому сначала определите объект действия: атрибут профиля, принадлежность к конкретному списку или отдельное событие. Затем откройте документацию именно нужного коннектора и проверьте, что он умеет делать при выходе строки из модели. Общая поддержка сервиса в каталоге ещё не подтверждает нужную операцию.

Установите устойчивый ключ модели

Primary key — поле или сочетание полей, по которому различаются строки модели. Для списка клиентов обычно нужен постоянный клиентский ID, сопоставимый с системой назначения. В результатах модели не должно быть двух строк с одним ключом и разным смыслом.

Если вместо одного клиента запрос возвращает строку на каждую покупку, сначала приведите модель к нужному уровню. Иначе изменение числа заказов способно выглядеть как изменение числа участников. Смена email тоже не должна без необходимости превращать прежнего клиента в нового.

Сверьте ключ модели с полем сопоставления в получателе. Устойчивый customer_id в хранилище бесполезен, если коннектор ищет запись по другому идентификатору, который отсутствует или неоднозначен. Проверка готовой интеграции включает эту пару полей, а не только успешное подключение.

Проверьте обработку исчезнувшей строки

CDC, или change data capture, в этом контексте означает обнаружение добавленных, изменённых и исчезнувших строк между результатами запусков. Но обнаружить выход строки и удалить человека из нужного списка — разные этапы. Действие определяют настройки синхронизации и возможности получателя. [1]

Условный пример. В первом запуске сегмент содержит клиентов A, B и C. Во втором B сделал покупку, C отписался, а D достиг порога неактивности. Бизнес ожидает список A и D. При этом покупка B должна сохраниться в профиле, а запрет C — распространиться на маркетинговые коммуникации по отдельному правилу.

Не используйте отсутствие человека в одном коммерческом сегменте как основание глобальной отписки. И наоборот: удаление отписавшегося только из одного списка не заменяет единый запрет рассылок.

Защититесь от ошибочно пустого результата

SQL-запрос может успешно выполниться и вернуть ноль строк из-за неполной загрузки источника. Если синхронизация интерпретирует это как реальный выход всех участников, ошибка качества данных превратится в массовое изменение CRM.

Задайте проверки свежести таблиц, ожидаемого масштаба аудитории и доли исключений. Если объём резко отличается от обычного, приостановите применение изменений предусмотренным в проекте способом и выясните причину. Где реализовать барьер — в подготовке модели, оркестраторе или доступных средствах платформы — определяет архитектура проекта.

Резкое уменьшение сегмента бывает корректным, например после завершения акции. Поэтому барьер должен предусматривать подтверждённое исключение с причиной и владельцем. Постоянно отключённая проверка не защищает данные.

Осторожно восстанавливайте синхронизацию

Полный повторный запуск и сброс истории CDC не равнозначны обычной повторной попытке. Hightouch предупреждает, что full resync снова обрабатывает текущие строки как добавленные и игнорирует исчезнувшие строки даже при включённой настройке удаления. Команда Clear and fill сначала очищает выбранный список или аудиторию, затем заполняет её текущими строками модели. Эта операция доступна только для поддерживаемых направлений синхронизации. [2]

Перед восстановлением сохраните ожидаемый состав и текущее состояние получателя. Проверьте, не повторятся ли бизнес-события и не появятся ли дубли. Ошибки отдельных строк разбирайте отдельно: общая успешность запуска не доказывает, что каждый адресат обновился. Документация Hightouch описывает повторную обработку отклонённых записей, но исправление невалидных исходных данных остаётся необходимым. [3]

Завершайте приёмку сверкой множества идентификаторов, а не только числа строк. Два списка по тысяче человек могут содержать разных людей. После каждого теста должны быть объяснимы добавления, изменения, исключения и отклонённые записи. Тогда синхронизация действительно поддерживает актуальную аудиторию, а не просто регулярно отправляет данные.

Источники

1. Hightouch. Sync types and modes. Hightouch Docs. Проверено 23.09.2026.

2. Hightouch. Resync, reset CDC, or clear and fill. Hightouch Docs. Проверено 23.09.2026.

3. Hightouch. Retry strategy. Hightouch Docs. Проверено 23.09.2026.