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

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

Webhooks - это не о боксе)

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

Как это работает?

Веб-хуки - это метод осуществления контроля над разными типами событий в системе ESP в режиме реального времени и информирования сторонних URL об их поведении.

Webhooks можно настроить для практически любых типов событий:

• Жалоба на спам;

• Отписка;

• Переход по ссылке;

• Прочтение письма;

• Ошибка доставки.

Веб-хуки в действии

Настроив веб-хуки, вы сможете на своей стороне получать необходимую информацию без отправки запросов в нашу систему. Например, webhooks необходимы для отслеживания того, работают ли триггеры. Чтобы получать такие уведомления о сбоях, каждому триггеру нужно присвоить свою метку (тег). В массиве JSON эта информация будет передаваться следующим образом: "messageTag": "AbandonedCart"

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

Альтернативный вариант контроля триггеров: пример из практики

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

Ниже приводится поэтапная схема внедрения таких уведомлений.

При нажатии на название организации в аккаунте еСпутник появляется выпадающее меню, в котором нужно выбрать пункт “Настройки” (Settings)

Открывается страница настройки уведомлений о сбоях (Notifications settings). С помощью кнопки Add notification создается новое уведомление.

Это может быть предупреждение (Warning) или тревога (Alarm). Для каждого важного триггера целесообразно создать оба эти уведомления, например, если в системе зафиксирован всего один заказ за день, то это повод отправить первое предупреждение, а если за 3 дня не пришло ни одного события с заказом - то это тревожный знак и нужно срочно разобраться в ситуации.

При добавлении нового уведомления нужно заполнить все требуемые поля:

• В типе уведомления указать “событие”,

• Выбрать из выпадающего списка название события, частоту поступления которого нужно контролировать,

• Указать количество событий, которое считаете критичным и период, за который система должна их посчитать;

• Выбрать вид создаваемого уведомления (“Warning” или “Alarm”)

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

Настройка сценариев запуска писем “Warning” и “Alarm”

Для отправки уведомлений “Предупреждение” и “Тревога” создаем стандартные сценарии такого вида:

Используем блок “Обязательный емейл”, так как получатель этих уведомлений не обязательно должен быть подписчиком. Отправку данных сообщений можно настроить на любой электронный адрес (например, руководителя компании, маркетолога, аккаунт менеджера).

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

Создаем письма: делаем правильные акценты

Так как сообщения “Предупреждение” и “Тревога” носят исключительно утилитарный характер, то на их дизайне можно не делать особый акцент, эти письма могут быть созданы и в Plain text формате. Главные их задачи - обратить на себя внимание получателя и донести суть проблемы. Чтоб адресат не пропустил такое письмо в почте, можно добавить в тему эмоджи. Значок тревоги привлечет внимание.

А вот пример самого уведомления:

Чтобы это письмо было более информативным и у получателя не было необходимости переходить в историю событий и искать в теле запроса название триггера, частота отправок которого не соответствует обычной или желаемой, эту информацию можно добавить в письмо такие переменные как $!data.get('AlertTrackingSourceName'), $!data.get('ActualCount'), $!data.get('PeriodDays'). Как результат, в контентной части письма будет видно, в работе какого триггера произошел сбой и какие условия были заданы в настройках (число событий и количество дней):

Как веб-хуки спасают ситуацию

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

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

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