API для CRM-маркетолога: что нужно знать для работы с интеграциями

API встречается во многих задачах CRM-маркетинга. С его помощью сайт может автоматически передавать данные о заказе в CDP, обновлять данные клиента в CRM или запускать рассылку после покупки.

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

Разберемся на примерах и без кода.

API помогает системам обмениваться данными

Представим интернет-магазин. Клиент оформил заказ на сайте. Информация о покупке нужна сразу нескольким системам: CRM-система должна сохранить заказ, а сервис рассылок — отправить письмо клиенту.

Можно переносить данные вручную: менеджер  откроет CRM, создаст заказ, укажет клиента, сумму и товары. Но если заказов сотни в день, такой подход не работает.

Поэтому обмен между системами автоматизируют. Один из способов — API.

API позволяет одной системе обратиться к другой: передать данные, запросить информацию или попросить выполнить действие. Это обращение называется API-запрос.

Когда клиент завершает покупку в интернет-магазине, сайт отправляет API-запрос в CRM. Если перевести его с языка программ на обычный, получится примерно так:

Создай новый заказ. Его сумма — 7 000 ₽. Вот покупатель и список товаров.

CRM получает запрос и выполняет указанное действие — создает заказ с переданными данными.

Но через API не всегда можно передать любые данные.

Каждый сервис сам определяет, какие действия доступны через его API и какие данные он может принимать.

Например, сервис может позволить сообщить о брошенной оплате, но не принимать список товаров. Или принимать название товара, но не его цену.

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

Передать данные через API и использовать их — не одно и то же

Теперь представим, что данные о заказе нужно передать еще и в сервис рассылок. Маркетолог хочет для покупок дороже 5 000 ₽ запускать отдельную ветку сценария, а в письме показывать товары из заказа.

Для такой механики нужны данные о сумме и составе заказа. Сначала нужно проверить, позволяет ли API сервиса их передать.

Допустим, позволяет. Но значит ли это, что сценарий получится настроить именно так?

Не обязательно.

Сервис может получить сумму заказа, но не позволить использовать ее для ветвления сценария. Тогда настроить условие «если сумма больше 5 000 ₽ → запустить отдельную ветку» не получится.

То же самое с товарами. Сервис может получить и сохранить список покупок, но не позволить автоматически показать эти товары в письме.

Поэтому важно проверить: 

а) можно ли передать нужные данные в сервис через API?

б) можно ли использовать полученные данные для нужной задачи?

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

Это различие особенно важно при оценке сервисов. Фраза «данные можно передавать через API» сама по себе еще не означает, что на них получится построить нужную маркетинговую механику.

Как грамотно поставить задачу разработчику

Чтобы настроить интеграцию, недостаточно сказать разработчику: «Нам нужно передавать заказы по API». Из такой формулировки непонятно, какой результат должен получиться.

Лучше начать с маркетинговой задачи.

Например:

После первой покупки отправляем клиенту письмо с благодарностью. Если сумма заказа больше 5 000 ₽, запускаем отдельную ветку сценария. В письме показываем товары из заказа.

Из такого описания разработчик поймет, что должна делать интеграция, и сможет определить, какие данные для этого понадобятся и можно ли получить и передать их через API.

Поэтому маркетологу важно описать две вещи.

Что должно происходить и при каких условиях?

Вместо «после покупки запускаем сценарий», конкретизируем: «после первой покупки отправляем письмо, а для заказов дороже 5 000 ₽ запускаем отдельную ветку».

Какие данные нужно использовать?

Например, сумму заказа нужно проверить перед выбором ветки, а купленные товары — автоматически показать в письме.

Маркетологу при этому необязательно самому определять, какие поля должны быть в API-запросе и как технически передать данные. Это можно решить вместе с разработчиком.

Главное — понятно описать желаемый результат. Тогда разработчик сможет проверить техническую сторону.

Новый редактор сценариев Unisender: сыро или уже можно пользоваться? 

Unisender представил новый редактор сценариев. Старый редактор цепочек был довольно ограничен — например, автоматизацию можно было запустить только после подписки, добавления контакта в список или присвоения тега.

Теперь запуск автоматизации также доступен через API, сегмент или событие, а email, Telegram и MAX можно объединить в одном сценарии.

Лаборатория Bonfire протестировала новые возможности на рабочих задачах и узнала, что стало удобнее, а где пока есть ограничения.

API-триггер: меньше лишних действий, но не хватает гибкости

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

С API-триггером промежуточный шаг больше не нужен: внешняя система может сразу передать контакт в нужный сценарий.

Вместе с контактом можно передать и другую информацию, например, сумму заказа или список товаров, а затем добавить ее в письмо.

Но использовать эту информацию в условиях сценария, как оказалось, пока нельзя. 

Например, зная сумму заказа, не получится разделить сценарий на две ветки:

  • если сумма заказа больше 5 000 ₽ отправлять письмо А;
  • если сумма заказа до 5 000 ₽ отправлять письмо Б.

На практике это ограничивает персонализацию и гибкость сценария. 

В редакторе есть еще один инструмент — блок «API-запрос». С его помощью прямо из сценария можно отправить данные во внешнюю систему или запросить информацию у нее.

Здесь мы обнаружили расхождение с документацией. В ней указано, что ответ API-запроса можно использовать в условиях. Но в самом блоке «Условие» такой возможности пока нет.

API-триггер упростил запуск сценариев из CRM и других систем. Но работать с полученной информацией внутри сценария пока можно не везде.

Запуск сценария по сегменту: подойдет для сценариев без жестких сроков

Сначала маркетолог создает сегмент и задает условия, по которым в него попадают контакты: например, город или дату покупки. Когда контакт начинает соответствовать этим условиям, для него запускается сценарий.

Но и тут есть одно «но». 

Unisender проверяет сегменты только раз в сутки. Поэтому между попаданием контакта в сегмент и запуском сценария может пройти до 24 часов.

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

Больше всего вопросов у нас вызвал Менеджер событий

Он передает в Unisender события — любые действия клиента на сайте или в другой системе. Это может быть просмотр товара, оформление заказа или брошенная корзина. 

По событиям можно запускать сценарии и собирать сегменты. Правда, возможности здесь, увы, довольно ограничены. 

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

Еще одно существенное ограничение мы обнаружили при работе с данными внутри самих событий. Разберем на примере брошенной корзины.

Сайт определяет, что клиент оставил товары в корзине и не оформил заказ, а затем передает в Unisender событие «Брошенная корзина», которое и запускает нужный сценарий.

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

Но, как оказалось, передать состав корзины в Unisender можно, а вывести эти товары в письме — нет.

В поведенческих рассылках важно не просто отреагировать на действие клиента, а продолжить его путь. 

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

А еще в Менеджере событий нашлись баги

При тестировании мы столкнулись с двумя ошибками:

  1. В сегментации. По документации события можно использовать в условиях сегмента, но в интерфейсе они не отображались. Мы написали в поддержку Unisender, и ошибку исправили.
  2. В карточках контактов. При переходе от одного контакта к другому во вкладке «События» могли остаться данные предыдущего пользователя. Чтобы увидеть актуальные события, приходилось вручную переключать фильтр и снова выбирать исходное значение.

Обе ошибки мы обнаружили при базовой проверке Менеджера событий и сам факт таких багов усиливает общее впечатление о том, что инструменту требуется доработка.

У меня сложилось впечатление, что Менеджер событий и API-триггер — две половины одного инструмента, которые зачем-то разделили.

«Менеджер» позволяет создавать свои события, передавать вместе с ними нужную информацию и сохранять ее в карточке клиента. А API-триггер дает возможность  использовать полученные данные в сценарии и письмах.

Я думаю, если Unisender объединит эти механики, получится действительно сильный инструмент для поведенческих сценариев.

Так новый редактор уже можно использовать?

Да, но многое зависит от сложности автоматизации и того, насколько глубоко ее нужно персонализировать.

Unisender уже умеет получать достаточно много данных, но использовать ее внутри сценариев получается не всегда. Ограничения есть и в других инструментах — например, в сегментации. События можно отбирать по дате, но нельзя учитывать их количество за период или данные внутри события.

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

Мы активно используем Unisender в проектах и считаем, что новый редактор — это действительно шаг вперед. Но перед запуском стоит проверить, подходят ли новые возможности под логику конкретного сценария.