Что такое push service Huawei

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

9200 просмотров
Что такое push-уведомления

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

Push уведомления (push notifications) — сообщения, которые всплывают на экране девайса пользователя: на смартфоне, на компьютере и на экранах умных устройств. Пуш — это короткий текст, сообщающий пользователю важную информацию: старт акции, изменение статуса заказа, об операции на счёте и другое.

Задача push-сообщения — «подтолкнуть» (push) пользователя к быстрому действию прямо сейчас. Это главное отличие от технологии pull (тянуть), когда человек сам заходит на сайт или в почту, чтобы получить («вытянуть») информацию.

Обзор и интеграция Huawei Push kit

триггерные — пользователь совершил или не совершил действие, на которое реагирует система;

транзакционные — подтверждение оплаты, смена статуса заявки и другие;

контентные — новая информация о продукте, изменения в работе компании.

Пуш сообщения бывают мобильными и браузерными.

Mobile push (мобильные) появляются на экранах мобильных устройств. Их отправляют мобильные приложения, если пользователь разрешил это действие. Push-уведомления mobile версии поддерживают заголовок, текст, картинку, иконку бренда, кнопку действия (CTA).

Web push (браузерные) всплывают на экране компьютера или мобильного устройства, но присылает их не приложение, а браузер. Пользователь даёт разрешение на отправку во всплывающем окне, когда заходит на сайт. Такие пуш уведомления можно отключить при желании в настройках браузера.

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

В web push notifications входит заголовок, текст, иконка, картинка, гиперссылка и адрес сайта, который отправил сообщение.

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

Пуш сообщения — находка для маркетологов. Как push помогают бизнесу?

Повышают вовлечённость пользователей. Как показывают исследования, возможно увеличить показатель до 88%.

Возвращают пользователей. Поднять Retention rates в 3-10 раз с push-уведомлениями реально. Исследования показывают, что бренды, которые начнут рассылку пушей, могут за 90 дней повысить показатель Retention на 190%.

Увеличивают открываемость уведомлений. Пуш-сообщения открывают чаще, чем письма email-рассылки: Opening rate пушей выше на 50%, а Click rate в 7 раз.

«Ловят» клиентов по геолокациям. 53% пользователей готовы поделиться своей текущей локацией. Бизнес может отслеживать их устройства и автоматически присылать информацию об актуальных предложениях рядом.

Продвигают пользователя по воронке продаж. Согласно исследованиям, 48% клиентов покупают после того, как получили пуш-уведомление.

|| КАК РЕШИТЬ ПРОБЛЕМУ С Push УВЕДОМЛЕНИЯМИ НА ТЕЛЕФОНАХ HUAWEI и HONOR без сервисов гугл ||

• Доставляют информацию в реальном времени, что важно в условиях высокой конкуренции.
• Показывают всю информацию на экране — не нужны дополнительные действия, чтобы её получить.
• Не требуют сбора персональных данных (номеров телефонов), что упрощает работу и снижает риск санкций.
• Помогают быть всегда на связи с клиентом и напоминать о себе. Есть возможности персонализации.
• Не проходят проверку спам-фильтров, как сообщения электронной почты.

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

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

Последняя публикация на сайте СМИ — отлично, потому что пользователь подписывался именно на получение актуальных новостей. «Ваш заказ доставлен» — тоже важно для клиента.

В любой сфере пуш-уведомления полезно применять:

• для онбординга;
• как сообщения о транзакциях;
• для вовлечения и удержания пользователей.

На начальном этапе работы с брендом пользователь может отвлечься, забыть или отложить: заполнение данных, первый заказ, оформление профиля в соцсети, начало активных действий, для которых он подписался (например, тренировки в фитнес-приложении). Пуш исправит ситуацию и «подтолкнёт» пользователя к активности.

Транзакции

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

Вовлечение и удержание

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

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

Интернет-торговля

Маркетплейсы и интернет-магазины с помощью пуш уведомлений сообщают пользователям про:

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

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

Банки присылают через push:

• персональные предложения по кредитам и вкладам;
• напоминания о сроке кредита;
• сообщение о перевыпуске карты;
• операции со счётом: покупке, пополнении;
• предупреждения о подозрительных операциях;
• одноразовые пароли для входа в систему.

Рекрутинговые сайты

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

• просмотре резюме;
• приглашении на собеседования;
• новых вакансиях по критериям пользователя;
• другую дополнительную информацию, которая ускорит поиск работы.

Недвижимость

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

Какие есть варианты для пуш-уведомлений:

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

Медицинская организация

Частные клиники используют push, чтобы:

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

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

• необходимость пройти урок;
• время события (вебинара, конференции, встречи с наставником);
• сдачу домашнего задания;
• скидки на допкурсы;
• ответы от менторов и наставников на вопросы ученика.

Возможно, самый известный пример пуш-уведомлений в обучении — кейс приложения для изучения иностранных языков Duolingo. Зелёная сова на иконке пуш-уведомлений и тон сообщений даже стали мемом.

Бухгалтерия и госуслуги

Страшный сон бухгалтера и предпринимателя — не сдать вовремя налоговую отчётность и не успеть заплатить налоги. Через push удобно получать уведомления о сроках по отчётам и «спать спокойно».

Как происходит отправка web push и mobile push

Со стороны пользователя всё просто — дать согласие на рассылку и получать важную информацию оперативно. Со стороны отправителя есть нюансы: для каждой операционной системы используются свои пуш-сервисы (они же провайдеры): FCM, APNS, huawei Push Kit и другие. Рассмотрим два популярных сервиса, которые рассылают пуши на большую часть устройств.

Firebase Cloud Messaging (FCM) — сервис для отправки push-уведомлений на устройства Android, IOS, в браузеры Chrome, Opera, Yandex, Firefox и другие. Сообщение автоматически отображается на устройстве от клиентского приложения.

Apple Push Notification Service (APNS) — сервис для отправки пуш-уведомлений на устройства Apple, который присылает сообщения с текстом, иконкой или картинкой. Также возможно воспроизвести короткий звук.

Сервисы работают по похожему принципу. Так происходит отправка push-уведомлений:

• Устройство клиента подключается к сервису пуш-уведомлений: Firebase Cloud Messaging, APNS или другому. Получает токен — специальный идентификатор.
• Токен отправляется серверу конкретного приложения (Backend сервер).
• Сервер приложения использует токен для отправки уведомлений пользователю на устройство: в мобильное приложение, в браузер, на смарт-часы, на TV и так далее.

Так рассылки делают напрямую из пуш-сервисов, но для маркетинга их возможности ограничены. Не всегда можно с помощью этих инструментов персонализировать уведомления и сегментировать аудиторию. Для маркетинговых задач подходят сервисы-отправщики, которые выступают в роли Backend серверов. Они хранят идентификаторы и «дергают» пуш-сервис, когда нужно отправить рассылку. Также их плюс — работа сразу с несколькими пуш-сервисами.

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

11 комментариев
Написать комментарий.
Аккаунт удален
Развернуть ветку

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

Развернуть ветку

Отключил к чёртовой матери все пуши на телефоне. Счастлив как никогда.

Увы, хороший и полезный инструмент превратился в способ спама и информационный мусор.

Развернуть ветку

Здравствуйте. К сожалению, такое встречается. К счастью, не все приложения такие.

Развернуть ветку

При серфинге 80% сайтов это зашёл прочитал и вышел, закрыть окна с предложением подписаться на новости, дать разрешение к геоданным, уведомление об адблоке, информирование о печеньках, и это ещё далеко не все.
Мобильные приложения туда же, при желании отключить эту уведомления возникает сложность, они не подписаны, исключительно техническое описание, где уведомления об акциях а где сообщения в приложении и статус заказа решительно непонятно.
И если очередное приложение сетей фастфуда получит отключение уведомлений со спамом, и от этого пострадает возможность получать пуши о статусе заказа, 1 звезда такому приложению.

Развернуть ветку

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

Развернуть ветку

Вот как понимать восстановленный и разнообразный?
PS: злобных любителей пушей от всяких пиццерий etc я удалил, при необходимости ставлю их обратно, но чаще заказывать из тех что уже стоят на телефоне.
Цена пушей с акциями.

Развернуть ветку

Начиная с Android 8.0, добавилась такая фича как “Категории уведомлений”. Добавили ее как раз для того, чтобы пользователи могли лучше контролировать пуши на своих телефонах (отключать звук уведомлений, вибрацию, отображение на заблокированном экране и др). Создают эти категории разработчики, но только пользователи могут менять настройки категории на своем устройстве.
Например, на скрине можно увидеть, какие категории есть в приложении TikTok.

Miscellaneous и Restored в данном случае и есть категории. Надо признать, что Вкус Вилл не оставил вам большого выбора.
Restored — это те уведомления, которые пришли на телефон, вы с ними еще никак не успели повзаимодействовать (не удаляли и не открывали), но произошло принудительное закрытие приложения. Эти пуши будут дожидаться вас именно в категории Restored, чтобы вы вновь их увидели после того, как приложение заработает.
Miscellaneous — это категория для тех уведомлений, которым сам отправитель изначально категорию не назначил.
Таким образом, в приложении Вкус Вилл у вас есть возможность отключить получение уведомлений из этих категорий.

Если что, здесь вы найдете более подробную информацию о категориях: https://developer.android.com/training/notify-user/channels

Create and Manage Notification Channels | Android Developers
developer.android.com
Развернуть ветку

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

Развернуть ветку

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

Развернуть ветку

Согласен. Крайне важный инструмент, мы его сейчас активно развиваем в своем сервисе, как раз полчаса назад опубликовал статью )

Развернуть ветку

Комментарий удален модератором

Источник: vc.ru

Mobile push: настройка и подключение

Настройка браузерных Push-уведомлений описана в соответствующей статье.

Описание

Мобильные push-уведомления отображаются по мере получения в центре уведомлений мобильного устройства — в «шторке» Android и iOS смартфонов, планшетов и других гаджетов. По умолчанию уведомления включены для устанавливаемых приложений, так что вы можете сразу с момента установки начать процесс вовлечения клиента.

Для мобильных приложений есть 4 варианта настройки:

• Google Firebase Cloud Messaging — для Android и iOS приложений;
• Apple Push Notification Service — только для iOS приложений;
• Yandex.AppMetrica — для Android и iOS приложений;
• Huawei Mobile Services — для Android и iOS приложений;
• RuStore — только для Android приложений.

Yandex.AppMetrica использует для отправки SDK Google Firebase. Для отправки уведомлений вам нужно будет установить его в приложение.

В Altcraft Platform доступна интеграция с Yandex.AppMetrica для импорта профилей пользователей, регистрации их действий и связанной с ними ценности (стоимости).

Настройка App Push в мобильных приложениях Android

Пароль — это сервисный токен.

Добавление подписки на push приложений

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

Подписка на Yandex.AppMetrica может добавляться автоматически пользователям приложения с подключенным сервисом метрики. Подробнее в статье Интеграция с Yandex.AppMetrica.

Трекинг событий в app push

В push для приложений входят ссылки ack и open.

GET запрос этих ссылок создаёт события push доставлен и push открыт.

Они отобразятся в истории пользователя и сводном отчёте.

Регистрация события в app push

С помощью вызова API можно добавлять произвольные события: Добавить события с app push.

Источник: docs.altcraft.com

Внедряем кросс-платформенные пуш-уведомления: начало

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

Для начала нужно понять, куда мы вообще хотим отправлять пуши. В нашем случае это веб-сайт, iOS-приложение и Android-приложение.

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

• У Firefox он называется Mozilla Push Service. Его исходный код и спецификация протокола открыты, чем мы позже воспользовались.
• У Chrome это Google Cloud Messaging (не Firebase Cloud Messaging, что можно увидеть по именам доменов в исходном коде), и так далее.

Хорошая новость для нас в том, что веб-пуши стандартизированы IETF (https://datatracker.ietf.org/wg/webpush/documents/), и поддерживать разные форматы API для каждого браузера как на клиенте, так и на сервере нам не придется.

Теперь рассмотрим устройства на базе Android. Здесь есть несколько вариантов:

• Если в системе установлены Google Apps, то можно воспользоваться Firebase Cloud Messaging.
• Если у вас устройство от Huawei без Google Apps, то можно использовать Huawei Push Kit.
• Можно написать собственный пуш-сервер или воспользоваться готовыми проектами, например, https://bubu1.eu/openpush/, благо открытость платформы позволяет.

Далее идет iOS. В отличие от Android, способ отправить уведомления на устройства Apple всего один — использовать Apple Push Notification service (APNs).

Может возникнуть логичный вопрос: неужели придется поддерживать всё это многообразие стандартов, API и прочего на серверной стороне? На самом деле, всё не так уж и плохо, так как Firebase Cloud Messaging, помимо отправки на Android, покрывает еще и веб-пуши и работает с APNs. Так мы пришли к следующей схеме: на устройства Huawei без Google Apps отправляем через Huawei Push Kit, в остальных случаях пользуемся Firebase Cloud Messaging.

Несмотря на многообразие стандартов и сервисов, схема работы будет примерно одинаковой:

1. Клиент подключается к пуш-серверу и получает уникальный идентификатор — токен.
2. Клиент отправляет токен серверу конкретного приложения, чтобы стать связаным с учетной записью пользователя.
3. Сервер приложений начинает по полученному токену отправлять пуши для конкретного пользователя.

Попробуем написать тестовое приложение

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

Сделаем страницу с одной кнопкой и необходимыми скриптами:

simple_example.html

Также потребуется скрипт сервис-воркера. По умолчанию он подгружается автоматически по пути /firebase-messaging-sw.js . Для начала будем использовать готовый скрипт отсюда.

Открываем страницу, нажимаем на кнопку, разрешаем уведомления в браузере и копируем отображенный токен. Для удобства работы с API вручную можно создать долговременный ключ сервера (не сервисный аккаунт). Делаем простой запрос:

curl -X POST ‘https://fcm.googleapis.com/fcm/send’ -H ‘Authorization: key=’ -H ‘Content-Type: application/json’ -d ‘< «to» : «», «notification» : < «body» : «Body of Your Notification», «title»: «Title of Your Notification» >>’

Тут есть важный момент, о котором можно забыть: пуш-токен никак не связан с пользователем приложения, он связан с конкретным получателем (т.е. с клиентской конфигурацией). На мобильных устройствах он связан с конкретной инсталляцией приложения.

Посмотрим, что нам приходит в браузер. В документации описан колбэк setBackgroundMessageHandler . Модифицируем сервис-воркер, добавив в конец файла код:

messaging.setBackgroundMessageHandler((payload) => < console.log(‘Message received. ‘, payload); // . >);

Открываем консоль сервис-воркера, снова отправляем пуш… и ничего не видим в консоли, хотя уведомление отобразилось. Почему же? Ответ в есть в документации:

Note: If you set notification fields in your message payload, your setBackgroundMessageHandler callback is not called, and instead the SDK displays a notification based on your payload.

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

Тем не менее, можно это обойти, обрабатывая входящие пуши вручную. Поменяем содержимое firebase-messaging-sw.js :

firebase-messaging-sw.js

self.addEventListener(«push», event => < event.waitUntil(onPush(event)) >); async function onPush(event) < const push = event.data.json(); console.log(«push received», push) const < notification = <>> = ; await self.registration.showNotification(notification.title, < body: notification.body, >) >

Здесь мы считываем полезную нагрузку в json и парсим ее в js-объект, который будет выведен в консоль, заодно показывая уведомление. Обратите внимание на waitUntil внутри обработчика: он нужен для того, чтобы сервис-воркер не завершил работу до окончания асинхронного вызова onPush .

Теперь добавим пользователей в наше приложение

Для удобства заведем новую страницу:

user_example.html

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

inmemory.go

type MemoryStorage struct < mu sync.RWMutex userTokens map[uint64][]Token tokenOwners map[string]uint64 >func NewMemoryStorage() *MemoryStorage < return userTokens: map[uint64][]Token<>, tokenOwners: map[string]uint64<>, > > type Token struct < Token string `json:»token»` Platform string `json:»platform»` >func (ms *MemoryStorage) SaveToken(ctx context.Context, userID uint64, token Token) error < ms.mu.Lock() defer ms.mu.Unlock() owner, ok := ms.tokenOwners[token.Token] // if old user comes with some token it’s ok if owner == userID < return nil >// if new user come with existing token we // should change it’s owner to prevent push target mismatch if ok < ms.deleteTokenFromUser(token.Token, owner) >ut := ms.userTokens[userID] ut = append(ut, token) ms.userTokens[userID] = ut ms.tokenOwners[token.Token] = userID return nil > func (ms *MemoryStorage) deleteTokenFromUser(token string, userID uint64) < ut := ms.userTokens[userID] for i, t := range ut < if t.Token == token < ut[i], ut[len(ut)-1] = ut[len(ut)-1], Token<>ut = ut[:len(ut)-1] break > > ms.userTokens[userID] = ut > func (ms *MemoryStorage) UserTokens(ctx context.Context, userID uint64) ([]Token, error) < ms.mu.RLock() defer ms.mu.RUnlock() tokens := ms.userTokens[userID] ret := make([]Token, len(tokens)) copy(ret, tokens) return ret, nil >func (ms *MemoryStorage) DeleteTokens(ctx context.Context, tokens []string) error < ms.mu.Lock() defer ms.mu.Unlock() for _, token := range tokens < user, ok := ms.tokenOwners[token] if !ok < return nil >ms.deleteTokenFromUser(token, user) > return nil >

В бэкенд также добавлен код отправки пушей конкретному пользователю.

Базово мы обеспечиваем следующую функциональность:

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

Опишу несколько важных моментов, на которые мы наткнулись уже на практике (они отражены в примере):

• Пуш-токены имеют ограниченный срок жизни, однако узнать его из самого токена, на первый взгляд, невозможно. Судя по коду firebase-js-sdk, этот срок чуть больше недели, так как колбэк на обновление токена onTokenRefresh вызывается раз в неделю.
• Разные пользователи могут прислать одинаковые пуш-токены. Такое возможно в случае, если запрос на инвалидацию в Firebase не прошел успешно. Для решения этой проблемы мы в данном случае меняем владельца токена.
• У пользователя может завершиться сессия без явного логаута. Т.е. пользователь больше не авторизован, однако уведомления продолжают поступать. Способ решения этой проблемы зависит от архитектуры приложения. Мы при отправке пуш-токена на сервер сохраняем идентификатор пользователя еще и локально, при каждой загрузке страницы сверяя его с ответом на запрос о текущем пользователе. Если значения различаются или пользователь не авторизован, то пуш-токен инвалидируется. Однако у такого подхода всё же есть один недостаток: инвалидация происходит только в случае загрузки страницы сайта.
• Сохраняйте платформу, с которой получен токен. Это поможет при дальнейшей кастомизации: например, добавить возможность ответа в чат прямо из пуша (в Android/iOS можно, в браузере — нет), кнопки и прочее.

И вот, грабли собраны, доработки выложены в прод. Пуши ходят… или не ходят? Самое время поговорить про

Надежность

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

Идея следующая: мы генерируем одноразовый токен подтверждения (в нашем случае это просто UUID) и отправляем его в пуше. Клиент при получении и показе пуша делает HTTP-запрос, в который включается присланный токен подтверждения. Немного дорабатываем бекенд и firebase-messaging-sw.js :

firebase-messaging-sw.js

self.addEventListener(«push», event => < event.waitUntil(onPush(event)) >); async function onPush(event) < const push = event.data.json(); console.log(«push received», push) const < notification = <>, data = <> > = ; await self.registration.showNotification(notification.title, < body: notification.body, >) if (data.id) < await fetch(`$/api/v1/notifications/$/confirm`, < method: «POST» >) > >

И если с вебом нам хватило такой простой доработки, то с мобильными устройствами всё несколько сложнее. Помните про замечание в документации о setBackgroundMessageHandler ? Так вот, дело в том, что в Firebase (да и в Huawei) есть не совсем очевидное (по API) разделение на, условно, информационные пуши (если есть поле notification ) и data-пуши. По задумке, информационные пуши никак не обрабатываются приложением и на их основе сразу формируется уведомление, а data-пуши попадают в специальный обработчик и дальше приложение решает, что делать.

Если при получении веб-пушей с ними можно работать до показа, отказавшись от firebase-js-sdk в сервис-воркере, то в Android так не получится. Поэтому для Android мы перенесли всю нужную информацию исключительно в data и перестали отправлять notification , что позволило нам реализовать подтверждение доставки.

Для APNs же достаточно просто выставить mutable-content в 1, и тогда при обработке пуша можно будет выполнять некоторый код, но с довольно серьезными ограничениями, хотя этого вполне достаточно для простого HTTP-запроса. Собственно, именно из-за ограничений iOS при подтверждении пуша не задействуется пользовательская сессия, а используются одноразовые токены.

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