
В прошлый раз мы вытаскивали рассылки из спама на Gmail — если уж угораздило туда провалиться из-за низкого отклика на кампании. Сегодня поговорим про триггерные (автоматические) рассылки и посмотрим, каким образом лучше налаживать их отправку:
• через сторонний сервис рассылок;
• через имеющуюся CMS/CRM-систему, самописный модуль и т.п. (то есть «своими силами»).
Такие решения периодически приходится принимать в email маркетинге — и, по всей видимости, не мне одному:)

[Аналогичный вопрос в профессиональном сообществе на Facebook]
На самом деле, короткий ответ здесь: нужно смотреть по ситуации. Выбор всегда происходит в зависимости от конкретных обстоятельств: целей триггера, его содержания, имеющихся в наличии технических средств и т.д. Но методику такого выбора попытаться обрисовать всё-таки можно — чем мы и займёмся в данной статье. Как водится, начнём с некоторых примеров.
Пример 1: Персональные товарные рекомендации
Интернет-магазин хочет запустить базовые триггерные рассылки — напоминания о брошенных просмотрах / корзинах, предложение сопутствующих товаров, реактивацию — с подстановкой в них персональных товарных рекомендаций для каждого пользователя.
Подключить отдельный сервис товарных рекомендаций на данном этапе не хватает бюджета. Поэтому встаёт вопрос: наладить отправку через сервис, в котором ведутся массовые рассылки магазина (используется маркетинговое базовое решение) или попытаться реализовать сценарии через CRM-систему, где происходит обработка заказов.
Из преимуществ сервиса рассылок: достаточно удобная работа с контентом писем, возможность выстраивать логику отправки сообщений в визуальном конструкторе сценариев, стабильное качество доставки, автоматическая «гигиена» базы — блокировка недоступных адресов, обработка жалоб на спам, готовый механизм отписки и т.д.

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

[Работа с контентом писем в CRM в режиме html-кода]
Однако в пользу CRM говорит то, что все необходимые данные — товарные рекомендации, события брошенных просмотров / корзин, заказы — содержатся внутри системы и могут быть использованы для настройки писем без дополнительной интеграции.
Предположим, сервис рассылок нас, как маркетологов, привлекает больше. Тогда оценим синхронизацию баз данных по АПИ, которую придётся реализовать между сервисом и CRM в данном случае.
Каждая товарная рекомендация — это фотография товара, название и ссылка на его страницу (3 параметра).

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

[Таблица с данными для товарных рекомендаций в сервисе рассылок]
Кроме того, если мы захотим менять число рекомендаций для пользователей — скажем, одному показать 9, а другому 6 штук (потому что больше не набирается), то редактор сервиса не справится с этой задачей, т.к. не поддерживает теги условия формата |IF| … |ELSE| (Если … То), необходимые, чтобы скрывать «пустые» карточки рекомендаций.
Итого, мы имеем чересчур громоздкую интеграцию — стабильность которой, к тому же, под вопросом + технические ограничения внутри самого сервиса, препятствующие внедрению триггерных писем в полной мере.
С другой стороны, работа в CRM не требует дополнительной интеграции — все данные уже в наличии. Подстановка / скрытие блоков в письме также возможна без проблем. Понадобятся некоторые дополнительные усилия: настроить аутентификацию, создать механизм отписки, как-то наладить сбор статистики — но всё это решаемо. Например, для отписки достаточно завести в профиле пользователя дополнительный чек-бокс «Согласен на рассылку» и снимать его в случае перехода по определённой ссылке.

[Чек-бокс подписки, добавленный в CRM — если флажок снимается, отправка триггеров пользователю блокируется]
Поэтому в данной ситуации между сервисом и CRM-системой мы делаем выбор в пользу CRM.
| Триггерные рассылки через CRM всё же потребуют помощи программиста. Для него можно подготовить специальное техническое задание, где расписать все условия отправки. См. Как написать ТЗ на запуск автоматических писем |
Пример 2: Индивидуальная скидка по промокоду
Другой интернет-магазин собирается отправлять подписчикам автоматические письма со скидкой 10% на второй заказ по индивидуальному промокоду с ограниченным сроком действия.

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

[Модуль генерации промокодов внутри CMS интернет-магазина]
Умеет сайт и отправлять письма — например, транзакционные сообщения со статусами заказов. Однако визуальный функционал для работы с письмами отсутствует. Рассылка пидёт с общего IP-адреса хостинга, на котором размещён сайт, и периодически случаются сбои доставки — из-за репутации других пользователей хостинга.
С другой стороны, интеграция с сервисом рассылок сводится в данном случае к передаче одного-единственного параметра: сгенерированного промокода на скидку. Промокод автоматически создаётся в нужный момент времени в CMS, передаётся в сервис рассылок по АПИ, а подписчик включается в дополнительный список контактов, к которому «привязано» срабатывание триггерного письма.

[Настройка сценария отправки письма со скидкой через сервис рассылок]
Реализация через сервис рассылок в этом случае выглядит проще и надёжнее. Поэтому вывод такой: сравнивая возможности CMS и сервиса, делаем выбор в пользу сервиса.
| Кстати, сервис можно использовать, чтобы реализовать и более сложные триггерные рассылки, если их намеренно «подстроить» под имеющийся функционал: сократить число передаваемых параметров, творчески применить доступные опции сервиса. См. подробнее Настраиваем автоматические письма… |
Пробуем обобщить
В обоих случаях, приведённых выше, мы шли примерно одинаковым путём:
→ оценивали, что потребуется, чтобы запустить письма через сервис | через CMS/CRM;
→ сравнивали объём работы, а также имеющиеся плюсы и минусы;
→ выбирали оптимальный вариант с точки зрения трудозатрат, простоты и надёжности решения.
В этом порядке действий мы исходили из того, что инструментарий нам задан, и у нас нет возможности его поменять: скажем, подключить профессиональный сервис рассылок или какое-то другое решение — работаем с тем, что есть.

Также мы не особо принимали во внимание экономическую сторону вопроса: как посчитать целесообразность того или иного подхода в деньгах. Однако, на мой взгляд, для небольших и средних проектов это не так критично. Цена вопроса, как правило, невысока, а триггерные письма достаточно эффективны, чтобы «отбить» затраты на внедрение в течение нескольких месяцев работы или даже быстрее. Если говорить о крупных проектах с большими бюджетами, то там подход, конечно, другой, и финансовая оценка понадобится (интересный «калькулятор» окупаемости вложений в автоматизацию маркетинга есть, например, у Mindbox).
Если мы в чём-то сомневаемся и нам сходу трудно разбить проект на подзадачи, можно просто открыть блочный редактор писем и начать «набрасывать» в нём интересующее нас письмо, а параллельно разбираться, какие параметры необходимы для его создания.
| Упражнение на определение динамических параметров в письме есть в статье Динамический контент в рассылке → |
Зная набор параметров, мы можем задаться вопросом, откуда их получить и сложно ли будет наладить их передачу в сервис рассылок? Если у нас базовый сервис, а параметров, задействованных в письме, больше десятка (а то и несколько десятков), то, скорее всего, лучше всё делать на своей стороне. Если же речь про пару-тройку параметров, смело можно выбирать сервис, как инструмент, более приспособленный для качественных и стабильных email рассылок.
Заключение
Постепенно, внедряя разные триггерные рассылки, мы, что называется, «набьём руку» и будем сразу понимать, как лучше реализовать ту или иную автоматизацию. Как модифицировать триггер, чтобы его внедрение оказалось не чересчур перегруженным и сложным.
В конце концов, мы можем даже наделать ошибок на первых порах, пытаясь запустить сценарий через неподходящее решение. Однако и это будет работать на нас в долгосрочной перспективе — добавляя нам опыта и аргументов в следующий раз, когда придёт пора выбирать, через что реализовать автоматические письма: через внутренний функционал или внешний сервис рассылок.
![]() |
[В будущей статье разберёмся с такой тактикой, как повтор рассылок по неоткрывшим подписчикам: какие тут могут быть «подводные камни» и как эффективно ей пользоваться]. |
P.S. Ещё больше информации о грамотном ведении рассылок вы найдёте в моём курсе «Email маркетинг под ключ». Он будет доступен вам по электронной почте.
Также, если вы ещё не подписались на рассылку моего блога — самое время это сделать 😉
