Push token что это

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

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

Для начала нужно понять, куда мы вообще хотим отправлять пуши. В нашем случае это веб-сайт, 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-сервер с передачей статики.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Надежность

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

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

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

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

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

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

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

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

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

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

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

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

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

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 — сервис, который поможет справиться с этими и многими другими задачами. Присоединяйтесь к нам 🙂

Unlocking the Full Potential of Push: A Look at $PUSH Token Utility��

Token economics (or tokenomics) are a critical component of any blockchain or cryptocurrency project. It dictates how incentives are created, distributed, and managed within the network. Push Protocol is a decentralized communication layer for Web3 that uses a native token, $PUSH, to incentivize its network participants.

In this post, we’ll take a closer look at Push token economics and explore how it differs from other token systems. We’ll also examine the specific incentives driving the Push Protocol network and how they contribute to the network’s overall success.

Push Token Economics: An Overview

Push Protocol’s token economics aim to create a circular economy run by the community, for the community. The goal is for every participant to be rewarded for their contributions while simultaneously discouraging behavior that would be detrimental to the network. The $PUSH token is at the center of the ecosystem, providing incentives for all network participants.

The $PUSH token is used in four primary ways within the Push Protocol ecosystem: securing the network, network utility, Push DAO and governance, and the reward pool fee. As Push Protocol expands to more chains and adds new forms of communication, more utility for $PUSH may emerge in addition to the four primary use cases.

1. Securing the Network

Push Nodes are an integral part of the Push Protocol network. These nodes allow Push Protocol to facilitate communication across multiple blockchains while retaining governance on the Ethereum mainnet. Push Nodes can be run by anyone and are incentivized to act in the network’s best interest through the use of $PUSH tokens in Proof of Stake. Nodes that continue to reach consensus and operate in the network’s best interest are rewarded in $PUSH tokens. Conversely, Push Nodes that do not remain synced with consensus or attempt to damage the network are penalized with the $PUSH tokens these bad actors staked.

2. Network Utility

$PUSH tokens are used as payment for message broadcasting on the Push Protocol network. When users broadcast a message, they must pay in $PUSH tokens to deliver that message to all interested parties. This payment incentivizes nodes on the network to relay the message to their peers, ensuring that the network remains fast and reliable.

3. Push DAO and Governance

53% of the supply of $PUSH has been allocated to the community to define the future of Push Protocol and its development. $PUSH also gives owners the right to vote on critical protocol decisions, including the staking structure, staking mechanisms, and reward distribution rates.

Governance votes can include:

• The structure of the fees paid by services
• The DeFi mechanism for the staking pool
• Other protocol incentivization and financial elements

Push Protocol adheres to Progressive Decentralized Governance. That is, a structure where power in decisions making is gradually distributed to the community. This approach allows token holders to have a say in the protocol’s future direction, ensuring that the network remains aligned with the community’s interests.

4. Push Fee Pool

The Push Fee Pool is designed to reward various participants, fostering a circular economy within the Push Protocol ecosystem. As the community moves towards greater decentralization, the network will determine fees, such as those charged to “super users” of chat and notifications (protocols sending large volumes of notifications) and fees related to the utility features of the protocol. It is essential to note that all fees are charged at the protocol level.

These fees are then distributed to $PUSH token holders and cryptocurrency wallets adopting the Push Protocol. The participants receiving rewards include token holders, wallet providers, and other stakeholders contributing to the ecosystem’s growth and decentralization.

The $PUSH token incorporates a time-weighted feature, enabling the protocol to identify and reward token holders who have maintained their $PUSH holdings for extended periods. This mechanism ensures that long-term supporters of the project receive proportionally higher rewards.

In summary, the Push Fee Pool aims to clarify the following points:

• Various participants, including token holders, wallet providers, and other stakeholders, are rewarded through the Push Fee Pool.
• Fees are charged at the protocol level and can include charges for “super users” and utility features within the Push Protocol.
• The fees collected are not from liquidity pools but rather from protocol-level activities.
• The $PUSH token’s time-weighted feature ensures that long-term token holders receive proportionally higher rewards.

Key Features of Push Tokenomics:

Push Protocol’s token economics model is designed with several essential features to promote a robust and sustainable ecosystem:

1. Circular Economy: The tokenomics aims to reward all network participants, encouraging them to hold onto tokens and contribute to the network’s growth and development.
2. Hybrid Proof of Stake Mechanism: Push Protocol utilizes a hybrid Proof of Stake mechanism to secure the network. Rewards and penalties in $PUSH tokens incentivize good behavior and deter bad actors.
3. Community-driven Governance: The Push DAO and governance system empower the community to influence the network’s future direction, ensuring alignment with the interests of its members.

While some of these features may share similarities with other tokenomic models, the combination of these elements within Push Protocol’s ecosystem helps create a unique and thriving environment for its users and stakeholders.

The Role of Incentive Schemes in Blockchain Networks

Incentive schemes play a significant role in driving participation and fostering growth in blockchain and cryptocurrency projects. While they are not the sole determinant of success, well-designed incentives can encourage users to hold onto their tokens, actively engage with the network, and contribute to its growth and development. Common incentive schemes include proof of stake, proof of work, token burning, airdrops, staking, liquidity mining, and gamification. By striking a balance between incentivization and other factors such as technology, governance, and community engagement, a project can increase its chances of long-term success and sustainability.

Let’s break them all down:

Proof of Stake (PoS) is a consensus mechanism that uses token staking to incentivize network participants to act in the network’s best interest. In PoS, validators stake tokens to verify transactions, and those who verify transactions correctly are rewarded with additional tokens. Those who act against the network’s best interests may lose their staked tokens.

Proof of Work (PoW) is a consensus mechanism that uses computational power to verify transactions. In PoW, miners solve complex mathematical problems to add new blocks to the blockchain. The first miner to solve the problem is rewarded with new tokens, and their block is added to the blockchain. PoW is resource-intensive and may lead to centralization.

Token Burning removes tokens from circulation by sending them to an address that no one can access. Token burning can be used to increase the value of existing tokens by decreasing the overall supply.

Airdrops are used by cryptocurrency projects to distribute free tokens to users. Airdrops can be used to increase network participation and attract new users. This is especially helpful for a project just starting out.

Staking is a mechanism that allows users to hold tokens for a specific period to receive rewards in return. Staking incentivizes participants to hold onto their tokens and participate in the network; the longer they stake, the greater their rewards will be.

Liquidity Mining incentivizes users to provide liquidity to a specific pool in exchange for tokens collected from trading fees. The more liquidity that is provided, the greater the rewards will be.

Gamification is a process of incentivizing users to complete specific actions. This can include completing transactions, referring friends, or engaging with the platform in other ways. By providing rewards for these actions, users are encouraged to continue using the platform and contributing to its growth and development.

Conclusion

Push Protocol’s token economics are designed to create a circular economy that incentivizes and rewards all network participants, while deterring behavior that would be detrimental to the network. Token economics and the resulting incentives play a crucial role in accelerating the adoption of a given cryptocurrency or project. Push Protocol achieves this through its use of a hybrid Proof of Stake mechanism and its Push DAO and governance system, which give the community a say in the network’s future direction and foster a collaborative environment.

As the Push Protocol community continues to grow and evolve, the team is constantly looking to add more utility for the $PUSH token. This includes exploring new use cases for the token and incentivizing more participants to hold and use the token. The community plays a crucial role in fostering this innovation and contributing to the network’s growth and development.

Incentives and token economics are essential components of any successful blockchain or cryptocurrency project. Push Protocol’s token economics exemplify a system that incentivizes participants to secure the network, pay for message broadcasting, and participate in network governance. As Push Protocol expands to more chains and adds new forms of communication, it will be exciting to see how its token economics evolve to create even more incentives for network participants. We invite you to join the Push Protocol community and discover the power of its token economics for yourself.

About Push Protocol

Push is the communication protocol of web3. Push protocol enables cross-chain notifications and messaging for dapps, wallets, and services tied to wallet addresses in an open, gasless, and platform-agnostic fashion. The open communication layer allows any crypto wallet /frontend to tap into the network and get the communication across.

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

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

Блок Send Push

Для отправки push-уведомлений используются блоки Send Push, соответствующие операционной системе целевого устройства (iOS или Android).

Получение Push Token и Bundle ID

Для выполнения отправки необходимо указать, как минимум, два параметра: Push Token и IOS (Android) Bundle ID. Поэтому стоит начать с подготовительной части и разобраться, как данные параметры получить.

По умолчанию база данных каждого проекта содержит модель Mobile Instance, которая связана с моделью User и содержит необходимые поля: push_token и bundle_id.

Создадим отдельный бизнес процесс для мобильного приложения, который и будет формировать заполненную модель Mobile Instance. Для получения токена push воспользуемся блоком Get Push Token.

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

В зависимости от результата используется соответствующий блок IOS Device Info или Android Device Info. Оттуда можно получить разнообразную информацию об устройстве, но в нашем примере достаточно узнать только Bundle ID.

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

Запись информации о мобильном устройстве пользователя

Следующий шаг — создание бизнес-процесса бэкенда для связи сформированного Mobile Instance с конкретным пользователем и записи в базу. В данном бизнес-процессе необходимо:

1. Узнать текущего пользователя с помощью блока Auth: Get current user.
2. Развернуть содержимое полученной модели Mobile Instance
3. Собрать модель заново и добавить в нее связь с пользователем с помощью блока Make Mobile Instance.
4. Воспользоваться блоком DB: Create Mobile Instance и сохранить данные в базе.

В эндпойнте POST /Mobile Instance/ можно заменить стандартный бизнес-процесс на тот, который был только что создан.

Завершающий этап подготовки — определиться с тем, когда именно стоит записывать в базу данных информацию об устройстве пользователя. Логичным решением будет делать это при выполнении авторизации в приложении. Для этого, в процесс авторизации пользователя в мобильном приложении сразу после блока Set Auth Token нужно добавить два новых блока с ранее созданными бизнес-процессами. Первый получает и формирует необходимую информацию, второй создает связь с пользователем и выполняет запись в базу данных.

Отправка push-уведомлений

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

Начнем со входящих параметров. Необходимо передать сам текст уведомления. Он состоит из трех частей: тела сообщения (body), его заголовка (title) и подзаголовка (subtitle).

Далее необходимо найти всех пользователей приложения. Для этого воспользуемся блоком Search User и зададим необходимые параметры:

• _With = Mobile Instances (нужно получить не только информацию о пользователе, но и о связанном с ним мобильном устройстве)
• Limit = -1 (по умолчанию запрос отдает 25 записей, “-1” указывается чтобы снять это ограничение и получить всех пользователей)
• _mobile_instances_os = Android (по условиям задачи нас интересуют только устройства Android)

Для сформированного массива пользователей нужно запустить цикл операций (блок For each loop)

Для каждого пользователя из блока Expand User нужно получить информацию о мобильных устройствах (Mobile Instances). Нам необходимо отправить уведомление только на одно устройство, поэтому установим index = 0 в блоке Array Element, а также проверим, содержит ли массив вообще хоть один элемент (ведь у пользователя может быть только устройство на iOS). Для этого проверим элемент на валидность, передадим значение valid index в блок If-Else и продолжим цикл только в случае значения true.

Если все правильно и информация об устройстве пользователя найдена, то нужно воспользоваться блоком Expand Mobile Instance и передать необходимые значения в блок Send Push (Android).

Обратите внимание на то, что при разработке и тестировании приложения в Developer App необходимо установить значение Developer Mode = True.

Также можно воспользоваться опцией TTL (Time to live). Она определяет время в секундах для отправки уведомления. В случае если уведомление не удается доставить сразу, например, если пользователь временно вне зоны доступа, то в отведенное время будут совершаться повторные попытки доставки.

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

Дополнительные параметры

Отдельно стоит обговорить дополнительные параметры блока отправки:

• Push ID
• Push Class
• Data

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

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

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