Персонализация email-рассылок без HTML в Mindbox

Как я перенёс персонализацию из HTML в интерфейс конструктора от подстановки данных до автоматического заполнения продуктовых сеток

Продукт

Конструктор email-рассылок Mindbox

Этап

Выход из MVP

Срок

3 месяца

Моя Роль

Product designer – вёл дизайн направление задачи: от систематизации данных и сценариев до интерфейсов подстановки, форматирования и продуктовых сеток

Команда

Продакт-менеджер, дизайнер архитектор, 3 разработчика

Результат в цифрах

113 клиентов начали запускать 60% рассылок на новом конструкторе

Больше 60% новых рассылок запускают в конструкторе

было 67 → стало 113 · цель 100

23 клиента начали запускать 100% рассылок на новом конструкторе

Все новые рассылки запускают в конструкторе

было 8 → стало 23 · цель 20

Написано 2 истории успеха для журнала Mindbox (раз, два, три)

Помогают продажам подтверждать ценность продукта

было 0 → стало 3 · цель 1

Срок замера Adoption-метрик 2 месяца после релиза.

По замеру с клиентом сборка письма с заказом или списком товаров стала примерно в 5 раз быстрее.

Почему клиентские кейсы важный результат: они фиксируют измеримый эффект от продукта – рост выручки, снижение затрат или ускорение работы. Маркетинг может публиковать такие истории успеха на сайте, а продажи – показывать или отправлять их потенциальным клиентам как доказательство ценности продукта.

Контекст

Mindbox хранит большое количество данных о клиентах: персональные данные, историю покупок и заказов, просмотренные товары, избранное, рекомендации и другие события. Эти данные можно использовать в email-рассылках, чтобы делать письма персонализированными: обращаться к клиенту по имени, показывать его заказ, выводить товары, которые он смотрел или добавил в избранное, рекомендовать релевантные продукты.

Раньше такие сценарии можно было реализовать только через код в HTML-вёрстке. Пользователю нужно было разобраться в документации, изучить несколько статей и вручную добавлять специальные конструкции в HTML.

Большинство клиентов не могли сделать это самостоятельно. Им требовалась помощь менеджера на нашей стороне, из-за чего запуск рассылок занимал больше времени, команда тратила ресурсы на поддержку типовых сценариев, а клиенты не могли оперативно вносить правки в свои рассылки.

Бизнес мотивация

Клиентам нужно быстро и самостоятельно запускать персонализированные рассылки, но существующий сценарий требовал технических знаний и часто зависел от помощи менеджеров. Это замедляет запуск писем, создает нагрузку на команду и снижает ценность встроенного конструктора.

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

Мой вклад

  • Разобрал дерево переменных Mindbox, связи между сущностями и текущую логику подстановки данных.
  • Систематизировал персональные, системные и продуктовые параметры и сценарии их использования.
  • Спроектировал выбор, вставку и последующее редактирование тегов подстановки.
  • Описал правила форматирования для разных типов данных.
  • Изучил способы расчёта цен, скидок и итоговых сумм и выделил рекомендуемые сценарии.
  • Подготовил логику и макеты автоматического заполнения продуктовой сетки.
  • Проработал вывод изображений и поведение товарных данных внутри сетки.

Объём решения: клиентские и системные данные · форматы · цены и скидки · редактируемые теги · продуктовые сетки

Подробнее про ключевые проблемы и решения

1. Превратил сложное дерево данных в понятную систему

Проблема. В Mindbox хранилось множество параметров, связанных с клиентами, заказами, покупками, просмотрами и рекомендациями. Чтобы использовать их в письме, клиенту нужно было разбираться во внутренней структуре данных и документации. Как минимум вот эти статьи (раз, два, три) и дерево переменных (пример прохода по дереву)

Решение

Я изучил клиентские сценарии, дерево переменных, связи между сущностями и существующие HTML-конструкции. Затем разложил данные по типам и сценариям, собрал схемы и таблицы и определил, какие параметры нужно показывать в интерфейсе конструктора.

Что изменилось: сложная внутренняя модель стала основой понятного пользовательского сценария, а интерфейс получил единые правила работы с данными.

Открыть макет в Figma ↗

2. Перенёс подстановку данных из HTML в интерфейс

Проблема. Для персонализации письма клиентам приходилось вручную добавлять специальные конструкции в HTML. Большинство не могло сделать это самостоятельно и обращалось за помощью к менеджерам.

Решение

Я спроектировал механизм выбора и вставки параметров прямо в письмо. Пользователь может добавить данные о человеке, заказе, покупке, просмотре, избранном или рекомендации, а для даты, числа, текста и других типов настроить подходящий формат отображения.

Что изменилось: базовые сценарии персонализации стали доступны без документации, ручной вёрстки и знания синтаксиса Mindbox.

Открыть макет в Figma ↗

3. Сделал теги подстановки редактируемыми

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

Решение

Мы сделали тег полноценным объектом конструктора. После добавления пользователь может выбрать его в письме, открыть настройки, изменить формат отображения или заменить параметр.

Что изменилось: персонализацию стало проще и безопаснее редактировать, а встроенный конструктор получил сценарий, которого не было у изученных конкурентов.

Открыть макет в Figma ↗

4. Автоматизировал заполнение продуктовых сеток

Проблема. Чтобы вывести несколько товаров, заказов или рекомендаций, нужно было писать цикл в HTML. Это требовало технических знаний, занимало время и усложняло дальнейшее редактирование письма.

Решение

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

Что изменилось: сценарий, который раньше требовал кода и помощи менеджера, стал собираться в интерфейсе; по замеру с клиентом – примерно в 5 раз быстрее.

Открыть макет в Figma ↗

5. Упорядочил работу с ценами и скидками

Проблема. Скидку можно было рассчитать на единицу товара, строку заказа или весь чек, а также через разные промо-механики. Клиенты по-разному выводили цены в письмах – часто так, как удалось разобраться самостоятельно.

Решение

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

Что изменилось: в конструкторе появились согласованные сценарии работы с ценами вместо набора разрозненных способов.

Открыть макет в Figma ↗

Результаты подробнее

🥇 Adoption ≥ 60%

Что измеряли: количество средних и крупных клиентов, у которых больше 60% новых email-рассылок запускается во встроенном конструкторе.

  • Было: 67 клиентов
  • Цель: 100 клиентов
  • Результат: 113 клиентов
  • Срок: 2 месяца после релиза

Влияние. Ещё 46 клиентов начали использовать конструктор как основной инструмент для большей части рассылок. Цель была превышена на 13%, что показало рост регулярного использования продукта после запуска персонализации.


🥇 Full Adoption

Что измеряли: количество средних и крупных клиентов, которые запускают во встроенном конструкторе 100% новых email-рассылок.

  • Было: 8 клиентов
  • Цель: 20 клиентов
  • Результат: 23 клиента
  • Срок: 2 месяца после релиза

Влияние. Количество полностью перешедших клиентов выросло почти в три раза, а цель была превышена на 15%. Для этих клиентов конструктор стал полноценной заменой ручной вёрстке и сторонним инструментам.


🥇 Скорость создания персонализированной рассылки

Что измеряли: время сборки письма с данными заказа или списком товаров до и после появления новых сценариев в интерфейсе.

  • Результат: примерно в 5 раз быстрее
  • Метод: замер совместно с клиентом

Влияние. Сценарий, который раньше требовал изучения документации, работы с HTML и помощи менеджера, стал собираться непосредственно в конструкторе. Это сократило время запуска рассылок и нагрузку на команду поддержки клиентов.


🥇 Клиентские истории успеха

Что измеряли: количество клиентских кейсов, в которых зафиксирован измеримый эффект от использования продукта.

  • Было: 0 кейсов
  • Цель: 1 кейс
  • Результат: 2 кейса

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


🥇 Что изменилось для продукта

Персонализация перестала быть технической задачей, зашитой в HTML. Клиенты получили управляемый интерфейс для работы с данными, форматами и продуктовыми сценариями, а команда сократила зависимость от ручной поддержки типовых рассылок.

Главный вывод: глубокая интеграция становится конкурентным преимуществом, когда сложные возможности системы превращены в понятные сценарии, а их эффект подтверждён результатами реальных клиентов.