Push-уведомления — жизненно важный маркетинговый инструмент для всех, у кого есть мобильное приложение.
Это лучший способ общаться с вашими пользователями, отправляя срочные сообщения на их мобильные телефоны.
Мобильное приложение может отправить пользователю push-уведомление, представляющее собой краткое всплывающее сообщение, которое появляется на его смартфоне, даже если приложение не открыто.
Эти оповещения могут включать напоминания, обновления, скидки и многое другое.
Они созданы, чтобы привлечь внимание пользователей. Заголовок, сообщение, изображение и URL-адрес — все это возможные компоненты push-уведомления. Смайлики, логотипы и другие вещи также могут быть их частью.
Операционные системы, такие как Apple OS и Google Android, имеют различные интерфейсы для push-уведомлений.
Push-уведомления можно использовать для повышения вовлеченности, повышения использования приложения, влияния на конверсию и многого другого.
Варианты действительно безграничны.
Push-уведомления для мобильных устройств, также известные как push-уведомления для мобильных устройств, могут дополнить использование таких каналов, как электронная почта, SMS и онлайн-push-уведомления, предоставляя ряд особых преимуществ.
В этом посте вы получите краткое описание службы уведомлений, а также информацию о ее целях, высокоуровневом дизайне, специальных функциях и многом другом.
Цель
Разработать службу уведомлений, которая может эффективно распространять сообщения от продукта к пользователю по различным каналам.
Требования:
- API отправки: опубликуйте авторизованную конечную точку, чтобы любой серверный модуль и микрослужба могли начать доставлять уведомления.
- Совместимые каналы: поддержка доставки оповещений по любому каналу, который публикует API, например по электронной почте, текстовым сообщениям и push-уведомлениям.
- Пользовательские настройки: разрешить пользователям выбирать свои пользовательские настройки для каждого канала и уведомления.
- Ограничения соответствия нижестоящих услуг: избегайте e-mail или служба SMS ограничена или остановлена.
- Масштабируемость: разрешить (теоретически) бесконечное горизонтальное масштабирование.
Архитектура высокого уровня
Допустим, ваш код должен кого-то уведомить:
- Конечная точка POST/send вызывается вашим кодом. Для каждого доступного канала запрос включает идентификатор пользователя получателя, тип уведомления и его содержимое.
- Поток учетных данных клиента OAuth2 используется конечной точкой /send для аутентификации запроса.
- Затем из базы данных запрашиваются варианты уведомлений пользователя. Настройки показывают, подписан ли пользователь на определенный канал и уведомления.
- Из базы данных он будет считывать характеристики пользователей, такие как адреса электронной почты и номера телефонов.
- Эта конечная точка создаст объект сообщения, который включает характеристики пользователя, каналы и контент для конкретного канала. Однако он не будет включать деактивированные каналы. Затем сообщение доставляется в службу разветвления.
- Входящие сообщения распределяются по очередям заданий через службу разветвления. Однако существует фильтрация, позволяющая игнорировать очереди заданий для каналов, не указанных в сообщении.
- Каждый канал имеет процессор и рабочую очередь. Процессор берет задачу, а затем запрашивает соответствующую услугу, такую как транзакционная электронная почта или служба SMS.
Основные элементы архитектуры
POST/отправлено
Вы могли заметить, что в запрос к этой конечной точке включается только идентификатор пользователя, а не адрес электронной почты или номер телефона. Это позволяет службам уведомлений оставаться анонимными для ваших пользователей.
Для обеспечения масштабируемости конечная точка размещается за балансировщик нагрузки.
Обычная проверка подлинности пользователя не обеспечивает защиту конечной точки.
Вы должны использовать отдельный метод аутентификации, известный как поток учетных данных клиента OAuth2, используемый для связи между серверами, поскольку служба, которая отправляет запрос, является самим программным обеспечением.
Ваше приложение будет предоставлять уведомления во многих разных местах. Вы можете использовать функцию отправки практически где угодно, например, из новой кодовой базы или рабочего процесса сборки, реализовав ее как конечную точку за балансировщиком нагрузки, что гарантирует ее независимую масштабируемость.
PUT/пользовательские настройки
Используйте пару «ключ-значение» или базу данных NoSQL, которая чрезвычайно масштабируема. Отформатируйте записи следующим образом: КЛЮЧ: пример идентификатора пользователя: образец идентификатора уведомления, ЗНАЧЕНИЕ: ["электронная почта", "состояние: истина", "SMS", "состояние: ложь", канал: "электронная почта", "электронная почта", состояние : истинный
Если в записях присутствуют «ложные» значения, конечная точка передачи исключит соответствующий канал из сообщения, доставляемого на разветвление. Если для канала нет записи, пользователь явно не указал свои предпочтения. Вы должны согласиться на дефолт в этом сценарии.
Пользователь может изменять данные в базе данных пользовательских настроек, используя ваш пользовательский интерфейс и обычную конечную точку, которая защищена вашими стандартными процедурами аутентификации.
Пользователи будут раздражаться и будут вынуждены обозначать ваши оповещения как спам или отключать их, если вы не предоставите им возможность изменить настройки уведомлений. В результате ваш пользовательский интерфейс пострадает еще больше, а службы доставки электронной почты или SMS могут приостановить действие вашей учетной записи.
Разветвитель
Fanout копирует сообщение и распределяет его по разным адресам. Они доступны по цене и очень масштабируемы. Используйте SNS в AWS. Используйте Pub/Sub в Azure, а также темы и подписки в Google Cloud Platform.
Чтобы предотвратить отправку бессмысленных сообщений в очереди заданий исключенных каналов, вы можете настроить фильтрацию между очередями разветвления и рабочими очередями. Например, в AWS SNS вы можете указать, что очередь заданий электронной почты должна получать сообщение разветвления только в том случае, если в поле «каналы» указано значение «электронная почта».
Даже если бы вы могли создать код для отправки идентичного сообщения в требуемые очереди заданий, разветвление более эффективно и требует меньшего количества кода. Fanout также предлагает удобство добавления и удаления очередей, что позволяет расширять и реорганизовывать каналы.
Обработка задания
Сообщения хранятся в очередях в ожидании обработки вашими обработчиками заданий. Они также доступны по цене и очень масштабируемы. Процессоры заданий — это фрагменты кода, которые обрабатывают сообщения из очередей заданий. В зависимости от объема сообщений в очереди они могут масштабироваться.
Обработчик заданий должен сделать вызов API к соответствующему поставщику, чтобы доставить уведомление в нашем сценарии через службу транзакционной электронной почты.
Большинство поставщиков услуг электронной почты, SMS и подобных сообщений предъявляют жесткие требования к количеству и качеству отправляемых вами сообщений. Кроме того, вы хотите тщательно изучить их и настроить подходящие процедуры. Вот наш совет, как избежать исключения из AWS SES.
Вы можете определить максимальное количество обработчиков заданий, чтобы не допустить превышения лимитов ставок служб доставки.
Дальнейшие улучшения
Вы можете взглянуть на кучу этих предметов.
- Им нужны собственные API, таблицы и т. д., чтобы иметь масштабируемую службу уведомлений в приложении.
- Сбор и отображение отчета об открытии/клике
- Удаление содержимого уведомлений из кода и предоставление вашему продукту и команде дизайнеров возможности визуально изменять предупреждения без изменения кода.
- Без изменения какого-либо кода ваша команда может использовать панель инструментов для активации или отключения уведомлений для определенных каналов.
Преимущества Push-уведомлений
- Увеличьте взаимодействие пользователей: обновления и свежие материалы будут поддерживать интерес ваших пользователей.
- Повысьте видимость связи: гарантируйте, что ваши сообщения будут получены немедленно, даже когда люди неактивны. Отправляйте срочные уведомления и предоставляйте пользователям беспроблемный опыт.
- Поддерживайте удержание: используйте хорошо видимые push-уведомления, чтобы побудить пользователей вернуться. Вы можете увеличить удержание пользователей и сократить отток, возвращая клиентов на свой веб-сайт и в приложение.
- Повышение конверсии. Создавая push-кампании с наградами, акциями, скидками или другими предложениями в приложении, вы можете увеличить продажи.
- Масштабируйте свое предприятие. Ваш коммуникационный подход должен масштабироваться по мере расширения вашей аудитории. По мере расширения клиентской базы push-уведомления становятся эффективным способом оставаться с ними на связи.
- Сделайте пользовательский опыт связным (UX): отправляя потребителям оповещения о транзакциях, чтобы информировать их и обеспечивать беспрепятственный кросс-канальный опыт, вы можете уменьшить трения на протяжении всего пути клиента.
Заключение
В заключение мы получили знания об архитектуре масштабируемого сервиса push-уведомлений. Мы также рассмотрели инструменты, предоставляемые всеми основными поставщиками облачных услуг, чтобы вы могли основывать свои уведомления на них.
Несмотря на то, что я изо всех сил старался предоставить вам обзор архитектуры системы push-уведомлений, за кулисами происходит гораздо больше.
Я искренне надеюсь, что вы найдете эту информацию полезной и будете использовать ее с пользой.
Оставьте комментарий