В прошлый раз мы тестировали поп-ап форму подписки, проверяя, насколько она может навредить сайту в нашем случае? Сегодня поговорим, как настраивается автоматическая отправка писем в сервисе рассылок.
Не всегда задуманные сценарии удаётся реализовать на 100% — недостаточно ресурсов на разработку, нужно всё сделать быстро или сам сервис, выбранный для рассылок, накладывает определённые ограничения.
Тогда приходится подстраиваться под то, чем мы реально располагаем: упрощать сценарий, динамический контент заменять статическим, использовать более обтекаемые формулировки в письмах и т.д.
Такие случаи и будем разбирать в этот раз.
Напоминание о бонусе за подписку
Предположим, мы даём пользователям промокод за подписку:
Промокод «улетает» по электронной почте в специальном автоматическом письме, настроенном в сервисе для случая подписки через поп-ап. При этом мы ограничиваем срок действия бонуса, чтобы дополнительно стимулировать подписчиков к покупке:
В идеале, нам нужно отслеживать, воспользовался ли подписчик промокодом и, если нет, напоминать ему об этом в отдельном письме — за некоторое время до завершения его действия. Например:
Ваша скидка сгорает через 3 дня!
Однако по факту это не так просто: придётся заводить дополнительное поле в базе данных — что-то вроде «статуса промокода» — проверять его и передавать информацию в сервис рассылок по АПИ, а в сервисе уже «привязывать» к этому событию триггерное письмо, зная наверняка, что промокод не использован.
Допустим, так сделать у нас нет возможности: мы сотрудничаем с веб-студией, которая выкатывает счёт за каждую доработку, и оценила такой функционал в изрядную сумму.
Если пользователь не открыл письмо, которое мы выслали ему сразу после подписки, очевидно, он не воспользовался промокодом внутри него.
Исходя из этого предположения мы и настраиваем нужное нам напоминание — отправлять второе письмо, скажем, через 4 дня после отправки первого, если то не было открыто:
(Вот, как может выглядеть такая настройка —
на примере сервиса GetResponse)
Конечно, это не так надёжно, как отслеживание каждого промокода. Часть пользователей откроет письмо, но промокодом не воспользуется — и мы не напомним им об этом. Другая часть откроет письмо, не загружая картинок, мы не зафиксируем это открытие и через 4 дня отправим им напоминание, хотя, возможно, промокод уже использован.
Однако это всё частные случаи: для большинства подписчиков привязка к открытию сработает корректно и автоматическая отправка писем-напоминаний о промокоде будет выглядеть адекватно. На это большинство и ориентируемся, пренебрегая некоторыми неточностями:
Итого, настройка письма-напоминания о бонусе за подписку с помощью имеющегося функционала сервиса — 0 рублей:)
Благодарность за обратную связь
Другой случай: в b2b компании нам нужно поблагодарить пользователя за анкету, которую он заполнил после встречи с менеджером:
Причём благодарность нужна именно адресная, чтобы подчеркнуть, что фидбек реально получен и взят в работу. Не просто дежурное «спасибо за анкету!» на финальной страничке Гугл Форм (хотя и это тоже есть), а отдельное письмо с благодарностью: спасибо, проработаем ситуацию…
В идеале, нам нужно передавать данные о заполнении анкеты в сервис: опять же, организовывать какое-то дополнительное поле «статус анкеты», связываться с Гугл Формами по АПИ (если есть такая возможность) и так далее.
Но мы этого сделать не можем: у компании один разработчик на удалёнке, задачи для которого расписаны на месяцы вперёд, а благодарить за анкету нужно прямо сейчас.
У нас есть данные, что 80% тех, кто переходит в анкету, заполняет её. Этого достаточно, чтобы приравнять клик по ссылке на анкету её заполнению.
В таком случае, настраиваем дополнительное письмо, идущее вслед за опросом, с условием — если пользователь перешёл по ссылке на анкету из письма, сразу отправлять ему благодарность:
(Пример подобной настройки в MailChimp)
У нас остаётся часть пользователей, кому это письмо будет отправлено не к месту — перешли по ссылке, но анкету не заполнили. Зная это, мы просто корректируем формулировку благодарности в письме, чтобы она звучала «шире»:
И такое письмо, конечно, будет выглядеть не всегда корректно. Но нас всё же интересуют те 80% случаев, когда оно придётся абсолютно «в кассу».
Брошенная корзина
Наконец, рассмотрим классический сценарий для интернет-магазина, в котором участвует автоматическая отправка писем — напоминание о брошенной корзине. На самом деле и он не так прост, как может показаться на первый взгляд.
Есть готовые решения (например, Retail Rocket), но если нам нужно реализовать письмо через обычный сервис рассылок, то сразу возникают трудности.
Для стандартного письма о корзине понадобится передавать в сервис множество параметров: ссылки на товары, их фото, названия, цены. А что, если товаров в корзине будет 10? — тогда счёт переменных пойдёт на десятки. Или товар только 1 — как скрыть лишние блоки в вёрстке? И как сделать автоматическую авторизацию при переходе по ссылке из корзины?..
В общем, тут масса нюансов, если углубляться в которые, корзину можно никогда не запустить.
Например, мы можем создать список «Бросил корзину» и передавать туда всех, у кого такое событие зафиксировано:
(Вот, как это может выглядеть, например, в UniSender)
Далее мы можем настроить автоматическую отправку по этому списку простого письма, где напомним пользователю о корзине, не показывая товаров:
Ссылку на корзину с кнопки сделаем статической —
https://shop-example.ru/cart.
Возможно, кого-то из пользователей письмо без товаров не впечатлит. А кто-то перейдёт на сайт из письма с другого устройства, и корзина по статической ссылке окажется пустой.
Но будет и та значительная часть пользователей, которым напоминание поможет вернуться на сайт, куки «вспомнят» их корзину, и они благополучно завершат заказ.
В расчёте на это мы и настраиваем такое письмо в сервисе:
→ Фиксируем событие о корзине,
→ По АПИ передаём контакт в отдельный список в сервисе,
→ По списку настраиваем отправку автоматического письма со статическим контентом.
Работает нормально!
Заключение
Итак, иногда нам приходится умерять аппетиты, чтобы автоматическая отправка писем на нашем проекте была реализована хоть в каком-то виде.
Тогда нужно опираться на то, что уже умеет сервис рассылок сам по себе, в рамках готового функционала, чтобы с минимумом доработок (просто вовремя передавать контакт в сервис из собственной базы) можно было настроить запланированное письмо.
Для части пользователей при таком подходе оно придётся некстати — будет ложное срабатывание, нерелевантный контент и т.д. Но всё-таки, налаживая нашу автоматизацию, мы опираемся на большинство, для которого упрощённый сценарий срабатывает корректно — и мы приходим к нашей цели минимально доступными средствами.
В дальнейшем, когда сценарий заработает и покажет свою жизнеспособность, может быть, получится изыскать средства на его полноценную, «правильную» реализацию.
 |
[В следующий раз займёмся аудитом email маркетинга для себя или для клиента]. |
P.S. Ещё больше информации о работе с сервисами рассылок, о том, как настраивать в них автоматические письма — см. 3-й урок моего курса «Email маркетинг под ключ».
Если вы ещё не подписались на мою рассылку — самое время это сделать 😉
