GOGYM — контент-сервисы

Backend CMS был разработан с нуля вместе с моделями данных и API. Его задача — не просто хранить записи из админ-панели, а безопасно провести контент через весь жизненный цикл: принять настройки, дать возможность изменить и проверить их, а затем вернуть мобильному приложению актуальную коммуникацию для конкретного пользователя.

На этой основе работали InApp-сообщения, stories, баннеры на разных экранах, пользовательские сегменты и A/B-эксперименты. Все механики использовали общую инфраструктуру, но сохраняли собственные правила и сценарии управления.

Сервисный слой был построен на Node.js и Express.js. MongoDB использовалась для моделей динамического контента, правил сегментации и конфигураций экспериментов, где структура должна была развиваться вместе с продуктом.

API поддерживал операции получения, создания и изменения настроек, необходимые CMS и мобильному клиенту. Медиаматериалы для stories, баннеров и InApp хранились через MinIO, что отделяло работу с файлами от основной логики контентных сущностей.

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

Такое разделение не перегружало MongoDB несвойственными ей задачами и позволяло развивать сегментацию и контентные сценарии независимо от интерфейса CMS.

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

Сервисная часть поддерживала создание, изменение, проверку и использование сегментов, а UI давал маркетологам и аналитикам контроль над этим процессом. Настройка, которая раньше могла занимать неделю и требовала разработчиков, стала выполняться примерно за 10 минут.

Отдельная система A/B-тестирования связывала варианты коммуникации с пользовательскими сегментами. Backend хранил конфигурацию эксперимента, применял её при выдаче динамического контента и предоставлял данные для просмотра результатов в CMS.

Маркетинг мог повторно использовать механизм для разных кампаний вместо разработки одноразовой логики под каждую гипотезу. A/B-тестирование стало частью контентной платформы рядом с InApp, stories и баннерами.

Компоненты backend-платформы упаковывались в Docker-контейнеры и разворачивались в Kubernetes. Это давало воспроизводимое окружение для сервисов и их инфраструктурных зависимостей — MongoDB, Redis, Elasticsearch и MinIO.

Контентные механики развивались независимо от релизов мобильного приложения: изменения сервисов и CMS можно было доставлять своим циклом, сохраняя стабильные контракты для клиента.

GOGYM получил единую backend-основу для динамических коммуникаций и экспериментов. Собственная InApp-система исключила необходимость стороннего решения, а сегментация существенно сократила расходы на платные инструменты.

Адаптация контента для разных групп пользователей дала рост вовлечённости на 30%. Главное изменение процесса — маркетологи и аналитики получили возможность управлять коммуникациями и аудиториями самостоятельно, а разработчики сосредоточились на развитии платформы вместо ручной настройки каждой кампании.