GOGYM CMS — контент
Senior JavaScript Fullstack Developer
О проекте
В роли Senior JavaScript Fullstack Developer я с нуля спроектировал и реализовал frontend внутренней CMS GOGYM. Система превратила выпуск контента из цепочки задач для разработчиков в самостоятельный рабочий процесс маркетинга: специалист создаёт InApp-сообщение, stories или баннер, сразу проверяет результат в полном предпросмотре, выбирает сегмент и вариант A/B-теста, а затем публикует кампанию. Основной интерфейс построен на React, Vite, MUI и Redux Toolkit; для отдельного модуля управления сегментами использовались Next.js, MUI и Redux Toolkit.
Дать маркетингу управление контентом без очереди к разработчикам
Динамические коммуникации в приложении требовали слишком длинного цикла: идею нужно было передать в разработку, согласовать отображение, дождаться реализации и отдельно проверить результат. Даже небольшое изменение текста или аудитории могло растянуть выпуск кампании на несколько дней.
Я разработал CMS как self-service продукт для маркетинга. В одном интерфейсе сотрудник мог подготовить контент, настроить правила показа, увидеть его глазами пользователя и опубликовать без ручного изменения приложения и постоянного участия инженеров.
- Самостоятельная настройка кампаний
- Единый процесс создания и проверки
- Предпросмотр до публикации
- Сокращение количества ручных согласований
Интерфейс, построенный вокруг рабочего процесса маркетолога
Frontend CMS я спроектировал и реализовал с нуля на React и Vite. MUI стал основой визуальных компонентов, а Redux Toolkit — предсказуемого состояния сложных редакторов, фильтров, черновиков и предпросмотра.
Интерфейс не повторял структуру backend-моделей, а вёл пользователя по понятному сценарию: выбрать тип коммуникации, заполнить контент, настроить аудиторию и условия, проверить результат и только затем опубликовать. Для управления сегментацией был создан отдельный модуль на Next.js, MUI и Redux Toolkit.
- React + Vite как основа CMS
- MUI-компоненты и единые формы
- Redux Toolkit для состояния редакторов
- Next.js-модуль управления сегментами
Полный preview вместо проверки после публикации
Система InApp-сообщений была разработана с нуля на трёх уровнях: отображение в мобильном приложении, создание и изменение в CMS и сервисы для хранения, настройки и доставки. В этом кейсе ключевой фокус — рабочее место, связывающее эти уровни в единый пользовательский сценарий.
Редактор позволял настроить содержание и поведение сообщения, выбрать аудиторию и сразу увидеть итоговый вид до отправки. Специалист маркетинга мог за несколько минут собрать рекламную или информационную коммуникацию и проверить её без тестовой сборки приложения.
- Создание и редактирование InApp-сообщений
- Синхронный предпросмотр результата
- Настройка условий отображения
- Публикация без новой версии приложения
Stories и баннеры для разных экранов приложения
CMS объединила управление несколькими форматами динамического контента. Маркетинг мог создавать и обновлять stories, а также размещать баннеры в разных точках мобильного приложения, не превращая каждый новый материал в отдельную frontend-задачу.
Для каждого формата интерфейс сохранял общий принцип: настройки находятся рядом с визуальной проверкой, а пользователь понимает, где, для кого и в каком виде появится материал. Это снижало риск ошибок на этапе согласования.
- Управление stories
- Баннеры на разных экранах
- Единый подход к статусам и настройкам
- Предпросмотр каждого формата
Отдельная точка входа для каждого сценария
CMS была разделена на понятные продуктовые модули. Специалист выбирал не техническую сущность, а задачу: обновить контент приложения, настроить баннер главного экрана или собрать раздел «Что нового» со stories.
Такое разделение сокращало время поиска нужного инструмента и позволяло развивать каждый формат независимо, сохраняя общий подход к формам, preview и публикации.
Конструктор аудитории вместо недели разработки
Для маркетологов и аналитиков появился отдельный механизм создания, изменения и проверки пользовательских сегментов. В интерфейсе можно было собрать правила, проверить настройку и подготовить сегмент к использованию в контентной кампании.
То, что раньше требовало постановки задачи разработчикам и могло занимать до недели, стало настраиваться примерно за 10 минут. Команда маркетинга получила контроль над аудиторией коммуникаций без изменения кода.
- Создание и изменение правил сегмента
- Проверка настройки до запуска
- Использование сегментов в коммуникациях
- Настройка примерно за 10 минут
A/B-тестирование как часть того же процесса
Механизм A/B-тестов был вынесен в управляемый продуктовый сценарий. Пользователь CMS мог подготовить варианты контента, связать эксперимент с нужным сегментом, проверить конфигурацию и после запуска работать с результатами.
Эксперименты перестали быть разовыми техническими задачами. Они стали повторяемым инструментом для проверки гипотез вместе с InApp-сообщениями, stories и баннерами.
- Настройка вариантов эксперимента
- Связь A/B-теста с сегментами
- Проверка конфигурации перед запуском
- Просмотр результатов в рабочем интерфейсе
От нескольких дней согласований — к пяти минутам
CMS стала самостоятельным внутренним продуктом, а не технической формой поверх базы данных. Она связала контент, аудитории, эксперименты и mobile-preview в один понятный процесс для маркетинга.
Согласование и выпуск контента сократились с нескольких дней примерно до пяти минут. InApp-механики и динамическая адаптация контента дали рост вовлечённости пользователей на 30%, при этом ежедневная работа с системой больше не требовала участия разработчиков.