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