Обычно триггерные письма внедряют через сервис рассылок. Передают туда данные посредством интеграции, а внутри сервиса при помощи пользовательского интерфейса настраивают нужные сценарии:
Но такой путь подойдёт не всегда. Иногда сервис не может реализовать сценарий: у него не хватает функционала или нужна слишком сложная интеграция.
Решить проблему можно 2 способами.
Подключить более продвинутый сервис рассылок. Это дорого и долго — нужно переносить базу, настраивать все старые интеграции и только после этого подключать новую.
Настроить отправку писем своими силами, через CMS или CRM-систему. Этот способ дешевле, быстрее и проще. В CMS/CRM, которую мы используем на проекте, уже есть все нужные данные. Как правило, этот движок умеет отправлять письма — остаётся настроить нужный сценарий. Для этого нам понадобится помощь веб-программиста / студии, которая разрабатывала наш сайт или занимается его техподдержкой.
При этом мало просто поручить специалисту настройку триггерных писем. Чтобы получить хороший результат на выходе, нужно написать подробное техническое задание на внедрение (ТЗ).
В своей работе я пользуюсь следующей структурой ТЗ по каждому триггерному письму, которое собираюсь запустить:
Поговорим о каждом разделе ТЗ подробнее, а в конце посмотрим на пример конкретного ТЗ, который можно использовать в качестве образца в работе.
Начинаем ТЗ, как водится, с общей постановки задачи:
запустить напоминание о брошенной корзине…
автоматически запрашивать отзыв после заказа…
предложить пользователю сопутствующие продукты…
Ниже мы детальнее опишем, что требуется сделать. Хорошо, если наша цель ясна исполнителю с первых строчек ТЗ. Это упростит понимание задачи, а может и сразу наведёт его на мысли о технической реализации.
В данном разделе сообщим всё, что требуется, о том, при каких условиях мы хотим отправить письмо. Например, пользователь:
не продлил подписку на издание на следующий месяц…
сделал первый заказ, но не делает второй…
скачал брошюру «Шпаргалка по выбору цвета»…
Если условие наступило, это не значит, что письмо должно уйти мгновенно.
Я предпочитаю обособлять это отдельным пунктом ТЗ, где конкретно описываю всё, что касается момента отправки:
Например, письмо отправляется:
7-го числа каждого месяца, в 12:00 по мск…
через 30 дней после присвоения заказу статуса «Выполнен» (в то же самое время, в которое был присвоен статус)…
через 3 дня после скачивания брошюры, в 11:00 по мск (только будний день — если отправка приходится на выходной, сдвигаем на ближайшие понедельник)…
Почти в любой системе есть какой-то простой интерфейс для работы с письмами.
Как правило в нём отдельными полями выносятся:
Тему, адрес и имя отправителя удобно прописать отдельно в ТЗ, в качестве «базовых» настроек.
Даём ссылку на HTML-код письма. На мой взгляд, это принципиальный момент. Не стоит нагружать программиста ещё и «упаковкой» контента. Это специфическая работа, которую лучше или выполнить самому — на базе онлайн-конструктора писем — или поручить email-верстальщику.
Содержание письма, которое мы приводим в ТЗ, должно быть подготовлено по всем правилам вёрстки для email, корректно отображаться в разных почтовиках, адаптироваться на смартфонах.
Из нюансов: во всех ссылках письма стоит заранее прописать UTM-метки — обычно наша «домашняя» система не имеет функционала по их автоматической простановке. Или дополнительно обсудить этот момент с программистом, чтобы он добавил UTM при внедрении.
Скорее всего наше триггерное письмо содержит некоторое количество динамического контента — то есть контента, который меняется в зависимости от данных каждого пользователя. Например, в сообщение подставляется имя, номера заказа, количество накопленных бонусов.
Очень может быть, что в нашем письме динамических элементов будет много. Это одна из причин запускать его своими силами, чтобы не заморачиваться передачей всех параметров в сторонний сервис рассылок.
Подставлять динамический контент из базы данных будет программист. Но в самом письме нам нужно разметить места для подстановок. Обычно я пользуюсь условными обозначениями вида {{dinamic_tag}}, которые добавляю в HTML-код:
В ТЗ, в отдельном разделе я прописываю, что именно нужно подставлять вместо тегов:
{{Имя}} — подставляем имя пользователя (например, Сергей).
{{email}} — подставляем email-адрес пользователя, на который отправили рассылку.
{{ДД.ММ.ГГ}} — подставляем дату окончания действия промокода (например, 03.02.20).
Я рекомендую предусматривать ссылку отписки как элемент динамического контента.
С функцией отключения таких писем для пользователя, а возможно — передачей «сигнала» в наш сервис рассылок по API, чтобы отписать пользователя одновременно и там.
Также я добавляю в ТЗ конкретный пример, как задуманный сценарий должен срабатывать:
Часто это значительно упрощает понимание задачи и добавляет объёма к ТЗ.
На выходе мы получаем документ — в нём где-то по 2-3 страницы на каждое письмо:
Далее передаём его в работу программисту. Не пускаем дело на самотёк и активно сопровождаем внедрение — отвечаем на вопросы, возможно, что-то корректируем по ходу дела:
Затем принимаем результат. На тестирование и отладку писем лучше заложить отдельное время — это полноценная задача, которая требует нашего внимания. Даже если мы детально прописали всё в ТЗ, вряд ли задуманная механика заработает как нужно с первого раза. Скорее всего понадобится несколько циклов тестирования / исправления ошибок.
Во время тестов испытываем систему «на прочность», инициируя несколько событий одновременно, в разной последовательности, с разными условиями. Например, бросаем корзину, затем оформляем заказ, снова добавляем товары в корзину, но почти сразу удаляем их. Смотрим, какие письма нам в этом случае приходят.
Подробное ТЗ на внедрение помогает получить на выходе то, что запланировали, вплоть до малейших нюансов и деталей. А именно из таких мелочей и складывается полноценный email-маркетинг.
Делимся новостями и свежими статьями, рассказываем о новинках сервиса
Искренние письма о работе и жизни. Свежие статьи из блога. Эксклюзивные кейсы и интервью с экспертами диджитала.
