Push framework что это

Обновлено: 06.07.2024

Push-уведомления: что это, как работают и зачем нужны

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

около 50 push-messages в день сегодня получает среднестатистический пользователь смартфона;
примерно 53 % людей соглашаются на подписку для получения пуш-уведомлений;
на мобильные push-уведомления пользователи Android подписываются примерно в 91,1 % случаев. На iOS этот показатель находится на уровне 44 %. Такой разрыв объясняется необходимостью ручного подтверждения подписки для пользователей «яблочных» устройств.

Какой принцип работы у пуш-уведомлений

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

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

Какая классификация у пуш-уведомлений

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

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

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

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

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

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

Кому обязательно нужно использовать push-рассылки

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

Что лучше: push-уведомления или email-рассылка

Сегодня интернет-маркетинг предлагает массу доступных инструментов для привлечения целевой аудитории. Однако важно не только получить контакт с потенциальным клиентом, но и продолжить взаимодействие. Именно на этом этапе часто возникают сложности, обусловленные индивидуальными предпочтениями людей. Некоторым людям нравится читать электронные письма, а другие месяцами не проверяют свой ящик. Аналогично ситуация обстоит с push-уведомлениями. Некоторые люди изучают их содержимое с интересом, но есть и такие, которые быстро скрывают их без ознакомления. Следовательно, в сбалансированной маркетинговой стратегии стоит использовать все доступные возможности. То есть какой бы прогрессивной и современной ни была push-технология, от email-маркетинга все же полностью отказываться не стоит.

Что лучше: push-уведомления или SMS-рассылка

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

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

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

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

Push4Site. Очень приятный в настройке сервис с умеренной ценовой политикой. Он дает широкий набор инструментов для точной настройки рассылки и аналитики. Инструмент качественно русифицирован.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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 :

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

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

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

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

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

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

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

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

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

Надежность

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

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

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

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

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

Android (исключая Huawei) — 40 %
Web — 50 %
iOS — 70 %

Для Huawei достаточное количество данных еще не накоплено. Следует сказать о том, что мы не предпринимали никаких действий по увеличению доли доставленных пушей, как это сделали, например, в Яндекс.Почте.

Итоговая архитектура получается примерно такой:

Полную версию проекта можно взять на GitHub.

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

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

Сейчас самое время сказать: “Дружище, да ты чего, зачем разбираться с этой лямбдой и правами доступа для нее. Проще ведь поднять инстанс и кроном дергать скрипт ну или закинуть все в docker, чтобы поднимался, отрабатывал и схлопывался”. Не могу не согласиться — такое решение имеет право на жизнь. Но это добавляет немного больше работы. Поднятый инстанс нужно мониторить и в случае чего “тушить пожары”. А как очень хорошо известно, инженеров всегда напрягает, когда что-то идет не так. Да и просто хотелось “потрогать” такие сервисы как Lambda и DynamoDB, пускай даже в такой небольшой, но жутко интересной задачке.

Постановка задачи

Окей, идея есть — теперь сформулируем задачу.

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

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

Начнем с небольшой схемы:

Схема 1. Пример работы push-нотификации (на схеме есть Apple Push Notification service, но все описание далее будет касаться Firebase Cloud Messaging, но у Apple принцип работы схожий)

Итак, что мы имеем:

Еще пару слов об API.

API, в контексте нашей темы, делятся на два вида:

Так же они имеют одно общее название — это Web API’s, которые призваны облегчать жизнь программистам (источник).

Так вот, Push API и Notification API относятся к API браузера и представляют собой конструкции (набор объектов, функций, свойств и констант), построенные на основе языка JavaScript.

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

Откуда же берется Service Worker?

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

Service Worker готов к работе — поехали дальше!

Подписываемся на push-уведомления

Здесь можно отметить два шага:

За эти все процедуры отвечает тот самый упомянутый выше Push API.

Отправка пуша

Отправка push-уведомления заключается в триггере API нашего Push Service. Этот вызов должен содержать информацию, которую мы должны показать пользователю (payload) и группу пользователей на которую данный push будет отправлен. После того как мы сделали API вызов, Push Service — сформирует правильный формат для браузера и отдаст его в FCM, который поставит уведомление в очередь и будет ожидать, когда User Agent появится в сети.

Но push-уведомление не может жить в очереди вечно, поэтому у Push Service есть опция — TTL (Time to Live) или время жизни уведомления, по истечению которого, уведомление будет удалено 😈.

Получение push-уведомления пользователем

После того, как Push Service отправил push-уведомление, FCM доставит (ну или не доставит, если что-то пошло не так) его в браузер, последний создаст такую штуку как Push Event, на который отреагирует Service Worker и запустит обработку push-уведомления.

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

Реализация

Как всегда у правильных инженеров все веселье начинается с планирования — мы ничем не хуже 😄, поэтому:

Состав нашего стэка:

Итак начинаем с того, что пишем код для Lambda функции. Особенность его в том, что необходимо определить входную точку, так как Lambda функция вызывает функцию (2) внутри Lambda функции 😄, которая объявляется как “Handler” (1).

1) Handler — это и есть входная точка, которую и вызывает Lambda. Название Handler’a должно совпадать с именем функции в коде. 2) Имя функции, которая будет входной точкой в “Lambda”. 3) Event и Context — встроенные параметры, которые передаются вызываемой функции

Тут возникает законный вопрос, а что же такое эти переменные, которые мы передаем функции?

Документация говорит исчерпывающе (источник):

Event — использует этот параметр для передачи данных о событиях обработчику. В нашем случае, мы достаем из поля event тело ответа от API Analytics Service. Прилетает он в формате — json.

Contex — передает контекст объекта обработчику. Этот объект предоставляет методы и свойства, которые предоставляют информацию о вызове, функции и среде выполнения. Перейдя по ссылке можно увидеть методы и свойства, а также доступен пример логирования информации контекста (источник). Из контекста мы берем request_id, который используется для того, чтобы Lambda не запускалась несколько раз.

А вот как это все работает под капотом.

Cloudwatch event rule, по расписанию, триггерит Lambda функцию, она, в свою очередь, выполняет код, выполняет запрос/обновление данных в DynamoDB, записывает логи через CloudWatch и делает уведомление в Slack.

Ниже представлена блок схема, которая описывает алгоритм работы сервиса.

А если совсем просто, то Analytics Service API не умеет возвращать список статей для конкретного поддоменного имени, а только для домена целиком. Вот как-то так 😃.

Далее выполняем проверку был ли пуш с таким article_id отправлен или нет. Для этого мы вызываем функцию, которая достает записи из DynamoDB, сравнивает и обновляет записи в DynamoDB и в итоге возвращает нам значение переменной uniq.

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

Проблемы с которыми столкнулись

А теперь о проблемах, с которыми мы столкнулись при реализации данного сервиса.

Изначально, скрипт представлял собой, условно говоря, 5 строчек:

брали одну топ статью с сервиса аналитики
формировали json
отправляли на Push Service

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

Проверяем, полет нормальный — но недолгий 😃.

Настигла нас проблема, что пуши начали повторяться через 1–2 отправки (ну оно и логично 😃), так как у нас в базе лежит только один ID’шник статьи и он перезаписывался — небольшой просчет в архитектуре сервиса.

Поэтому следующим шагом стало то, что мы начали создавать массив items состоящий из article_id и записывать его в базу DynamoDB. Длину массива решили определить равную 5 — этого более чем достаточно, но в случае необходимости всегда можно увеличить.

Проверяем, полет нормальный — но недолгий, хотя дольше чем в предыдущем случае.

Следующая проблема с которой мы столкнулись — это перезапуск Lambda функции, что влекло за собой отправку 3-х push-уведомлений с интервалом в 1 минуту. Это происходило когда сервис отправки пушей отваливался по таймауту и Lambda функция считала, что она завалилась и запускалась повторно. Это, как оказалось, стандартное поведение для Lambda функции, которая работает в асинхронном режиме и если при выполнении функции она вернет ошибку, Lambda попробует выполнить ее еще раз. По умолчанию Lambda будет пробовать дополнительно 2 раза с интервалом в 1 минуту.

Решили эту проблему добавлением в DynamoDB такого поля как request_id. При каждом новом запуске Lambda генерирует уникальный request_id (он не меняется при перезапуске функции), который мы и вытягиваем из context. Проверку уникальности request_id выполняем перед проверкой article_id, а обновляем его каждый раз когда article_id — уникален. В итоге мы обрываем повторное выполнение функции, если такие попытки появляются.

Следующий вопрос может стать таким: “Так если Push Service отваливается по таймауту, то как вы понимаете ушел пуш или нет?”. И это тоже очень правильный вопрос. На самом деле, на протяжении всего полета, “не было ни единого разрыва” 😅, т.е. пуш отправлялся всегда, даже если мы не получали никакого ответа от API Push Service. Об этом говорит статистика отправки в административной панели Push Service, а так же уведомления в Slack.

Подводя итоги

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

Push-рассылки – это новый канал коммуникации с пользователями веб-ресурсов. Технология работает через Интернет-браузеры в различных операционных системах.

Пуш-уведомление появляется поверх всех раскрытых окон и задерживается на экране десктопного устройства определенное количество времени. Для Windows 10 и MacOS push-уведомления после отображения на экране переходят в Центр нотификаций, где их можно просмотреть позже. На мобильные устройства (например, на ОС Android) web push приходят даже при закрытом браузере.

Подписчику не нужно сообщать свои личные данные (номер телефона, электронный адрес и другую информацию, которая требуется, например, при подписке на рассылку email, sms или Viber).

Простая процедура и отсутствие необходимости предоставлять данные о себе (а многие пользователи не спешат делиться «личной» информацией) становятся первым шагом к формированию позитивного взаимодействия с подписчиком. Часто пользователь соглашается на подписку в нативном окне браузера импульсивно. Если в дальнейшем получаемые им пуши будут интересными и актуальными – он не станет отказываться от подписки.

Структура пуш-уведомления может меняться, в зависимости от браузера. Рассмотрим подробнее.

Как выглядят push-уведомления в браузере?

Web push в Windows 10

Читайте о нововведениях в отображении пушей в Google Chrome для Windows 10.

«Пуш» с длинным заголовком:

Push-уведомление с длинным заголовком и телом:

«Пуш» с большой картинкой:

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

Пуш в других браузерах

Похожие возможности открыты и для рассылок через Yandex-браузер.

В Firefox сегодня доступно отображение только стандартных уведомлений без расширенных возможностей:

Однако, даже при ограниченной вариативности необходимо для каждой новой рассылки создавать различные изображения и текст. Согласно статистике из реального кейса новостного сайта, только благодаря смене картинок и заголовков для каждого уведомления, кликабельность (CTR) выросла с 3-4% до 12-18%.

Показатели при одинаковых изображениях и тайтлах:

Рост CTR после смены стратегии:

Пуш-уведомления на мобильных устройствах

Ниже приведены примеры «пушей» в ОС Android для разных браузеров: Chrome, Opera, Yandex, Firefox.

Push-уведомления в Chrome на Андроид:

Как работают push-рассылки: принцип действия

Мы разобрались с основными понятиями о пуш-уведомлениях. Остановимся подробнее на принципах построения коммуникации сайта с пользователями посредством push-технологии.

Сбор базы

Планирование

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

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

Так же обдуманно нужно подходить к выбору частоты рассылок и длительности отправки уведомлений (TTL). Частота должна подкрепляться информационным поводом. То есть, едва ли будет оправданной рассылка пяти уведомлений с одинаковыми предложениями (к примеру, «Скидка на джинсы 20%») в течение недели. Важно следовать интересам подписчика и не перегружать его чрезмерным количеством однотипных месседжей.

Анализ

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

Успех компании обеспечен:

Простотой подключения сервиса (10 минут);
Поддержкой всех основных браузеров;
Постоянным улучшением услуги;
Грамотной поддержкой и сопровождением маркетинговых кампаний;

Безопасностью для клиентов;
Открытостью, в том числе для крупных компаний (White Label и Dedicated Service).

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

Как подключить push сервис к сайту: 4 шага

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

Push-рассылки обладают массой преимуществ по сравнению с другими каналами коммуникации (E-mail, SMS, мессенджеры):

Все эти факторы делают push-уведомления незаменимым инструментом маркетинговой стратегии, как при мультиканальном использовании (совместно с другими сервисами рассылок), так и отдельно. В каждой сфере бизнеса «пуши» находят свое применение и становятся надежной опорой для длительного и надежного контакта с клиентом.

Читайте также: