Более 40% выручки Lingualeo приходит из email — канала. В 2015 году мы отправили 300 млн писем. Для нас крайне важно, чтобы этот канал продаж работал эффективно: прогнозируемо, масштабируемо, а ROI рассылки максимизировался.
Сегодня мы в общих чертах расскажем о нашей непростой системе email-маркетинга, о переезде с одной платформы на другую, о системе локализации и о технических нюансах переезда. В этой коллективно подготовленной статье (Роман Домрачев, Backend Team Leader Lingualeo; Иван Зеленин, ex-руководитель отдела email-маркетинга и CRM Lingualeo, ныне операционный директор классного агентства по CRM-маркетингу WIM.Agency; Владимир Витковский, менеджер по монетизации Lingualeo; Константин Шиманаев, ведущий менеджер по маркетингу Lingualeo) есть интересные вещи и для маркетологов, и для технарей!
В 2015 году Lingualeo столкнулся с необходимостью перехода на новую платформу и технологию отправки писем, так как текущий ресурс (агентство, которое работало с платформой ExpertSender) уже не справлялся с нашими объемами и “хотелками”. Это была хорошая качественная платформа. Но Lingualeo уже из нее вырос. Плюс нам было важно контролировать весь процесс e-mailing’a: от дизайна до отправки. Поэтому мы решили перевести работу на другую платформу и начать готовить рассылки in-house. Мы хотели сделать email-marketing машиной.
Для выбора новой системы мы сформировали следующие критерии:
Мы остановили выбор на платформе Emarsys.
Но выбрать платформу на основании ТЗ было малой толикой. Следующим шагом стала интеграция с Lingualeo.
Любая интеграция с Email service provider (далее — ESP) предполагает 3 шага:
В нашем случае у Lingualeo еще добавилась автоматическая выгрузка аналитики из ESP, так как нам важно было понимать всё, что происходит на стороне ESP (отправленные письма, открытия писем, клики, недоставки), и сравнивать это с действиями пользователей на сайте. Плюс система локализации. Это с технической стороны.
С маркетинговой требовалось:
На начальном этапе интеграции ExpertSender и Emarsys были подключены параллельно на разных почтовых поддоменах.
Пользователи синхронизируются в оба ESP, а триггеры отправляются через один. К какому провайдеру относится триггер, настраивает администратор. Так мы смогли постепенно перенести старые триггеры в Emarsys, а новые делать сразу в нём.
Такая схема предполагает, что синхронизация пользователей должна производиться во все ESP одновременно. А также должна присутствовать возможность отправлять триггеры в обе системы, но письма отправлять только из одной. Однако, в качестве защиты от ошибок, отправка триггеров должна производиться только в одну из подключенных ESP, чтобы не допустить повторной отправки одного и того же письма из другой ESP. Администратор может управлять конфигурацией: через какую ESP какой тип писем отправлять.
Синхронизация пользователей и отправка триггеров – запросы в Emarsys. При синхронизации мы шлём значения, которые сохраняются в базе данных ESP, а при отправке триггеров отправляем идентификатор и данные, из которых провайдер собирает письмо.
Локализация шаблонов — две задачи, которые запускаются по крону: одна берёт шаблоны из ESP, парсит их и отправляет сегменты на перевод в WebTranslateIt (далее WTI), а вторая получает переведенные сегменты из WTI и выгружает их в ESP. Подробнее о локализации ниже.
Запросы на создание, обновление пользователей и отправку триггеров выполняются через очередь RabbitMQ. Запрос с сайта в ESP можно представить в виде двух частей:
Отправка запросов с сайта делается через сервис emailing’a. Он склеивает однотипные сообщения в один запрос, чтобы нагрузка на ESP была меньше. Сообщения отправляются через очередь, так нам не приходится заставлять пользователя ждать, пока ESP ответит.
Во время работы приложения мы имеем дело с данными пользователя, и каждое из изменений повторяется в ESP. Код приложения «подписывается» на сохранение пользователя и отправляет нужные данные. Но если отправлять запрос при каждом сохранении, то мы создаем много маленьких запросов. Эту проблему в Lingualeo решили, переделав отправку запросов. Теперь, когда меняются пользовательские данные, мы не отправляем запрос, а складываем в «карман». При завершении http-запроса мы собираем запросы, оказавшиеся в «кармане», и обрабатываем так, что сколько угодно изменений одного и того же пользователя превращаются в один запрос обновления данных в ESP.
Из очереди запрос забирают воркеры.
Воркеры — приложения, которые достают задания из очереди и выполняют. Воркер обрабатывает 1000 заданий, после чего умирает и перезапускается супервизором (supervisord.org).
Здесь сообщения сервиса e-mailing'а превращаются в понятные каждому из провайдеров запросы.
В очередях нельзя показать пользователю страницу «в джунглях творится что-то неладное», в случае ошибки воркер должен обработать ситуацию самостоятельно. В очереди не у кого спросить “что делать?”. Остаётся упасть с ошибкой, которая запишется в лог. Лог обрабатывает Gralylog2 (www.graylog.org), который умеет слать оповещения в почту и показывать потоки сообщений.
Логи спасают, если приложение падает, но если оно тормозит, логи не помогают понять, что произошло. Обнаруживать такие сообщения нам помогает pinba (pinba.org), в которую мы шлём таймеры приложения. У нас в центре офиса висит монитор, который показывает метрики сайта из данных, полученных пинбой.
Этапы подготовки писем:
У нас есть план рассылок на месяц. Цикл подготовки письма занимает в среднем неделю. Хотя периодически бывают срочные письма, и мы делаем их за 1 день. Исходя из плана e-mail менеджер делает заявки в jira на дизайн, прописывает проект, одновременно с этим ставится задача на копирайтинг. Как только копирайтинг готов, мы добавляем тексты в задачу дизайнерам в jira. Если дизайнеры заняты, то email-менеджер использует готовую базу картинок и пытается “слепить” изображение руками на основании готовых шаблонов верстки, чтобы не рисовать с нуля, а обойтись минимум изменений в готовой верстке. В случае, если дизайнеры подготовили уникальный шаблон, последний уходит верстальщикам. Верстка происходит очень быстро. Несколько часов — и нам сдают уже сверстанный макет. Email-менеджер проверят его в специализированной системе (у нас это emailonacid) и тестирует, как письма выглядят в мобильной версии и в разных клиентах.
Верстка несет в себе определенные сложности. Email-верстка очень специфична. Можно использовать только старые стандарты, нельзя div, следовательно, приходится пользоваться только определенными тегами. Верстальщики не очень любят email, потому что есть большие ограничения и нет возможности пользоваться новыми технологиями.
Чтобы выжать максимум из email-маркетинга, мало отправлять 300 млн писем в год, нужно отправлять их как можно более таргетированными (больше писем маленьким сегментам) и персонализированными (имеющими больше конкретики о получателе в теле письма — имя, пол, и даже данные о пройденных и рекомендуемых занятиях). Аналитика показывает, что это верный шаг — письма с персонализацией имеют конверсию на 20% выше.
Мы синхронизируем в Emarsys два типа данных — статические (пол, возраст и тд) и поведенческие данные. Статические данные больше подходят для фильтрации, а для более глубокой персонализации мы используем дополнительные поля, в которые приложение загружает данные периодически. Например, письмо со статистикой пользователя по занятиям формируется за несколько часов до отправки, чтобы оставаться актуальным, дойдя до пользователя!
Триггеры — это указание Emarsys отправить письмо сразу, используя переданные данные, или спустя время, заданное в панели управления. Триггеры можно использовать, чтобы создавать рассылки самостоятельно. Для этого нужно подготовить список пользователей и отправить для каждого из них запрос в Emarsys с нужными данными. Такой способ рассылок поддерживать сложнее, чем обычный. Зато мы можем реагировать на действия пользователя в тот же момент, когда он совершает эти действия на сайте.
Как пример триггерной рассылки можно привести мотивирующее письмо, которое пользователь получает после работы со словарем. Например, пользователь добавляет слова в свой “Словарь”, но не тренирует в течение последующих 2 дней. В таком случае, на второй день после добавления ему приходит письмо-мотивашка с напоминанием о том, что ему следует выучить эти слова. Письма такого рода имеют одни из самых лучших показателей вовлечения пользователей сервиса.
Одна из особенностей работы Lingualeo — это широкая география. Наши студенты живут не только в России и ближнем зарубежье, но и в Бразилии и Турции. Поэтому наши email-коммуникации должны быть локализованы.
Очень важно, чтобы каждому уходило свое письмо. Система локализации работает следующим образом: у нас есть шаблон, он делится на определенные строчки, которые мы хотим перевести. Этот текст передается в систему для перевода – это WTI. (Подробнее о системе локализации продукта Lingualeo в посте Игоря Любимова, Head of Localization Lingualeo.) В этой системе переводчики получают строки, дальше происходит «магия». По результатам «колдовства» перевод приходит в Emarsys в виде шаблонов. Далее мы проверяем, отправляя менеджерам по локализации: насколько правдивым получилось письмо, и стоит ли что-то изменить визуально.
Техническая сторона «магии» локализации происходит следующим образом: маркетологи создают master-шаблон на русском языке. Дальше этот шаблон подхватывается сервисом локализации, и на его основе создаются локализованные slave-шаблоны. Локаль пользователя хранится в его карточке в Emarsys.
Задача локализации разделена на два этапа:
Обе задачи решаются сервисом локализации: EmarsysLocalizationService. Запуск системы локализации происходит каждый час.
Алгоритм экспорта сегментов из Emarsys в WTI:
Алгоритм импорта сегментов из WTI в Emarsys:
— Содержимое сохраняется в slave-шаблон (шаблон создается, если его не было или обновляется, если он уже
существовал).
Схема взаимодействия WTI и Emarsys:
Для оценки эффективности рассылок, помимо базовых метрик (open rate, click rate, unsubsсribe rate, и т.п.), доступных в кабинете Emarsys, мы используем ряд дополнительных, которые рассчитываются на основе активности пользователя на сервисе после перехода из письма.
Это возможно благодаря тому, что информация о всех отправках, открытиях писем и переходах по ссылкам из них, загружается в наше аналитическое хранилище, где можно рассчитать любые метрики и воронки в произвольных разрезах. По каждой рассылке можно построить, например, такую воронку:
Шаг 1. Количество отправок.
Шаг 2. Количество открытий.
Шаг 3. Количество переходов из писем.
Шаг 4. Количество пользователей, получивших XP в течение суток после перехода из письма.
Шаг 5. Количество совершивших покупку в течение суток + выручка с каждой отправки в течение суток после рассылки.
Все перечисленные метрики можно произвольно сегментировать, например, по полу, возрасту, количеству дней с момента регистрации (новички/старички), платформе регистрации и т.д. На основе этой информации мы оптимизируем рассылки.
С технической стороны:
С бизнес-маркетинговой стороны:
Сегодня мы в общих чертах расскажем о нашей непростой системе email-маркетинга, о переезде с одной платформы на другую, о системе локализации и о технических нюансах переезда. В этой коллективно подготовленной статье (Роман Домрачев, Backend Team Leader Lingualeo; Иван Зеленин, ex-руководитель отдела email-маркетинга и CRM Lingualeo, ныне операционный директор классного агентства по CRM-маркетингу WIM.Agency; Владимир Витковский, менеджер по монетизации Lingualeo; Константин Шиманаев, ведущий менеджер по маркетингу Lingualeo) есть интересные вещи и для маркетологов, и для технарей!
В 2015 году Lingualeo столкнулся с необходимостью перехода на новую платформу и технологию отправки писем, так как текущий ресурс (агентство, которое работало с платформой ExpertSender) уже не справлялся с нашими объемами и “хотелками”. Это была хорошая качественная платформа. Но Lingualeo уже из нее вырос. Плюс нам было важно контролировать весь процесс e-mailing’a: от дизайна до отправки. Поэтому мы решили перевести работу на другую платформу и начать готовить рассылки in-house. Мы хотели сделать email-marketing машиной.
Для выбора новой системы мы сформировали следующие критерии:
- стоимость на 1000 писем;
- возможность работы с различными языковыми локалями;
- максимальная доставляемость на email-домены по всему миру;
- удобство интерфейса для администрирования большого количества email-цепочек;
- время доставки больших объемов писем в течение нескольких часов (до этого максимально мы могли отправить 1-2 млн в день, при этом было необходимо просить агентство делать ручные “докрутки” в системе);
- подробная аналитика (мы хотели знать, что происходит с нашими письмами, какие действия клиенты совершают по отношению к ним, но были не готовы строить аналитическую систему на своей стороне);
- аптайм > 99,5%;
- простая интеграция с бекендом Lingualeo;
- русскоязычная техническая поддержка и её физическое присутствие в России, включая технический персонал.
Мы остановили выбор на платформе Emarsys.
Но выбрать платформу на основании ТЗ было малой толикой. Следующим шагом стала интеграция с Lingualeo.
Схема интеграции
Любая интеграция с Email service provider (далее — ESP) предполагает 3 шага:
- регулярная синхронизация базы контактов с использованием выгрузок CSV;
- мгновенная синхронизация с использованием API.;
- настройка API-триггеров для передачи событий.
В нашем случае у Lingualeo еще добавилась автоматическая выгрузка аналитики из ESP, так как нам важно было понимать всё, что происходит на стороне ESP (отправленные письма, открытия писем, клики, недоставки), и сравнивать это с действиями пользователей на сайте. Плюс система локализации. Это с технической стороны.
С маркетинговой требовалось:
- Настроить логику триггеров и цепочек писем;
- Обновить, протестировать и выкатить дизайн и вёрстку писем;
- Проследить за доставляемостью, настроить постмастера и обеспечить плавный разогрев;
- Обновить формат аналитики и повысить его смысловую значимость.
На начальном этапе интеграции ExpertSender и Emarsys были подключены параллельно на разных почтовых поддоменах.
Пользователи синхронизируются в оба ESP, а триггеры отправляются через один. К какому провайдеру относится триггер, настраивает администратор. Так мы смогли постепенно перенести старые триггеры в Emarsys, а новые делать сразу в нём.
Такая схема предполагает, что синхронизация пользователей должна производиться во все ESP одновременно. А также должна присутствовать возможность отправлять триггеры в обе системы, но письма отправлять только из одной. Однако, в качестве защиты от ошибок, отправка триггеров должна производиться только в одну из подключенных ESP, чтобы не допустить повторной отправки одного и того же письма из другой ESP. Администратор может управлять конфигурацией: через какую ESP какой тип писем отправлять.
Синхронизация пользователей и отправка триггеров – запросы в Emarsys. При синхронизации мы шлём значения, которые сохраняются в базе данных ESP, а при отправке триггеров отправляем идентификатор и данные, из которых провайдер собирает письмо.
Локализация шаблонов — две задачи, которые запускаются по крону: одна берёт шаблоны из ESP, парсит их и отправляет сегменты на перевод в WebTranslateIt (далее WTI), а вторая получает переведенные сегменты из WTI и выгружает их в ESP. Подробнее о локализации ниже.
Запросы на создание, обновление пользователей и отправку триггеров выполняются через очередь RabbitMQ. Запрос с сайта в ESP можно представить в виде двух частей:
- попадание запроса в очередь;
- обработка и выполнение запроса.
Отправка запроса в очередь
Отправка запросов с сайта делается через сервис emailing’a. Он склеивает однотипные сообщения в один запрос, чтобы нагрузка на ESP была меньше. Сообщения отправляются через очередь, так нам не приходится заставлять пользователя ждать, пока ESP ответит.
Во время работы приложения мы имеем дело с данными пользователя, и каждое из изменений повторяется в ESP. Код приложения «подписывается» на сохранение пользователя и отправляет нужные данные. Но если отправлять запрос при каждом сохранении, то мы создаем много маленьких запросов. Эту проблему в Lingualeo решили, переделав отправку запросов. Теперь, когда меняются пользовательские данные, мы не отправляем запрос, а складываем в «карман». При завершении http-запроса мы собираем запросы, оказавшиеся в «кармане», и обрабатываем так, что сколько угодно изменений одного и того же пользователя превращаются в один запрос обновления данных в ESP.
Обработка и выполнение запроса
Из очереди запрос забирают воркеры.
Воркеры — приложения, которые достают задания из очереди и выполняют. Воркер обрабатывает 1000 заданий, после чего умирает и перезапускается супервизором (supervisord.org).
Здесь сообщения сервиса e-mailing'а превращаются в понятные каждому из провайдеров запросы.
В очередях нельзя показать пользователю страницу «в джунглях творится что-то неладное», в случае ошибки воркер должен обработать ситуацию самостоятельно. В очереди не у кого спросить “что делать?”. Остаётся упасть с ошибкой, которая запишется в лог. Лог обрабатывает Gralylog2 (www.graylog.org), который умеет слать оповещения в почту и показывать потоки сообщений.
Логи спасают, если приложение падает, но если оно тормозит, логи не помогают понять, что произошло. Обнаруживать такие сообщения нам помогает pinba (pinba.org), в которую мы шлём таймеры приложения. У нас в центре офиса висит монитор, который показывает метрики сайта из данных, полученных пинбой.
Подготовка писем
Этапы подготовки писем:
- формирование идеи,
- мock-up письма,
- копирайтинг,
- дизайн,
- вёрстка,
- тестирование вёрстки,
- персонализация и настройка,
- тестирование,
- локализация.
Идея, mock-up, копирайтинг, дизайн и верстка
У нас есть план рассылок на месяц. Цикл подготовки письма занимает в среднем неделю. Хотя периодически бывают срочные письма, и мы делаем их за 1 день. Исходя из плана e-mail менеджер делает заявки в jira на дизайн, прописывает проект, одновременно с этим ставится задача на копирайтинг. Как только копирайтинг готов, мы добавляем тексты в задачу дизайнерам в jira. Если дизайнеры заняты, то email-менеджер использует готовую базу картинок и пытается “слепить” изображение руками на основании готовых шаблонов верстки, чтобы не рисовать с нуля, а обойтись минимум изменений в готовой верстке. В случае, если дизайнеры подготовили уникальный шаблон, последний уходит верстальщикам. Верстка происходит очень быстро. Несколько часов — и нам сдают уже сверстанный макет. Email-менеджер проверят его в специализированной системе (у нас это emailonacid) и тестирует, как письма выглядят в мобильной версии и в разных клиентах.
Верстка несет в себе определенные сложности. Email-верстка очень специфична. Можно использовать только старые стандарты, нельзя div, следовательно, приходится пользоваться только определенными тегами. Верстальщики не очень любят email, потому что есть большие ограничения и нет возможности пользоваться новыми технологиями.
Персонализация
Чтобы выжать максимум из email-маркетинга, мало отправлять 300 млн писем в год, нужно отправлять их как можно более таргетированными (больше писем маленьким сегментам) и персонализированными (имеющими больше конкретики о получателе в теле письма — имя, пол, и даже данные о пройденных и рекомендуемых занятиях). Аналитика показывает, что это верный шаг — письма с персонализацией имеют конверсию на 20% выше.
Рассылки группам пользователей
Мы синхронизируем в Emarsys два типа данных — статические (пол, возраст и тд) и поведенческие данные. Статические данные больше подходят для фильтрации, а для более глубокой персонализации мы используем дополнительные поля, в которые приложение загружает данные периодически. Например, письмо со статистикой пользователя по занятиям формируется за несколько часов до отправки, чтобы оставаться актуальным, дойдя до пользователя!
Триггерные рассылки
Триггеры — это указание Emarsys отправить письмо сразу, используя переданные данные, или спустя время, заданное в панели управления. Триггеры можно использовать, чтобы создавать рассылки самостоятельно. Для этого нужно подготовить список пользователей и отправить для каждого из них запрос в Emarsys с нужными данными. Такой способ рассылок поддерживать сложнее, чем обычный. Зато мы можем реагировать на действия пользователя в тот же момент, когда он совершает эти действия на сайте.
Как пример триггерной рассылки можно привести мотивирующее письмо, которое пользователь получает после работы со словарем. Например, пользователь добавляет слова в свой “Словарь”, но не тренирует в течение последующих 2 дней. В таком случае, на второй день после добавления ему приходит письмо-мотивашка с напоминанием о том, что ему следует выучить эти слова. Письма такого рода имеют одни из самых лучших показателей вовлечения пользователей сервиса.
Локализация
Одна из особенностей работы Lingualeo — это широкая география. Наши студенты живут не только в России и ближнем зарубежье, но и в Бразилии и Турции. Поэтому наши email-коммуникации должны быть локализованы.
Очень важно, чтобы каждому уходило свое письмо. Система локализации работает следующим образом: у нас есть шаблон, он делится на определенные строчки, которые мы хотим перевести. Этот текст передается в систему для перевода – это WTI. (Подробнее о системе локализации продукта Lingualeo в посте Игоря Любимова, Head of Localization Lingualeo.) В этой системе переводчики получают строки, дальше происходит «магия». По результатам «колдовства» перевод приходит в Emarsys в виде шаблонов. Далее мы проверяем, отправляя менеджерам по локализации: насколько правдивым получилось письмо, и стоит ли что-то изменить визуально.
Техническая сторона «магии» локализации происходит следующим образом: маркетологи создают master-шаблон на русском языке. Дальше этот шаблон подхватывается сервисом локализации, и на его основе создаются локализованные slave-шаблоны. Локаль пользователя хранится в его карточке в Emarsys.
Задача локализации разделена на два этапа:
- Парсинг master-шаблонов и экспорт сегментов в WTI.
- Получение переводов из WTI и создание/обновление локализованных slave-шаблонов.
Обе задачи решаются сервисом локализации: EmarsysLocalizationService. Запуск системы локализации происходит каждый час.
Алгоритм экспорта сегментов из Emarsys в WTI:
- Все шаблоны приходят из Emarsys.
- Система отфильтровывает только master-шаблоны.
- Для каждого master-шаблона запрашивается его контент из Emarsys.
- Сегменты парсятся из контента шаблона (key = значение атрибута data-translate-segment, value=содержимое внутри тега).
- Набор сегментов из шаблона отправляется в WTI (каждому шаблону соответствует свой файл в WTI).
Алгоритм импорта сегментов из WTI в Emarsys:
- Все данные для проекта Lingualeo-Email-Templates запрашиваются из WTI.
- Все шаблоны приходят из Emarsys.
- Система отфильтровывает только master-шаблоны.
- Для каждого master-шаблона запрашивается его контент из Emarsys:
- Из WTI-проекта извлекается информация о WTI-master-файле, который соответствует текущему шаблону.
- Для каждой включенной локали из WTI запрашиваются сегменты (по ID wti-master-файла).
— Содержимое сохраняется в slave-шаблон (шаблон создается, если его не было или обновляется, если он уже
существовал).
Схема взаимодействия WTI и Emarsys:
АНАЛИТИКА
Для оценки эффективности рассылок, помимо базовых метрик (open rate, click rate, unsubsсribe rate, и т.п.), доступных в кабинете Emarsys, мы используем ряд дополнительных, которые рассчитываются на основе активности пользователя на сервисе после перехода из письма.
Это возможно благодаря тому, что информация о всех отправках, открытиях писем и переходах по ссылкам из них, загружается в наше аналитическое хранилище, где можно рассчитать любые метрики и воронки в произвольных разрезах. По каждой рассылке можно построить, например, такую воронку:
Шаг 1. Количество отправок.
Шаг 2. Количество открытий.
Шаг 3. Количество переходов из писем.
Шаг 4. Количество пользователей, получивших XP в течение суток после перехода из письма.
Шаг 5. Количество совершивших покупку в течение суток + выручка с каждой отправки в течение суток после рассылки.
Все перечисленные метрики можно произвольно сегментировать, например, по полу, возрасту, количеству дней с момента регистрации (новички/старички), платформе регистрации и т.д. На основе этой информации мы оптимизируем рассылки.
ИТОГО
С технической стороны:
- Увеличили возможный объём отправляемых сообщений до 45 млн ежемесячно и больше;
- Получили возможность отправлять до 20 млн писем в сутки;
- Время доставки 2 млн сообщений сократилось с суток до 1-2 часов и ограничивается лишь способностью принять на сайте определенное количество учащихся;
- Процесс подготовки писем на разные локали упростился и стал занимать минимум вдвое меньше времени и ресурсов;
- Для внедрения новых триггеров реже нужно вмешательство команды backend-разработки.
С бизнес-маркетинговой стороны:
- Получили доступ к расширенной аналитике, включая список конкретных действий по каждой email-кампании;
- Ускорили процесс создания и отправки срочного письма с недели до одного дня при необходимости;
- Ускорили процесс внедрения штатного письма с двух недель до недели;
- Улучшили качество писем за счёт вовлечения внутренних дизайнеров в процесс создания писем и контроля с их стороны;
- Значительно удешевили стоимость отправки письма.
- На десятки процентов улучшили продуктовые и маркетинговые метрики, связанные с emailing'ом (и нам все еще есть над чем работать)
