CRM и сервис рассылок: как передавать сегменты и сохранять отписки

Почему контакта в CRM недостаточно для рассылки

В документации Unisender состояние адреса и его участие в списках рассылки описаны отдельно. Это исходная точка интеграции: карточка клиента может оставаться в CRM после отписки, а новое имя или телефон в ней не означают, что человек снова подписался на письма.

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

Карточка и подписка решают разные задачи. В нашей конфигурации историю работы с клиентом сохраняют и после его отказа от писем, а дальнейшее участие в отправках определяют по данным о подписке. Компания заранее называет источник этих данных, способ их получения и ответственного, который разбирает спорное состояние. Интегратор переносит согласованные значения, вместо того чтобы назначать всем контактам один статус по факту наличия email.

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

Какие сведения передавать в каждую сторону

У каждой системы своя зона ответственности. Из CRM обычно нужны имя, адрес и признаки выбранного сегмента; обратно — состояние подписки и результат обработки адреса, если выбранное подключение это поддерживает.

В официальном обзоре Битрикс24 описано приложение интеграции с Unisender, которое передаёт контакты и компании, позволяет сопоставлять поля и запускать ручной экспорт выбранной группы. Это полезные возможности, но из такого описания нельзя вывести, что любой установленный коннектор возвращает все отписки. Обратное направление нужно отдельно подтвердить по документации конкретного приложения и показать на испытании. Название сервиса в карточке приложения для этого недостаточно.

Я рекомендую составить короткую карту обмена до выбора коннектора: какие поля меняются в Битрикс24, какие — в рассылочном сервисе, откуда берётся окончательное значение при несовпадении и кто разбирает случай, если автоматически выбрать его невозможно. Альтернатива «обновлять в обе стороны всё подряд» выглядит гибкой, но скрывает конфликт между запоздавшим событием и более новым состоянием. Особенно опасно, когда обычное редактирование фамилии возвращает адрес в рассылку.

Кто отвечает за результат обмена

Для каждого направления нужен владелец. Маркетолог утверждает признаки сегмента. Администратор сервиса отвечает за доступ к сведениям о подписках. Интегратор показывает перенос и обработку ошибок. Руководитель назначает сотрудника, который принимает спорные случаи после запуска. Этот сотрудник сопоставляет сведения двух систем и принимает решение по составу отправки, если значения расходятся и требуется объяснение со стороны маркетолога или интегратора.

Как сопоставлять контакты и изменения email

Связь по имени ненадёжна. Два человека могут называться одинаково, а один клиент — использовать несколько адресов, поэтому правило сопоставления лучше записать до первой массовой передачи.

Метод subscribe в Unisender определяет существующий контакт по email: если передать другой адрес с прежним телефоном, документация описывает создание нового контакта, а не замену почты в старой записи. Из этого следует конкретный вопрос подрядчику: как в выбранном решении обрабатывается смена адреса и что происходит с прежней записью? Ответ нужен на уровне действия и итогового списка, без пересказа устройства API.

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

Тестовые карточки для смены адреса и дублей

Маркетологу удобно подготовить несколько служебных карточек: один адрес в двух контактах, один контакт с двумя адресами и карточку после объединения дублей. Для каждой заранее задают ожидаемое число получателей и то, какой адрес попадёт в следующую отправку. Эти данные принадлежат команде и используются только для приёмки. Массовую очистку реальной базы лучше выделить в самостоятельную работу: иначе ошибки сопоставления смешаются с давно накопленными дублями, а результаты испытания будет трудно повторить.

Подробнее о причине и разборе повторных карточек рассказано в материале про дубликаты клиентов в Битрикс24. Для обмена полезно знать, какая запись относится к человеку и какие адреса он использует.

Чем сегмент отличается от списка подписчиков

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

В задании я разделяю два действия: обновить сведения о человеке и изменить его участие в конкретной группе. Маркетолог описывает условия входа и выхода обычными словами, затем исполнитель переводит их в поля и события. Например, в конфигурации этой статьи сегмент строится по выбранной продуктовой теме и действующему статусу подписки; признак продуктовой темы не подменяет сведения о подписке. Такое описание легче принять, чем формулу с названиями внутренних полей, смысл которой понятен только разработчику.

Что меняет повторная передача

У метода subscribe режим 0 сохраняет существующие поля и добавляет новые; режим 1 заменяет прежние поля и метки, оставляя контакт только в переданных списках; режим 2 обновляет переданные поля, сохраняя остальные. Для меток у режима 2 отдельное правило: переданные заменяют прежние, а при отсутствии меток в запросе сохраняются старые. Настройку выбирает интегратор. Я прошу показать её результат на тесте: имя изменилось, а соседние списки и признаки, которых текущая задача не касается, сохранились в согласованном состоянии.

Сверка текущего состава

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

Что делать с отписками и недоступными адресами

Метод getContact в Unisender отдельно возвращает общее состояние email и его состояние в списках. В числе глобальных значений есть ожидание подтверждения, активный адрес, отписка от всех рассылок и блокировка. Отдельно возвращается доступность почтового ящика, включая временную недоступность и переполнение. Это разные причины исключения: человек может не хотеть письма, а может хотеть, но временно не принимать их из-за состояния ящика.

Я рекомендую хранить причину ограничения вместе с её источником и временем получения. Альтернатива — единая галочка «не отправлять» — быстрее в настройке, но не позволяет отличить отказ от временной ошибки доставки. Без причины ответственный может принять отказ за временную ошибку, особенно если коллега сообщает, что с этим клиентом недавно разговаривали по телефону и адрес в карточке выглядит правильным. Если у компании несколько тем, ограничение сохраняют с указанием списка, к которому оно относится, а полный отказ от писем фиксируют отдельно, чтобы одно значение не заменяло разные решения адресата. Даже если интерфейс CRM показывает короткий статус, подробности остаются в истории, доступной ответственному.

Повторное включение и восстановление карточки

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

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

Как принять обмен до первой рабочей кампании

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

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

Результат в CRM и сервисе рассылок

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

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