Разработка сервиса push-рассылок для аптечной сети Фармленд

Современный мир информационных технологий невозможно представить без эффективных механизмов коммуникации с пользователями. Один из таких механизмов - сервисы пуш-уведомлений, которые позволяют компаниям достигать своей аудитории в реальном времени. В данной статье мы рассмотрим процесс разработки сервиса пуш-рассылок на примере нашего кейса для федеральной аптечной сети Фармленд, его ключевые компоненты, технологии и методы, а также обсудим практические аспекты его реализации.

Существует несколько способов связи с клиентами:

Пуш-уведомления же обладают несколькими преимуществами по сравнению с другими способами коммуникации:

Пуш-уведомления — один из самых эффективных способов поддерживать связь с клиентами через мобильные приложения.

Архитектура сервиса пуш-рассылок состоит из серверной и клиентской частей.

2. Клиентская часть (Swift и Kotlin):

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

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

Кроме того, мы разработали отдельный микросервис для управления пуш-рассылками.

Сервис пуш-рассылок рекомендуется размещать на отдельном сервере по нескольким причинам:

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

На данный момент мы отправляем более 1 миллиона пуш-уведомлений по всей базе пользователей. Однако в первой версии нашего приложения мы не учитывали сразу такой объем данных, так как наша первоочередная задача заключалась в создании минимально жизнеспособного продукта (MVP). В этой статье мы рассмотрим, как развивался функционал MVP для сервиса пуш-рассылок и с какими проблемами мы столкнулись.

При запуске приложения, пуш-уведомления отправлялись по статусам заказов при их изменении, а также по всей базе пользователей в случае проведения акций и предложений. Мы предусмотрели возможность отправки пушей только определенным типам устройств: iOS или Android. Отправка сообщений происходила последовательно из очереди.

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

Если очередь содержит слишком много задач и они не успевают обрабатываться последовательно, можно использовать несколько стратегий для решения этой проблемы:

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

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

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

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

В ходе работы перед нами стояли следующие задачи и способы их решения:

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

Мы разработали возможность отправки персонализированных рассылок по сегментам пользователей. Для этого мы используем разнообразную информацию о действиях пользователей в системе - их заказы, просмотры товаров, брошенные корзины, избранные товары, историю поиска и многое другое. Эта информация позволяет нам создавать уникальные предложения и скидки для каждого пользователя.

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

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

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

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

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

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

Ставьте лайки и подписывайтесь на наш блог! У нас много интересных дизайн-проектов, кейсов и экспертного материала по разработке веб-проектов любой сложности!