Интеграция CRM с сервисом email-рассылок: какие поля синхронизировать и как проверить, что цепочки запускаются без потерь

Рабочая интеграция CRM и рассылок не ограничивается копированием email. Нужно сохранить смысл данных: клиент может иметь несколько сделок, отказаться от писем или ещё не подтвердить подписку. Если все эти состояния заменить флагом «контакт существует», автоматизация начнёт отправлять лишнее и терять нужное.

Ниже — авторский проект связки amoCRM и Unisender. Он объясняет контракт данных и проверки, а не сообщает о фактически подключённых аккаунтах. Конкретные поля, доступность вебхуков и права проверьте в своей конфигурации перед реализацией.

Выберите несколько событий, а не синхронизацию всего подряд

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

Авторский пример: контакт 42 получил памятку и подтвердил подписку; при записи на занятие меняется его дальнейшая цепочка. Сделка и контакт — разные сущности. Если у человека одна сделка завершена покупкой, а другая закрыта без результата, последнее изменение сделки не должно автоматически превращать покупателя обратно в незнакомого подписчика.

В API amoCRM контакт имеет собственный id, дополнительные поля и связанные сущности. Поэтому сначала установите, к какому контакту относится событие сделки, а уже затем вычисляйте нужный маркетинговый статус по согласованному правилу.

Составьте карту полей и владельцев

Данные	Источник истины в примере	Использование
CRM contact.id	amoCRM	Связь с внешним идентификатором и журналом обработки
Выбранный email	Согласованное поле контакта	fields[email] метода subscribe
Имя	Профиль CRM	Соответствующее поле персонализации в рассылке
Интерес и источник подписки	Форма или согласованная запись CRM	Пользовательские поля и метки сегментации
Основание и подтверждение рекламной подписки	Журнал согласий и подтверждений	Допуск к подходящему сценарию
Статус доступности и отписки	Сервис рассылок и запрос самого адресата	Запрет дальнейшей отправки и обратная отметка в CRM
person_id	Ответ Unisender	Таблица соответствий с CRM и диагностика

Пользовательские поля вроде CRM_ID, INTEREST и STAGE — названия вашего проекта, а не готовые универсальные поля обоих продуктов. Создайте их и согласуйте типы заранее. Для нескольких адресов одного контакта определите, какой используется; пустое значение нельзя отправлять как исправление рабочего email.

Unisender идентифицирует контакт по email. По его документации передача другого email при том же телефоне может создать новый контакт, а не изменить адрес существующего. Поэтому CRM id и person_id полезны для связи, но не отменяют правила идентификации сервиса.

Привяжите CRM-сегмент к списку рассылки

У subscribe обязательны list_ids и fields с email. list_ids — коды списков через запятую; их получают методом getLists. Название стадии CRM вместо кода списка не подходит. В авторском проекте маркетолог задаёт таблицу маршрутизации: «интерес к пробному занятию» → список 134, «подтверждённая покупка» → список 135. Числа условные: в рабочем аккаунте подставьте реально полученные коды.

Интеграция вычисляет сегмент по контакту и всем относящимся к нему сделкам, затем выбирает список по таблице. Пример набора параметров для нового адреса: list_ids=134, fields[email]=test@example.org, double_optin=0, overwrite=0. Секрет API передаётся защищённо отдельно; этот набор не является готовым запросом. В этом авторском проекте для ожидающего подтверждения контакта обычную welcome-серию не запускают. После подтверждения проверяют рабочий статус и только тогда разрешают соответствующую автоматизацию.

Добавление в список 135 не означает автоматического удаления из 134 при любом overwrite. Разведите членство в списках и условие запуска цепочки: правило покупки должно выключать прежнюю цепочку, даже если контакт остаётся в её списке. Если нужна именно смена членства, спроектируйте её отдельным действием по API; не включайте overwrite=1 ради этого без учёта всех списков и полей.

Разделите согласие и техническую подписку

Для рекламных сообщений в России действует требование предварительного согласия адресата по статье 18 № 38-ФЗ и прекращения рекламы по его требованию. Запись о сделке или заполненный email сами по себе не означают согласия на маркетинговую серию.

Метод subscribe поддерживает double_optin. При сценарии с запросом подтверждения адрес ещё не получает обычные рассылки: статус «Запрошено подтверждение» отличается от «Новый» и «Активен», которым сервис допускает отправку. Не трактуйте успешный API-ответ как доказательство уже завершённого подтверждения.

В примере welcome начинается после выполнения предусмотренных условий подписки и доступности контакта. Режим добавления без письма подтверждения можно рассматривать только при реально имеющемся основании; это не способ исправить низкую конверсию в согласие.

Обновляйте только управляемые поля

У subscribe есть параметр overwrite с существенными последствиями. Значение 0 добавляет новые поля и метки, сохраняя значения существующих. Значение 1 удаляет старые поля и метки, заменяет их переданными и оставляет контакт только в переданных списках. Это риск для полной выгрузки поверх чужих процессов.

Значение 2 заменяет переданные поля и сохраняет другие поля. Но переданные метки при этом перезаписываются; отсутствие меток сохраняет прежние. Поэтому «частичное обновление» не означает автоматическое объединение любого массива тегов. До запроса рассчитайте конечный набор либо не передавайте метки, которыми интеграция не управляет.

После ответа сохраните result.person_id и результат обработки. Проверяйте JSON и сообщение об ошибке, а не только факт завершившегося HTTP-запроса. Отдельно отмечайте состояния «ожидает подтверждения», «доступен» и «отправка запрещена».

Принимайте вебхуки быстро, выполняйте работу надёжно

amoCRM отправляет вебхуки в формате x-www-form-urlencoded и ожидает ответ не более двух секунд. При неудаче предусмотрены повторные попытки. Не обрабатывайте тело как гарантированный JSON и не выполняйте всю интеграцию синхронно до ответа CRM.

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

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

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

Верните отписку в CRM

Unsubscribe помечает адрес отписавшимся, сохраняя контакт в списках; exclude означает другое действие. Документация прямо предупреждает: вернуть статус отписавшегося на активный через API нельзя, это делает сам контакт через ссылку активации. Старый флаг CRM «разрешено» не должен перезаписать более поздний отказ.

Один из вариантов сверки — async/exportContacts. Можно запросить email_status, contact_status, списки отписки и нужные поля. Сначала API возвращает task_uuid, затем результат получают через уведомление notify_url или async/getTaskResult. Состояние completed и ссылка на файл — следующий этап; ответ с новым заданием ещё не означает готовую выгрузку.

Сопоставьте выгрузку с CRM и обновите собственный запрет отправки. Учитывайте статус адреса и включённость контакта, а не только принадлежность списку. Сохраняйте причину ограничения, чтобы менеджер не пытался «починить» согласие повторным импортом.

Проверьте интеграцию на сценариях

Тест	Что должно быть подтверждено
Новый тестовый адрес	Нужные поля, ожидаемый статус и единственный вход в цепочку после её условий
Точный повтор события	Нет дубля контакта и повторного welcome
Изменение только имени	Другие поля, метки и списки не потеряны
Отписка в сервисе	Запрет вернулся в CRM и не отменён старой записью
Недоступный API	Задача видна, причина сохранена, повтор контролируется
Несколько сделок контакта	Маркетинговый статус вычислен по установленному правилу

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

Готовность связки подтверждает воспроизводимый путь тестового контакта: от исходного события через сохранённый API-результат до нужной цепочки и корректной отписки. Число перенесённых строк без этих проверок ещё не означает, что автоматизация работает.