Как Emerging Travel Group подготовили письма к выходу на мировой рынок

Привет! Меня зовут Мария, я занимаюсь емейл-маркетингом в группе компаний Emerging Travel Group. Сегодня я расскажу, как мы усовершенствовали структуру наших сервисных писем, чтобы быстро переводить их на разные языки.

Emerging Travel Group управляет компаниями, которые специализируются на бронировании отелей в 220 странах мира. Наши бренды — Ostrovok, ZenHotels, B2B.Ostrovok и RateHawk — работают более чем на 100 рынках.

Масштабы емейл-коммуникации огромны: разные бренды, разные сегменты пользователей, разные маркетинговые акции и, конечно, разные языки. Не сойти с ума во всём этом нам помогает MailOTA.

Знакомьтесь — MailOTA

MailOTA — это внутренняя система управления емейл-коммуникацией, созданная нашей продуктовой командой на Django. MailOTA интегрируется с «транспортом» рассылок Mailgun, корпоративными СУБД и CRM, использует Jinja2 для рендера писем и стандартный механизм GNU gettext для их локализации. Это полноценная ESP, которую мы постоянно совершенствуем: добавляем новые возможности, автоматизируем рутину, делаем удобнее интерфейс, упрощаем (в хорошем смысле) емейл-маркетинг.

Django — платформа для разработки сложных сайтов и веб-приложений, написанная на языке программирования Python.

СУБД — система управления базами данных.

Jinja2 — шаблонизатор для языка программирования Python.

Рендеринг (отрисовка) — преобразование математического описания или кода в графическое изображение.

GNU gettext — программное обеспечение для адаптации продукта к разным языкам.

Самое важное, что мы делаем в MailOTA, — управляем транзакционными и триггерными письмами на всех языках брендов ETG. Мы уже локализовали наши сайты на тринадцати языках: английский, русский, немецкий, испанский, французский, итальянский, португальский, польский, турецкий, греческий, румынский, болгарский, венгерский. То же и с письмами. В ближайших планах — запускать новый язык каждый месяц.

При таких масштабах локализации у нас возникло две проблемы:

  1. Мы не успевали переводить все шаблоны на новые языки.
  2. Количество новых шаблонов (на новых языках) росло в геометрической прогрессии.

Например, вы начинаете с 10 транзакционных писем. Если нужно перевести на восемь языков каждое из них, писем становится 80. А если нужно внести даже незначительные изменения в вёрстку, это тоже придётся делать 80 раз.

Расскажу, как мы решили эти проблемы за год.

Шаг 1. Навели порядок в хаосе шаблонов

Мы начали с реорганизации: 238 независимых друг от друга шаблонов объединили в единую иерархическую структуру из 34 шаблонов. Она работает по принципу наследования: «родительский шаблон → дочерние шаблоны».

Это отношение «один ко многим»: у одного родительского шаблона (контейнера) может быть много дочерних шаблонов (писем). Но у одного дочернего шаблона бывает только один «родитель».

Родительский шаблон (базовый контейнер)

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

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

Например, мы используем макрос для отображения текста в блоке программы лояльности в зависимости от текущего баланса пользователя. Или для подстановки картинки и названия города в зависимости от его id в базе данных.

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

Пояснение:

  1. Создаём макрос, чтобы отображать названия и картинки городов в зависимости от их id.
  2. Подключаем макрос к базовому шаблону, где содержится вёрстка письма.
  3. Настраиваем дочерний шаблон для рассылки: пишем названия нужных городов, и картинки подтягиваются автоматически.

Промежуточный родительский шаблон (промежуточный контейнер)

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

Пояснение:
Вёрстка промежуточного шаблона — это огромная «простыня» кода. На рендере видим весь набор блоков, которые можно использовать в этом шаблоне.

Дочерний шаблон (письмо)

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

Варианты связки дочернего шаблона и базового контейнера
В схеме иерархии шаблонов я указала, что в промежуточный контейнер мы передаём блоки, нужные для данного типа письма. Способов передачи может быть два: 1) перечисляем только те блоки, которые нужно включить в письмо; 2) перечисляем только те блоки, которые нужно убрать из письма. Мы выбрали второй способ.

Итого

Вложенная структура позволяет централизованно управлять всем текстовым контентом в автоматических письмах и не множить шаблоны. А заодно и ошибки — куда же без них.

Шаг 2. Интегрировали ESP с сервисом переводов

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

Правда, сначала этот контент нужно создать. Для этого мы связали MailOTA с платформой локализации OneSky. Основные преимущества сервиса — профессиональные переводчики (люди, а не машина!), 50 языков в арсенале, автоматический экспорт и импорт текстов. ETG уже давно использует OneSky для локализации своих сайтов. С осени прошлого года мы интегрировали OneSky с емейлами, чтобы обеспечить единство коммуникации и автоматизировать рутину.

Каждый час MailOTA проверяет родительские шаблоны и забирает из них строки текста для перевода. Чтобы MailOTA знала, какие строки отправить в OneSky, мы используем синтаксис {% trans %} Hello World! {% endtrans %}.

<table border="0" cellpadding="0" cellspacing="0" style="border-spacing: 0; font-family: sans-serif; mso-table-lspace: 0pt; mso-table-rspace: 0pt; text-align: left;">
<tr>
<td width="540" style="color: #232426; font-family: 'Arial', sans-serif; font-size: 14px; font-weight: normal; line-height: 23px; mso-line-height-rule: exactly; padding: 0 0 25px;">
<ul style="margin: 0; padding: 0;">
<li style="margin: 0 0 10px; list-style: disc inside;">
{% trans %}When you choose to pay at the hotel, points will be credited to your account up to 60 days after checkout.{% endtrans %}
</li>
<li style="margin: 0 0 10px; list-style: disc inside;">
{% trans %}When you choose to pay at the time of booking, points will be credited to your account up to 5 days after checkout.{% endtrans %}
</li>
<li style="margin: 0; list-style: disc inside;">
{% trans %}Starting from your second eligible booking, you can pay up to 50% of the total cost of the booking using your points.{% endtrans %}
</li>
</td>
</tr>
</table>
Технический процесс включает четыре этапа:

  1. Cтроки текста внутри обёртки {% trans %} сохраняются в .po-файл. Для каждой переводимой строки этот файл содержит пары msgid/msgstr (ключ/значение), где msgid — исходная строка, а msgstr — переведённая строка. Для каждого языка, на который нужно перевести текст, создаётся своя пара msgid: msgstr.
  2. MailOTA отправляет .po-файл в наш централизованный сервис переводов L10n. Это посредник, который берёт на себя всю работу по обмену текстовыми файлами между MailOTA и OneSky.
  3. L10n отправляет .po-файл в OneSky. Переводчики добавляют тексты в msgstr-значения для каждого msgid-ключа. Затем .po-файлы уже с переводами отправляются обратно в MailOTA — тоже через L10n.
  4. MailOTA сохраняет полученные файлы в базу данных и в кэш с разбивкой по языкам. Если впоследствии в переводах что-то меняется, то при их синхронизации между L10n и MailOTA кэш сбрасывается.


Так мы готовим переводы для всех текстов в базовых шаблонах. В момент отправки определённого письма с определённым текстом MailOTA, зная язык пользователя, забирает из кэша строки на этом языке и подставляет их в шаблон. В результате разные пользователи получают один и тот же шаблон, но на своём языке.

Шаг 3. Упростили процесс тестирования

Чтобы контролировать полноту перевода, на странице каждого шаблона есть раздел Translation Progress. Он показывает текущее состояние локализации на каждый язык. Если по какому-то языку прогресс меньше 100% (то есть текст для письма не переведён), то пользователю отправляется письмо на дефолтном языке. В нашем случае это английский.

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

Для визуальной проверки писем на разных языках наша продуктовая команда добавила в MailOTA удобный сервис Mail Demos. Сервис работает следующим образом:

  1. В разделе тестирования шаблона я указываю тестовые данные в формате JSON (например, емейл-адрес, Ф. И. О. пользователя, название отеля, даты заезда и т. д.), с которыми хочу «срендерить» письмо. Таких JSON может быть несколько — чтобы тестировать рендер пользовательских данных в зависимости от разных условий и циклов.
  2. MailOTA выполняет рендер шаблона с этими параметрами. Результат рендера я открываю в сервисе Mail Demos.
  3. С помощью переключалки по языкам я вижу, как письмо выглядит на разных языках. Если замечаю «шероховатости» — исправляю.
  4. Кроме того, я могу открыть коллегам доступ к шаблону, если считаю, что нужна дополнительная проверка контента.

Наши результаты за год

1. Ускорили локализацию транзакционных и триггерных писем. Мы запускаем письма на новом языке одновременно с появлением этого языка на сайте.

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

3. Уменьшили число ручных ошибок в текстах и вёрстке, научились экономить силы на управлении всей массой автоматических емейлов и в результате повысили качество коммуникации с пользователями.

Поделиться статьёй
Подписаться на рассылку