Push token что это

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.

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

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

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

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

Saved searches

Use saved searches to filter your results more quickly

You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session. You switched accounts on another tab or window. Reload to refresh your session.

concept: PushToken

Shortcuts

Clone this wiki locally

Firebase changes

Firebase is now included in the app, the parameters are not in the QR code anymore and the Firebase project that is used can not be changed.

Rollout Key URI

The creation of the push token is triggered by /token/init . The token enrollment of the push token is also a 2step enrollment. In the first step, the privacyIDEA Server creates a QR code with a key uri like this:

To initialize Firebase on the smartphone without google-services (to choose the Firebase project at runtime), the necessary information has to be provided by the privacyIDEA Server. The information can be extracted from the configuration file ‘google-services.json’ and ‘GoogleService.plist’ which are downloaded from the Firebase console for the specific project. The information that is required by the app to initalize firebase differs between iOS and Android, therefore the information for both will be in the QR so the App can extract the needed information. The extended key uri with that information could look like this:

Tokentype

Basically we use the same scheme that is used for the Google Authenticator and the privacyIDEA authenticator. The token type is pipush (in contrast to hotp or totp ).

Label

The tokentype is followed by the label that was created by the privacyIDEA server. This is not necessarily the serial, as this parameter can be modified by policies on the server side and by the user on the smartphone side.

Serial

The serial is used to identify the Token and is immutable. It is sent to the server when authenticating to assign the correct challenge.

Parameter: Enrollment URL

This parameter is the enrollment URL specified by url . This is the URL, that the push token will contact in the second enrollment step.

Parameter: Time To Live

This optional parameter is a time, for how long the smartphone token can try to register with the second enrollment step (in minutes). The second step could fail to a lot of reasons. So the server can specify how long the phone can try this.

Default value: 10

Parameter: enrollment_credential

This is usually a hex nonce, that the smartphone app needs to present to the enrollment endpoint, to authorize for taking the second enrollment step.

Parameter: v

This is the version of the used cryptographic algorithm or the overall enrollment process. The smartphone app should «know», which version it supports. If the version is higher than the supported version, the smartphone should exit and tell, that the QR code version is not supported on this App version.

default value: 1

Parameter: sslverify

Indicate whether the rollout urls certificate should be verified by the smartphone. This is only for the rollout process.

default value: 1

(Firebase)Parameter: ProjectID

The project ID not only identifies the project, but is also used for the DatabaseURL (projID.firebaseio.com) and the StorageBucket (projID.appspot.com). In the json, it is located at project_info/project_id. Both Android and iOS share this parameter

(Firebase)Parameter: AppID

client/client_info_mobilesdk_app_id for Android

(Firebase)Parameter: AppIDiOS

from GoogleService.plist, the iOS AppID is different from the Android one

(Firebase)Parameter: API Key

client/api_key/current_key for Android

(Firebase)Parameter: Api Key iOS

from GoogleService.plist, the iOS Api Key is different from the Android one

(Firebase)Parameter: Projectnumber

project_info/project_number, both Android and iOS share this parameter

Implementation idea:

• Enrollment Url / Registration Url
• TTL
• ProjectID
• AppID
• API Key
• Project Number

into a firebase push service. Store it in its own database and define an Enrollment Policy, which FB Push Service should be used.

Endpoints

Enrollment Endpoint

This is the endpoint that is contained in the QR code. The push token app sends all the necessary data for the 2nd enrollment step to this endpoint.

The normal tokentype endpoint /ttype/push is used.

So the enrollment URL should be of the form

The URL was initially sent in the QR Code, the app needs to add the parameters itself. (Later we could add some further optional parameters)

enrollment_credential This is a secret key to avoid attackers from guessing the serial number and thus taking the second step.

serial is the serial number of the token generated by privacyIDEA in the first step, that was passed in the QR Code.

fbtoken is the firebase token of the smartphone app.

pubkey is the public key of the smartphone app (PKCS1 encoded).

On enrollment the smartphone app generates an asymmetric key pair, save the firebase token and the private key and hands the firebase token and the public key to the privacyIDEA Server (PKCS1 encoded).

The response from the privacyIDEA to this enrollment URL call contains a public key of the privacyIDEA server.

The token in privacyIDEA

The token is stored in the database with the following information

• firebase config in privacyIDEA
• smartphone: public key
• smartphone: firebase token
• public key from server
• private key from server

Authentication Endpoint for Smartphone

First the authentication process is triggered. privacyIDEA needs to get an access token of the firebase service and then send the challenge to the firebase service via:

The body consists of key-value pairs. The keys are the following:

1. nonce
2. url
3. serial
4. question
5. title
6. sslverify
7. signature

The signature is in Base32 format and the signed string is built like:

Smartphone response

Accept

If the authentication request is allowed on the smartphone and the signature of the request is valid, the smartphone builds a response for the privacyIDEA Server. The signature is created for the following string:

The complete response looks like this:

Decline

If the authentication request is declined on the smartphone, the smartphone builds a response for the privacyIDEA server. The signature is created for the following string:

The complete response looks like this:

The challenge is deleted from the challenge table.

Polling Endpoint for Application

The application, where the user logs in, uses this endpoint of privacyIDEA to check, if the user has confirmed the login on his smartphone.

We can utilize the existing endpoint GET /token/challenges/ which is an administrative endpoint.

In the first authentication step the application would memorize the transaction_id and then poll to

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