Push token что это

Пуш-уведомления в RuStore: как мы сделали свой транспорт на замену Google Firebase

Кирилл Алексеев работает в VK, руководит несколькими командами разработки бэкенда в Почте Mail.ru. Далее, рассказ будет от его имени. Он расскажет, как на запуске RuStore делали пуш-уведомления, а конкретно транспорт на замену Google Firebase для Android. Сделает обзор публичной части сервиса, погрузит в детали архитектуры бэкенда сервиса пушей. Пояснит, как устроены их мобильные SDK, как интегрировали пуши RuStore в Почту Mail.ru и почему они не лягут надолго. Покажет, что у них получилось и как этим можно пользоваться. На запуске бета-версии RuStore было важно, чтобы продукт отвечал требованиям разработчиков и имел минимальную необходимую функциональность. Например, позволял связаться с пользователем с помощью пуш-уведомлений. Для этого активно переиспользовались технологии и знания изнутри.

Зачем делать свой транспорт пушей

Все пуш-уведомления отправляются на мобильные устройства через API операционных систем. У Google и Apple есть свои API. Чтобы послать пуш-уведомление на телефон Android, нужно сделать запрос на бэкенд Google. Дальше бэкенд Google доставит пуш на мобильное устройство.

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

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

Чтобы решить проблему, для начала мы зафиксировали требования к сервису, которые нужно прорабатывать:

• Сервис должен предоставлять возможность подписываться и отписываться от пушей для конкретного приложения на конкретном физическом устройстве.
• Должна быть возможность с бэкенда отправлять пуши по заданному токену на конкретное приложение на конкретном физическом устройстве, причём пуш должен дойти мгновенно, если устройство находится в сети.
• Если устройство находится оффлайн, то мы должны сохранить пуш во временном хранилище на диске и доставить его, когда устройство снова появится в сети.
• Сервис должен быть надёжным. Мы должны переживать уход одного Дата-центра из трёх, при этом насыпать как можно меньше ошибок, терять как можно меньше пушей и не создавать их дубликаты.
• Сервис должен быть безопасным. Не должно быть возможности с наскока прочитать чужие пуши или отправить пуш в чужое приложение. К примеру, бэкенд Почты отправит пуш в бэкенд Облака. И мы должны быть устойчивы к атакам типа Denial of Service.
• Простая интеграция в текущую схему работы с пушами. Было бы очень хорошо, если бы наш сервис нёс минимальный overhead на интеграцию в текущую схему, например, чтобы заменить Firebase на наш сервис.

Как выглядит любой пуш-сервис? Есть много похожих сервисов, которые предоставляют такую функциональность. Например, свои у Google, Apple, Huawei. Они все довольно похожи: в каждом есть строка со случайными символами, идентифицирующая конкретное приложение на конкретном физическом устройстве, которая называется пуш-токен.

Сам пуш — это произвольный payload, некий JSON, который пробрасывается на мобильное устройство. Часть полей обрабатываются операционной системой, а часть клиентом, то есть конкретным мобильным приложением.

Например, title: This is a push title. В этом случае на iOS отрисуется пуш с таким title.

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

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

Для iOS мы не нашли возможности гарантировать какую-либо задержку доставки. Нет возможности запускать наш код на iOS устройстве в фоне через конкретные периоды времени. Поэтому iOS мы решили отложить и сконцентрироваться на Android — в котором такая возможность есть.

Обзор публичной части сервиса

Начнём с веб-интерфейса управления пушами приложения в RuStore. Чтобы включить пуш-уведомления в RuStore, нужно пройти в консоль разработчика и включить там пуши.

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

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

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

Как устроены наши мобильные SDK

Наше SDK для Android повторяет интерфейс SDK Firebase. Мы стремимся к drop-in replacement для SDK FCM. У нас есть такие же методы, как у Firebase.

• GetToken — регистрирует и отдаёт наверх приложению новый пуш-токен, чтобы приложение его отправило на свой бэкенд.
• DeleteToken — метод, противоположный GetToken, он инвалидирует существующий токен, и после инвалидации пуши больше не будут по нему ходить.

Также определим несколько коллбэков:

• с onMessageReceived можно перехватить пуши и обработать их произвольным способом;
• с onNewToken узнать о том, что появился новый пуш-токен и пробросить его на бэкенд;
• с onDeletedMessages узнать о потерянных пушах, например, из-за того, что у них истекло время жизни.

Это всё аналогично Google Firebase.

В случае с API мы тоже стремимся к drop-in replacement. Мы повторяем схему запроса и схему ответа Google Firebase. В Firebase есть два типа пушей:

1. notification позволяет отправить пуш, который автоматически отрисовывается ОС;
2. data-пуш позволяет отправить пуш, который не будет автоматически отрисован, но в него можно засунуть какой-то payload, и дальше клиент сам решает, отрисовывать его или нет.

В данном случае будет отправлен пуш с title «Hello, world».

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

Основные компоненты SDK

Наш мобильный SDK состоит из клиентского и хостового SDK.

Хостовая часть встроена в RuStore. Она собирает все пуши на девайсе и рассылает их конкретным приложениям внутри девайса. Из этого следует логичное ограничение — для юзеров, у которых нет RuStore на девайсе, не будут ходить пуши. Но зато мы можем получать все пуши ровно через один WebSocket, и дальше рассылать их внутри девайса, а не держать отдельный WebSocket для каждого приложения, что могло бы, например, потреблять аккумулятор у юзера.

Клиентский SDK — это SDK, который разработчик встраивает в своё приложение, подобно Google Firebase SDK. Он содержит все те методы, которые я перечислял.

Клиентский и хостовый SDK при инициализации запоминают друг друга по package name. Это нужно, чтобы у злоумышленников не было возможности подставить какое-нибудь третье приложение, которое будет притворяться RuStore и перехватывать пуш-токены у клиентского SDK.

Как SDK получает пуши

Когда клиентский SDK выписывает новый пуш-токен, он пробрасывает его приложению, которое перебрасывает его на свой бэкенд. Но также он отправляет этот токен хостовому SDK, чтобы хостовый SDK получал по нему пуш-уведомления.

Когда клиентский SDK передаёт новый пуш-токен хостовому, хостовый SDK добавляет его в свой локальный кэш и начинает по нему получать пуши. Хостовый SDK идёт в наш бэкенд, открывает новый WebSocket и начинает слать запросы на подписку по всем пуш-токенам, которые у него есть. Если запрос на подписку проходит успешно, то дальше в этот WebSocket начинают сыпаться пуши от бэкенда.

В реальности большую часть пушей мы действительно доставляем через WebSocket, причём мгновенно. Но, если телефон офлайн, то WebSocket может не быть, а на Pub/Sub системе сложно реализовать 100% delivery rate. Пуш может потеряться, пока летит до клиента внутри нашей инфраструктуры, поэтому есть ещё вторичный механизм — HTTP-поллинга. Наш хостовый SDK простым HTTP запросом каждые 5 минут ходит на сервер и просит выгрузить те пуши, которые не были получены. Конечно, эти два механизма синхронизируются между собой по ID пушей, дубли пушей не показываются.

Чтобы мы могли получать пуши в фоне с минимальной задержкой доставки, юзер должен нам дать permission на работу в фоновом режиме. В этом случае для него запускается диалоговое окно «РАЗРЕШИТЬ». После этого мы можем работать в фоне, даже если приложение RuStore на телефоне закрыто.

Детали архитектуры бэкенда сервиса пушей

Бэкенд состоит из 6 основных компонентов:

API написано на Go и разворачивается в Kubernetes. Оно ходит в хранилище пуш-токенов, где лежат все зарегистрированные пуш-токены от всех приложений с метаданными по этим пуш-токенам. Хранилище реализовано на базе Redis Cluster.

Также API ходит в хранилище пушей, где хранятся все пуши на диске с TTL, пока за ними не придёт хостовый SDK. Хранилище пушей реализовано на базе Scylla.

Ещё есть хранилище проектов на базе Redis. Там хранятся все зарегистрированные проекты, их идентификаторы, сервисные токены.

Есть Rate Limits, тоже на базе Redis, а также Pub/Sub шина, через которую доставляются пуши через WebSocket. Это наша собственная разработка, о которой мы ещё поговорим.

Обзор хранилища пуш-токенов

По сути, пуш-токен — это словарик в Redis. На изображении токены представлены в сокращённом виде. На самом деле они длиннее. Всё это построено на базе Redis Cluster.

У каждого пуш-токена есть следующие поля:

• Идентификатор проекта, к которому привязан пуш-токен.

• Syn — монотонно возрастающий счётчик пушей по аналогии с TCP. Когда к нам приходит запрос на отправку нового пуша, мы делаем инкремент syn, получаем следующее значение, и это ID пуша.
• Syn_stored — по сути это тоже syn, но минимальный syn, который хранится на диске.

Нам нужно было реализовать возможность хранить ограниченное количество пуш-уведомлений, чтобы хранилище не забилось пушами. Для этого мы храним верхнюю границу (syn) и нижнюю границу (syn_stored). Когда к нам приходит запрос на отправку нового пуша, мы можем прямо в памяти из syn вычесть syn_stored. Так мы получаем, сколько у нас сейчас хранится, и решаем, нужно ли удалять пуши, чтобы освободить место. Мы это делаем в памяти, а не идём каждый раз на диск пересчитывать, сколько пушей в реальности хранится.

По статистике на 1 млн пуш-токенов у нас используется порядка 400 МБ в Redis. Для приложения размера Почта Mail.ru на Android потребовалось бы порядка 10-15 ГБ, чтобы сохранить все пуш-токены в памяти.

Обзор хранилища пушей

Хранилище пушей у нас на базе Scylla, всё хранится на диске. Здесь представлена схема таблицы с пушами.

Для каждого пуша мы храним:

• токен, к которому относится этот пуш;
• его идентификатор, то есть текущее значение syn;
• payload — это сам пуш;
• timestamp — это время создания пуша. В основном используется для статистики.

В терминах Scylla наш первичный ключ — это связка токена и syn.

В данном случае токен выступает как partition key, а syn — как clustering key. Это значит, что по каждому токену все пуши хранятся максимально компактно. Они отсортированы в порядке возрастания монотонного счётчика syn. Это позволяет нам делать эффективные чтения по набору токен и syn_range. Когда приходит очередной поллинг и запрашивает все пуши, начиная с какого-то min syn, у нас это работает довольно эффективно в силу специфики хранения этого в Scylla.

В Scylla нет понятия ведущего и ведомого узла. Там можно писать в любой узел, очевидно, из-за этого могут возникать конфликты на записи. Например, мы попробовали записать в первый узел, произошёл таймаут, мы не знаем, удалось записать или нет. Повторяем во второй узел. Здесь мы записали успешно, но на самом деле в первый узел тоже всё записалось.

Scylla разруливает такие конфликты автоматически по алгоритму LWW (Last Write Wins), то есть остаётся только та запись, у которой timestamp новее. Этот алгоритм не подходит в общем случае для задачи разрешения конфликтов мастер-мастер, но в нашем случае это позволяет by design не иметь дубликаты пушей на повторах.

Логика в API на отправке пуша

Вот пример запроса на отправку пуша.

• header Authorization, который содержит тот самый сервисный токен (сокращённый);
• пуш-токен, по которому отправляется пуш;
• идентификатор проекта (в url);
• title — это «Hello, world!».

Когда отправляется пуш, мы должны провести некоторое количество валидаций.

Первая валидация когда API идёт в хранилище проектов и проверяет, что заданный сервисный токен соответствует тому проекту, в который отправляется пуш. Если эта валидация пройдена, то нужно проверить, что указанный проект соответствует тому пуш-токену, на который пуш отправляется. Для этого мы у пуш-токенов храним project_id. В противном случае злоумышленник мог бы создать свой проект, выписать для него сервисные токены, потом найти пуш-токен, допустим, юзера Почты, и со своим сервисным токеном успешно отправить пуш юзеру почты. Конечно, такого быть не должно.

Если все валидации успешно пройдены, то дальше мы идём уже в хранилище пуш-токенов, делаем инкремент. В Redis это работает атомарно в силу однопоточности. Получаем новый ID пуша. Также мы в той же самой транзакции, в той же самой lua’шке можем проверить разницу между верхней и нижней границей, и понять консистентно с инкрементом счётчика, нужно ли удалять какой-то пуш из хранилища. Соответственно, lua’шка пробрасывает на бэкенд информацию о том, нужно ли удалять один пуш, и, в том числе, значение нового счётчика.

С этим значением нового счётчика API идёт в хранилище пушей и сохраняет там новый пуш с заданным временем жизни. Кстати, в API время жизни задаёт его клиент.

Асинхронно с этим мы идём в Pub/Sub шину и засылаем туда пуш. Если устройство подключено к интернету, есть WebSocket, то пуш будет мгновенно доставлен.

Так выглядит запрос на получение пушей:

Это публичная API, она в интернете, в неё входят все мобилки. Но пользоваться ей напрямую не придётся. Она инкапсулирована за SDK, наш SDK с ней взаимодействует.

Здесь так же есть идентификатор проекта, пуш-токен, для которого нужно получить пуши, и минимальный syn, с которого API должна вернуть все пуш-уведомления.

Когда в API приходит такой запрос, API идёт в хранилище пуш-токенов и смотрит, а есть ли в системе какие-то пуши и какое текущее значение syn. Если syn равен min_syn, значит никаких новых пушей не приходило и нет смысла идти в хранилище пушей, чтобы их получить. Если же syn больше, чем min_syn значит, какие-то пуши приходили, можно их забрать.

На самом деле это довольно важная оптимизация, которая полагается на то, что syn — это монотонно возрастающий счётчик. По нашей статистике примерно 98-99% запросов в Get обрабатываются без похода в хранилище пушей, то есть без похода в диск, а просто из памяти. Если же пуши всё-таки есть, то мы идём в хранилище пушей, забираем все эти пуши и отдаём клиенту. Далее мы асинхронно удаляем те пуши, которые считаем подтверждёнными, чтобы не хранить их на диске.

Важно отметить, что подтверждёнными считаются не те пуши, которые мы только что отправили, а пуши, у которых syn не больше, чем min_syn. Контракт между клиентом и API состоит в том, что если клиент присылает указанный min_syn, то мы считаем, что все пуши до этого min_syn он уже видел и их можно удалять.

Как не забить хранилище неактуальными пуш-токенами

Есть разные причины, по которым пуш-токен может «протухнуть»:

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

Поэтому мы все пуш-токены создаём в хранилище пуш-токенов с наперёд заданным TTL. Спустя указанное время пуш-токен удаляется из Redis автоматически, но только если он действительно не нужен приложению. Мы это понимаем по периодическим GET-запросам.

У поллинга есть несколько вторичных функций. Если к нам периодически приходят GET, то мы автоматически продлеваем время жизни токена. Мы делаем это не на каждый запрос, а раз в сколько-то часов или дней, чтобы не создавать лишнюю нагрузку на мастера хранилища пуш-токенов, потому что TTL мы задаём довольно долгий (порядка месяца).

Почему мы не ляжем (надолго)

Отказоустойчивость на уровне API

Наше API эксплуатируется в Kubernetes. Трафик на него заводится через публичный виртуальный IP-адрес. С этого виртуального IP-адреса нагрузка роутится на несколько машин, на которых стоит связка NGINX + Envoy.

Соответственно, NGINX принимает запрос, проксирует его в Envoy, который дальше его раскидывает по Kubernetes. Kubernetes живёт в 5 Дата-центрах, поэтому уход одного нам точно не страшен. На Envoy настроены health-чеки, он чекает все поды. Если какой-то под оказался на плохой Кубер-ноде, на которой, например, высокий LA, то health-чек сфейлится и под будет выкинут из нагрузки, и она распределится по нормальным подам.

Redis Cluster для хранилища пуш-токенов

Хранилище пуш-токенов у нас на базе Redis Cluster. Благодаря этому мы довольно легко масштабируемся горизонтально. Если кончается запас по CPU или по памяти, то мы пользуемся автоматическим решардингом в Redis. Просто добавляем ноды и кластер автоматически ребалансится.

В случае с чтениями всё даже проще. Мы большую часть чтений направляем на реплики. Поэтому если у нас кончается запас по чтениям, мы просто в Redis Cluster добавляем ещё реплики и начинаем балансировать нагрузку между ними.

Redis Cluster устойчив к уходу одного Дата-центра (конечно, если не засовывать все тачки в один Дата-центр) благодаря механизму автоматического failover. Если какой-то мастер-узел уходит, то оставшееся множество мастеров проводит выборы и из доступных реплик старого и выбирает нового. То есть какая-то реплика промоутится до мастера. Так кластер будет в даунтайме, по крайней мере, на запись, пока не выберется новый мастер. Опыт на практике показывает, что выборы занимают от 15 секунд до минуты и через минуту автоматически кластер снова доступен на запись.

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

Scylla для хранилища пушей

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

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

Мы в Почте Mail.ru активно используем Scylla. Можно посмотреть мой доклад с конференции Scylla Summit. Там я рассказывал о том, как мы добились нагрузки в 250 тысяч запросов в секунду на запись на небольшом кластере Scylla с HDD (у нас было всего лишь 8 узлов).

10 миллионов WebSocket и Go

Лет 5 назад мы разработали сервис Notifier, который отправляет пуши через WebSocket. Мы используем его, чтобы браузерным вкладкам, на которых открыта вкладка со списком писем, доставлять сообщения о новых письмах. Это позволяет нам:

1. Снижать задержку доставки, то есть юзер раньше узнаёт о том, что ему пришло письмо.
2. Уменьшить нагрузку на наш сторадж, то есть не приходится поллить сторадж.

Опытным путём доказано, что этот сервис устойчив к уходу одного Дата-центра. Можно почитать статью на Хабре от первоначального разработчика этого сервиса Сергея Камардина «Миллион WebSocket и Go», но с тех пор у нас нагрузка уже несколько выросла.

Защита от DoS на генерации пуш-токенов

Это ещё одна проблема, которую нам нужно было решить. Наше API на генерацию пуш-токенов доступно в интернете, чтобы любая мобилка могла пойти и сгенерировать себе пуш-токен. Из этого следует очевидная проблема — кто-то может вооружиться curl’ом и пойти забивать нам базу пуш-токенов. Apple и Google тоже решают у себя такую проблему. Наши исследования показали, что они используют для этого секреты, зашитые в физические устройства, проводят по ним авторизацию. У нас такой возможности не было, но у нас есть RuStore на телефоне, там есть авторизация юзера, которой мы решили воспользоваться.

Когда мобильное приложение хочет выписать себе новый пуш-токен, оно берёт o2-токен юзера из RuStore и идёт с ним в специальный сервис Auth-Proxy. Auth-Proxy берёт этот o2-токен и идёт в авторизацию RuStore. Авторизация проверяет токен, если он валидный, то возвращает «ОК». Вместе с «ОК» возвращается user_ID, к которому относится этот o2-токен.

Далее Auth-Proxy идёт в специальный сервис, который генерирует коротко живущие одноразовые токены. Генерирует токен и прикладывает к нему в payload user_ID. Дальше этот промежуточный токен прокидывается по всей цепочке в мобильное приложение.

Теперь мобильному приложению, чтобы выписать себе пуш-токен, нужно взять этот промежуточный токен и пойти в API. API пойдёт в сервис короткоживущих токенов, проверит его, причём запрос будет не идемпотентный. Поскольку токен одноразовый, его нельзя два раза использовать. Если токен валидный, то возвращается «ОК». Вместе с «ОК» возвращается payload, который был в токене. В данном случае это user_ID, к которому относился o2-токен. Дальше API генерирует пуш-токен, пробрасывает его на мобилку.

Таким образом за счёт проверки авторизации мы, как минимум, защитились от того, что кто-то возьмёт curl и пойдёт генерировать нам нагрузку. Но если кто-то задался целью, ему будет не сложно достать свой o2-токен из RuStore и с ним ходить к нам, создавать проблемы.

Поэтому у нас во всей цепочке используется user_ID. На API он сохраняется в рейтлимитилку. Если кто-то с одним и тем же o2-токеном будет ходить и пытаться генерировать пуш-токены, то он просто упрётся в лимиты.

Как мы интегрировали пуши RuStore в Почту Mail.ru

Не сюрприз, что первым большим потребителем разработанного сервиса стала Почта Mail.ru. Мы решили посмотреть, нормально ли работает то, что мы разработали. Мы стали параллельно запускать пуши по 2 каналам: по каналу с Firebase и по нашему каналу пуш-уведомлений RuStore. Мы замеряли, сколько пушей приходит через каждый из каналов.

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

Следующим этапом мы собираемся показывать первым тот пуш, который пришёл раньше. То есть если пуш придёт в Firebase, то покажем юзеру его, если в RuStore, то его, а на клиенте будет производиться дедупликация по ID пуша.

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

Мы, разработчики Почты Mail.ru, выступали для своего сервиса пуш-уведомлений RuStore потребителями, и могли оценить, насколько сложно его интегрировать.

Для включения пушей достаточно просто сделать несколько кликов в веб-интерфейсе, так сгенерируются ID проекта и сервисные токены.

Интерфейс нашего SDK повторяет интерфейс SDK FCM, встраивать его было несложно. А вот в случае с API получилось, что мы переиспользовали коннектор от Firebase, заменили в нём хост, и у нас всё заработало из коробки.

Какая польза от интеграции? За счёт старта экспериментов с интеграцией в Почту Mail.ru мы:

1. Частично защищены на случай, если Google заблокирует нам пуши совсем. Мы сможем продолжать слать пуши о новых письмах юзерам через канал пушей RuStore.
2. Можем повышать delivery rate за счёт отправки по двум каналам параллельно, а не по одному. Таким образом мы можем суммарно повышать delivery rate всех пушей, которые приходят на устройство юзерам.
3. Провели нагрузочное тестирование пушей RuStore в реальных условиях. Это позволило найти проблемы, часть которых мы уже зафиксили.

Промежуточные результаты (VKPNS vs FCM)

Эксперименты всё ещё идут, но я уже готов поделиться промежуточными результатами.

• Количество успешно отправленных пушей за сутки:

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

Спойлер: проблема была в том, что в коннекторе к Redis, который мы используем, был дедлок, из-за этого у нас в какой-то момент начинали копиться коннекты, что приводило к OOM. Если пользуетесь Radix, то рекомендую обновиться.

• Среднее время ответа API send: 13ms vs 45ms

Время ответа нашего API уже в 3 раза ниже, чем у Google. Это было ещё до фиксов OOM. Здесь приведено среднее время ответа, максимальное также ниже.

• Доставляемость пушей за сутки:
  Октябрь 2022 года ~60% vs 100%
  UPD: Декабрь 2022 года ~101% vs 100%

Пока что наша основная зона роста — это доставляемость пушей. Мы уже доставляем 60% от того, что доставляет Google через свой нативный канал. По нашей статистике для довольно большой части юзеров пуши не доставляются совсем, что говорит о том, что есть какой-то баг, из-за которого происходит рассинхронизация клиентского и хостового SDK. При этом те юзеры, кому мы пуши доставляем, получают примерно столько же, сколько и от Google — где-то мы доставляем чуть меньше, где-то чуть больше. Поэтому считаем, что текущее значение delivery rate вызвано не тем, что нас как-то режет ОС, то есть не непреодолимыми проблемами. В течение нескольких недель мы надеемся зафиксить баг, о котором я сказал, и тогда delivery rate существенно вырастет. UPD: пофиксили в декабре, актуальный delivery rate можно увидеть выше.

Планы на будущее

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

Приблизиться по функциональности к FCM

Как минимум, мы должны сделать рассылки по топикам (массовые рассылки в Firebase), поддержать ещё больше настроек пуша. Я говорил, что мы поддерживаем иконку, картинку, цвет пуша, но пока что не все поля. В консоли разработчиков в Firebase можно видеть метрики доставляемости, сколько там пушей отправлено, сколько доставлено, сколько открыто. Мы пока эту статистику не выводим, но это в планах.

Научиться получать пуши через другие приложения VK на устройстве пользователя

Я говорил о том, что пуш-уведомления приходят юзеру, только если у него стоит RuStore. Понятно, что это ограничение для роста нашего сервиса. Поэтому мы хотим сделать так, чтобы пуш-уведомления могли приходить через любой из продуктов ВК, который стоит на Android-устройстве юзера. Это должно существенно повысить нам охват. При этом важно, что мы должны продолжать держать только одно соединение, а не из каждого приложения ВК (из Маруси отдельно WebSocket, из Облака отдельно WebSocket) — это нам не подходит.

Добиться значения health-метрик не хуже, чем у Google FCM

Поскольку есть куда расти, как минимум, по delivery rate, и те значения API, которые я показывал, тоже нужно сохранить, важный вектор нашей работы — это стабилизация нашего сервиса. По основным health-метрик нам нужно быть, как минимум, не хуже, чем Google.

• Блог компании Конференции Олега Бунина (Онтико)
• Kubernetes

Тестирование push-уведомлений в мобильных приложениях

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

Какие цели преследуют с помощью push-уведомлений?

• вовлечение пользователей;
• удержание;
• формирование лояльности пользователей;
• стимуляция продаж;
• информирование.

Принцип работы push-уведомлений

1. пользователь устанавливает приложение на устройство;
2. выдаётся запрос прав на отправку уведомлений, и в случае успеха — ОС получает токен (идентификатор устройства) у службы push-уведомлений;
3. ОС передаёт токен на сервер для подключения к уведомлениям;
4. сервер шлёт уведомления при наступлении определенного события.

Где отображаются уведомления?

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

Разница между push-уведомлениями в iOS и Android

Функции push-уведомлений в iOS и Android довольно сильно различаются.

iOS основана на модели push Opt-In, которая не позволяет брендам отправлять мобильные push-уведомления пользователям своих приложений до тех пор, пока эти пользователи не согласятся их получать. Android, с другой стороны, автоматически разрешает пользователям получать push-уведомления с возможностью отказаться от них вручную.

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

Типы мобильных уведомлений

Информационные уведомления

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

Геолокационные уведомления

1. информировать о местных мероприятиях и акциях;
2. искать доступные рестораны в этом районе;
3. сообщать прогноз погоды;
4. завершать аренду или выезд за пределы зоны аренды на каршеринге, и многое другое.

Повторное вовлечение

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

Рекламные уведомления

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

Периодические уведомления

Они запускаются в определенное время и день.

Уведомления об опросах

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

Тестирование push-уведомлений

Не приходят push-уведомления

Чтобы разобраться в причине, для начала проверьте, чтобы в меню устройства была активирована соответствующая функция (разрешены уведомления для конкретного приложения). Затем убедитесь, что не включен режим «Не беспокоить».

Если всё настроено правильно, но уведомления не приходят, попробуйте перезагрузить устройство и заново авторизоваться в приложении. Бывает так, что необходимо заново отправить push-токен на серверную часть сервиса. Проверьте также, какой стиль уведомления используется (необходим «Баннер» либо «Предупреждение»).

Если не помогло всё перечисленное, попробуйте перезайти в свою учетную запись магазина приложений, либо откройте саму программу, в том случае, если на другие приложения тоже не приходят push-уведомления (стоит также проверить наличие интернета на устройстве).

Переходы по push-уведомлению

При тестировании необходимо проверить такие сценарии (с учётом того, что пользователь может быть авторизован или неавторизован):

• переход по push-уведомлению с заблокированного экрана;
• переход по push-уведомлению из «шторки»;
• пользователь находится в приложении;
• переход по push-уведомлению при свёрнутом приложении;
• пользователь разлогинился после получения push;
• переход по push-уведомлению с включенным «Don’t keep Activities» (характерно для Android-приложений).

Если push-уведомление ведет на WebView, то проверьте, что WebView открывается корректно на обеих платформах. И что в push зашит корректный URL.

Устаревший push-токен

У устройства изменился push-токен, когда восстановили приложение из резервной копии системы и не передался новый push-токен.

Очередь со стороны Apple

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

Проверка максимального и минимального количества отображаемых символов

В iOS и Android имеется лимит отображаемых символов. Он разный. Максимальное значение количества символов для платформы iOS – ограничение в 4 строки (178 символов), а для Android – не более 13 строк (663 символа). Не забудьте также проверить push-уведомление, содержащее минимальное количество символов, для обоих платформ можно задать 1 символ.

Кастомный звук для push-уведомления

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

Изображения в push-уведомлениях

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

Локальные push-уведомления

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

Проблемы на серверной стороне

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

Резюме

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

Над статьей работали: @KostyaKulakov, @yakoeka и @wincomm. А если остались вопросы — скорее пишите в Telegram-каналы @qa_chillout или @youlatech.

• push-уведомления
• push
• тестирование мобильных приложений

• Блог компании Юла
• Тестирование мобильных приложений

Push в общей системе маркетинговых коммуникаций

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

Статью подготовила Галина Панасюк — Head of CRM Busfor.ua. У Галины за плечами огромный опыт работы с пуш-уведомлениями, а главное — впечатляющие результаты их использования.

Сбор токенов, первичная сегментация и основные метрики для базы

Только размышляете над запуском пуш-рассылок? Этот раздел — для вас!

Создание проекта в Firebase

Веб-Push — это браузерные сообщения, которые настраиваются в системе Firebase.

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

Например, когда компания BUSFOR переходила в eSputnik, у нее уже был собственный проект в Firebase, благодаря чему около 80% базы токенов удалось сохранить. Если проект создает сервис рассылки, перенести из него контактную базу скорее всего не получится.

Идентификация контактов

Идентификатор пуш-уведомления — это токен устройства. Токен — не персональная информация, если он не связан с емейлом или какими-либо другими персональными данными клиента.

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

Срок жизни токена — от 14 дней до года, в зависимости от устройства и поведения пользователя: например, токен меняется при обновлении браузера.

Выбор сервиса

Существует 2 основных типа сервисов рассылки пуш-уведомлений.

Сервисы, которые рассылают только пуши:

Виды подписки

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

Браузерная подписка — стандартная, она происходит в один клик. Здесь вы не сможете ни вставить картинку, ни даже поменять цвет или форму кнопок. Язык уведомления зависит от языка браузера пользователя.

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

Мы рекомендуем ставить такое уведомление на страницу входа. На других страницах оно может отвлекать и раздражать пользователей. Особенно опасно ставить уведомления с предложением подписаться на страницы оформления заказа — пользователь может подумать, что разрешает платеж. Если он уже готов платить — не мешайте ему 🙂

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

Если пользователь согласится, то после этого покажется стандартное окно:

У подписки в два клика есть свои плюсы и минусы: конверсия по сравнению с подпиской в один клик может уменьшаться на 15-40%, зато подписываются только действительно заинтересованные пользователи. Таким образом, вы будете платить меньше, отправляя пуши только тем, кому они действительно нужны. Кроме того, уменьшатся жалобы на спам.

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

Данные для первичной сегментации

• Страница подписки — это первая точка контакта, и она часто отражает специфику интересов подписчика. Это может быть страница со скидками, мужская или женская одежда и т.д.
• Устройство — ваша стратегия рассылки будет зависеть от того, мобильное оно или десктопное.
• Геоположение — поможет сформировать актуальные предложения, учитывающие регион проживания контакта.
• Язык — вы сможете отправлять сообщения на привычном пользователям языке (особенно актуально для таких двуязычных стран, как Украина).
• Другая информация, доступная в разметке страницы — ID пользователя, история поиска, источник перехода и т.д. (сбор этих данных требует дополнительных настроек).

Автоматизация, разработка гипотез и роль канала в общей структуре трафика

Если для старта рассылки всё готово — сделаем ее максимально эффективной!

Автоматизация

Возможности автоматизации пуш-рассылок, которые подходит практически любому типу бизнеса — триггерные сценарии, welcome- и retention-серии.

Триггерные пуши, плюсы

• минимальная стоимость,
• расширение охвата.

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

Способы обогащения данных из пушей:

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

При всех этих вариантах ESP сможет собрать токен, емейл, ID и другие полученные данные вокруг одного контакта, чтобы впоследствии вести с ним омниканальную коммуникацию.

Настроить омниканальные рассылки

Welcome-серия, плюсы:

• высокая вовлеченность,
• высокая доставляемость,
• возможность монетизации трафика.

Welcome-цепочка в пушах может быть такой же интересной и эффективной, как и в email. Вы знакомите подписчика со своим бизнесом, делитесь ссылками на самые интересные материалы и акции. Но нужно помнить о том, что пуш-сообщение может увести пользователя со страницы. Поэтому лучше всего отправлять первый велком-пуш уже после того, как пользователь уйдет с вашего сайта. Например, если среднее время посещения вашего сайта 10 минут, настройте старт велком-цепочки на 15 минут после подписки.

Retention-серия, плюсы:

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

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

Построение гипотез

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

Разное поведение с разных устройств

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

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

Еще одно отличие мобильных и десктопных пушей — внешний вид. В десктоп-формате обычно это кнопка, текст и картинка.

А на мобильной версии картинка может обрезаться в зависимости от мобильного устройства. Поэтому мы советуем вообще не вставлять картинки в мобильную версию пушей.

Разное поведение с разными посадочными страницами

Анализируя конверсии пушей, не забывайте анализировать качество посадочных страниц.

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

Влияние дополнительных элементов

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

Время отправки и время жизни сообщения

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

Например, вы отправили сообщение в 15.00 и установили время жизни 5 часов, потому что в 20.00 акция, которую рекламирует пуш, закончится. Тогда все ваши получатели, которые в течение этих 5-ти часов откроют браузер, сразу получат это уведомление, после чего оно перестанет показываться.

Нужно помнить, что чем короче TTL, тем, соответственно, меньше будет доставляемость. Поэтому для постоянных акций лучше ставить максимальный TTL. И не забывайте указывать дату в метках сообщения, чтобы понимать, откуда пришла конверсия.

Влияние предложения

Тестируйте разные варианты предложений: может оказаться, что скидка в 5% и 6% дает очень разные результаты.

Задачи канала

Условно можно выделить три главных задачи пушей:

1) Быстрый трафик на посадочную

Основная задача пушей — нагнать быстрый трафик на посадочную страницу.

Тут вспоминается забавный кейс компании Bosfor.ua. Чтобы получить народную премию, подписчиков в пуше попросили голосовать за компанию. Сайт народной премии просто лёг, т.к. одновременно на него перешли тысячи сторонников Босфора. Подумайте, выдержит ли ваш сайт возможный трафик из пушей?

2) Продвижение новых страниц

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

3) Источник бесплатных установок приложения

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

Актуализация состояния базы и оптимизация всех этапов воронки

Стандартная воронка пуш-уведомления состоит из таких этапов:

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

Средняя статистика такова — от 100% отправленных:

• доставляется от 60 до 80% уведомлений,
• открывается — 20-30%,
• переходов — 1-2%.

• очистите контактную базу от неправильных и неактивных токенов;
• найдите лучшее время отправки сообщений;
• подберите оптимальный TTL;
• улучшайте контент уведомлений и посадочных страниц.

Как очистить контактную базу

Выделите группы контактов, которые неактивны на определенный день после регистрации. Обычно 80% неактивны на 35-й день. Отправьте этому сегменту экспериментальное уведомление — измените контент, время отправки и т.д. Удалите из базы все токены, владельцы которых не отреагировали на это уведомление.

То же можно сделать не по сроку жизни, а по количеству уведомлений, полученных контактом: если он получил N уведомлений (допустим, 100), но открытий не было, отправляем экспериментальный пуш, если результата нет — удаляем его из базы.

“Битые”, изначально неправильные токены удаляются в eSputnik автоматически. Если вы будете пользоваться другим сервисом, не забывайте чистить базу и от таких токенов.

Коротко о главном

• Пуш-уведомление — идеальный инструмент для увеличения трафика на сайт.
• При выборе сервиса обращайте внимание на возможность использовать пуш-уведомление в связке с другими каналами.
• Обогащайте данные токен-контактов информацией из других каналов.
• Актуализируйте базу — не забывайте чистить токены.

eSputnik — сервис, который поможет справиться с этими и многими другими задачами. Присоединяйтесь к нам 🙂

Push уведомление

Push уведомление — это короткое всплывающее сообщение в приложении или браузере. Его отправляют пользователям, чтобы рассказать об обновлениях, новостях и акциях. Главная цель push уведомления — доставить клиенту релевантную информацию для поддержания вовлеченности.

В этом видео директор по развитию SendPulse Александр Рысь подробно рассказывает о преимуществах и работе web push уведомлений.

Содержание

Преимущества push уведомлений

• Привлекают внимание пользователя
• Увеличивают вовлеченность
• Улучшают коммуникацию с пользователями
• Способствуют конвертации пользователей в клиентов
• Повышают конверсию
• Увеличивают трафик

Давайте рассмотрим несколько факторов, которые делают push уведомления эффективным маркетинговым инструментом для взаимодействия с клиентами по всему миру.

• Привлекают внимание пользователя. Согласно статистике, открываемость push уведомлений достигает 90%. Поэтому, несмотря на высокую конкуренцию, всплывающие сообщения имеют решающее значение с точки зрения привлечения внимания пользователей.
• Увеличивают вовлеченность. Частота подписки на push уведомления на устройствах Android составляет 91%, а на устройствах iOS — 44%, при этом кликабельность сообщений в 7 раз выше, чем у email. Это значит, что push уведомления — эффективный канал для взаимодействия с аудиторией.
• Улучшают коммуникацию с пользователями. С помощью push уведомлений бренды создают точки соприкосновения — микрокоммуникации, которые помогают выстраивать доверительные взаимоотношения.
• Способствуют конвертации пользователей в клиентов. Push уведомления могут помочь на каждом этапе пути покупателя.
• Повышают конверсию. Push уведомления способствуют удержанию существующих пользователей и реактивации неактивных подписчиков, что увеличивает конверсию.
• Увеличивают трафик. Персонализированные и релевантные push уведомления служат подходящим каналом для направления трафика на определенные страницы сайта или в разделы приложения.

Виды push уведомлений

Существует два вида push сообщений: мобильные и браузерные. Давайте подробнее рассмотрим каждый из них.

Мобильные push уведомления

Доступны для пользователей, которые загрузили приложение и подтвердили получение сообщений. Мобильные уведомления (in-app сообщения) помогают вовремя информировать об обновлениях, направлять подписчиков к определенным разделам приложения и предоставлять краткие инструкции. Основными платформами для получения push уведомлений в приложениях являются Android и iOS.

Согласно RubyGarage, мобильные push сообщения увеличивают уровень взаимодействия с приложением на 88% и в три раза повышают показатель удержания клиентов. Кроме того, пользователи, которые выбрали получение push уведомлений, запускают приложение в три раза чаще.

Длина сообщений зависит от мобильной операционной системы. Для iOS также играет роль тип уведомления. Максимальная длина варьируется от 62 символов для промо-сообщений до 235 символов для оповещений. На устройствах Android ограничение составляет около 84 символов в зависимости от размера экрана.

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

Web push уведомления

Браузерные сообщения появляются на рабочем столе компьютера или на экране мобильного телефона. Компании используют web push уведомления в основном в маркетинговых целях. Они отправляют информацию о скидках и акциях, сообщают о новых товарах на складе или делятся обучающими статьями.

Несмотря на тип push уведомлений, которые вы планируете отправлять, необходимо получить согласие пользователей. В противном случае сообщения компании будут нежелательными и репутация бренда может пострадать. Запрос на разрешение появляется в виде всплывающего окна в верхней части страницы, когда пользователь просматривает сайт. Как и в примере интернет-магазина Rozetka, он содержит только две опции: «Разрешить» или «Блокировать».

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

Web push уведомления — отличный способ продвижения продуктов и услуг компании во время акций и распродаж. Ниже вы видите одно из таких сообщений от магазина LeBoutique.

Максимальная длина такого сообщения зависит от типа устройства. Для смартфонов ограничение составляет 20-30 символов, для компьютеров — 175 символов (50 символов заголовок и 125 — основной текст).

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

Как работают push уведомления

Давайте выясним, как работают мобильные и браузерные уведомления.

Как работают мобильные уведомления

Давайте возьмем в качестве примера операционную систему iOS.

Сначала приложение отправляет запрос на ваше устройство. Девайс передает его службе push уведомлений Apple (APNS), которая в ответ отсылает токен устройства. Девайс перенаправляет токен в приложение, которое перемещает его в Backend. После этого токен устройства передается обратно APNS вместе с самим уведомлением. Только после этого сообщение достигает девайса и пользователь может его увидеть.

Схема ниже наглядно отображает, как мобильные push уведомления работают на устройствах iOS.

Как работают web push уведомления

Уведомления браузера работают по-другому. Каждый браузер, такой как Chrome, Firefox или Yandex, имеет свою службу push уведомлений, поэтому способы их доставки могут отличаться.

Сервер приложения отправляет сообщение сервису push уведомлений, который передает его User Agent — браузеру. Затем User Agent расшифровывает полученные данные и активирует Service Worker, чтобы передать событие push. После этого Service Worker отображает сообщение.

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

Push уведомления в SendPulse

1. Добавьте свой сайт
2. Добавьте сгенерированный код на сайт
3. Соберите подписчиков и отслеживайте статистику
4. Отправляйте web push кампании

Чтобы настроить отправку web push уведомлений в SendPulse, необходимо выполнить всего несколько шагов:

1. Добавьте свой сайт. Вставьте ссылку сайта и выполните общие настройки: выберите изображение, установите действие, которое должно стать триггером для запроса на подписку.
2. Добавьте сгенерированный код на сайт. Скопируйте и вставьте строку кода в шаблон вашего сайта перед закрывающимся тегом.
3. Соберите подписчиков и отслеживайте статистику. Все данные о результативности push уведомлений отображаются в личном кабинете SendPulse во вкладке «Статистика».
4. Отправляйте web push кампании. Выберите список получателей, напишите заголовок и основной текст, добавьте ссылку.

Подробнее о том, как настроить рассылку push уведомлений, читайте в базе знаний.

SendPulse позволяет сегментировать список подписчиков, персонализировать заголовок и основной текст, добавлять большое изображение, делать предпросмотр сообщения и планировать отправку web push уведомлений на определенное время.