Триггерные рассылки через сторонний сервис vs. своими силами (№104)

В прошлый раз мы вытаскивали рассылки из спама на Gmail — если уж угораздило туда провалиться из-за низкого отклика на кампании. Сегодня поговорим про триггерные (автоматические) рассылки и посмотрим, каким образом лучше налаживать их отправку:

• через сторонний сервис рассылок;
• через имеющуюся CMS/CRM-систему, самописный модуль и т.п. (то есть «своими силами»).

Такие решения периодически приходится принимать в email маркетинге — и, по всей видимости, не мне одному:)

Вопрос на Fb: триггерные рассылки — какое решение использовать?

[Аналогичный вопрос в профессиональном сообществе на Facebook]

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

 

Пример 1: Персональные товарные рекомендации

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

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

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

Триггерные рассылки: визуальный конструктор сценариев автоматических писем

[Визуальный конструктор сценариев автоматических писем в сервисе рассылок]

CRM предлагает отправку писем через свой встроенный модуль рассылок. Он значительно менее функционален. К примеру, редактировать письма можно только в режиме html-кода, нет готовой отписки, нет сколь угодно наглядной статистики по отправленным / доставленным / открытым письмам.

Триггерные рассылки: редактирование контента письма только в режиме html-кода

[Работа с контентом писем в CRM в режиме html-кода]

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

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

Каждая товарная рекомендация — это фотография товара, название и ссылка на его страницу (3 параметра).

Триггерные рассылки: структура товарной рекомендации в письме

[Типовая товарная рекомендация интернет-магазина]

Мы хотим подставлять в письма до 9 товарных рекомендаций, то есть 9 × 3 = 27 параметров. Помимо этого нам потребуется передавать в сервис «сигналы» из CRM о том, что брошен просмотр / корзина или оформлен заказ. В итоге получится порядка 30 параметров, для которых нужно подготовить в сервисе соответствующие поля, создавая громоздкую таблицу с данными.

Таблица с данными в сервисе рассылок

[Таблица с данными для товарных рекомендаций в сервисе рассылок]

Кроме того, если мы захотим менять число рекомендаций для пользователей — скажем, одному показать 9, а другому 6 штук (потому что больше не набирается), то редактор сервиса не справится с этой задачей, т.к. не поддерживает теги условия формата |IF| … |ELSE| (Если … То), необходимые, чтобы скрывать «пустые» карточки рекомендаций.

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

С другой стороны, работа в CRM не требует дополнительной интеграции — все данные уже в наличии. Подстановка / скрытие блоков в письме также возможна без проблем. Понадобятся некоторые дополнительные усилия: настроить аутентификацию, создать механизм отписки, как-то наладить сбор статистики — но всё это решаемо. Например, для отписки достаточно завести в профиле пользователя дополнительный чек-бокс «Согласен на рассылку» и снимать его в случае перехода по определённой ссылке.

Создание механизма отписки в CRM

[Чек-бокс подписки, добавленный в CRM — если флажок снимается, отправка триггеров пользователю блокируется]

 

Поэтому в данной ситуации между сервисом и CRM-системой мы делаем выбор в пользу CRM.

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

Пример 2: Индивидуальная скидка по промокоду

Другой интернет-магазин собирается отправлять подписчикам автоматические письма со скидкой 10% на второй заказ по индивидуальному промокоду с ограниченным сроком действия.

Триггерное письмо с промокодом на следующую покупку

[Автоматическое письмо с индивидуальным промокодом]

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

Промокоды генерируются с помощью специального модуля внутри CMS.

Модуль промокодов в CMS интернет-магазина

[Модуль генерации промокодов внутри CMS интернет-магазина]

Умеет сайт и отправлять письма — например, транзакционные сообщения со статусами заказов. Однако визуальный функционал для работы с письмами отсутствует. Рассылка пидёт с общего IP-адреса хостинга, на котором размещён сайт, и периодически случаются сбои доставки — из-за репутации других пользователей хостинга.

С другой стороны, интеграция с сервисом рассылок сводится в данном случае к передаче одного-единственного параметра: сгенерированного промокода на скидку. Промокод автоматически создаётся в нужный момент времени в CMS, передаётся в сервис рассылок по АПИ, а подписчик включается в дополнительный список контактов, к которому «привязано» срабатывание триггерного письма.

Автоматический сценарий в сервисе рассылок для отправки скидки 10%

[Настройка сценария отправки письма со скидкой через сервис рассылок]

 

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

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

Пробуем обобщить

В обоих случаях, приведённых выше, мы шли примерно одинаковым путём:

оценивали, что потребуется, чтобы запустить письма через сервис | через CMS/CRM;

сравнивали объём работы, а также имеющиеся плюсы и минусы;

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

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

Также мы не особо принимали во внимание экономическую сторону вопроса: как посчитать целесообразность того или иного подхода в деньгах. Однако, на мой взгляд, для небольших и средних проектов это не так критично. Цена вопроса, как правило, невысока, а триггерные письма достаточно эффективны, чтобы «отбить» затраты на внедрение в течение нескольких месяцев работы или даже быстрее. Если говорить о крупных проектах с большими бюджетами, то там подход, конечно, другой, и финансовая оценка понадобится (интересный «калькулятор» окупаемости вложений в автоматизацию маркетинга есть, например, у Mindbox).

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

Упражнение на определение динамических параметров в письме есть в статье Динамический контент в рассылке →

Зная набор параметров, мы можем задаться вопросом, откуда их получить и сложно ли будет наладить их передачу в сервис рассылок? Если у нас базовый сервис, а параметров, задействованных в письме, больше десятка (а то и несколько десятков), то, скорее всего, лучше всё делать на своей стороне. Если же речь про пару-тройку параметров, смело можно выбирать сервис, как инструмент, более приспособленный для качественных и стабильных email рассылок.

 

Заключение

Постепенно, внедряя разные триггерные рассылки, мы, что называется, «набьём руку» и будем сразу понимать, как лучше реализовать ту или иную автоматизацию. Как модифицировать триггер, чтобы его внедрение оказалось не чересчур перегруженным и сложным.

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

[В будущей статье разберёмся с такой тактикой, как повтор рассылок по неоткрывшим подписчикам: какие тут могут быть «подводные камни» и как эффективно ей пользоваться].

P.S. Ещё больше информации о грамотном ведении рассылок вы найдёте в моём курсе «Email маркетинг под ключ». Он будет доступен вам по электронной почте.

Также, если вы ещё не подписались на рассылку моего блога — самое время это сделать 😉