Показ in-app перед запросом разрешения на push-уведомления

In-app для предварительного запроса разрешения — это сообщение, которое вы показываете перед системным запросом на разрешение отправки push-уведомлений. Используйте его, чтобы объяснить, почему push-уведомления полезны, а затем запрашивайте разрешение только после того, как пользователь согласится в вашем in-app.

На iOS системный запрос появляется только один раз за установку. Если пользователь нажмет Не разрешать, приложение не сможет показать этот запрос снова. Push-уведомления останутся выключенными, пока пользователь не включит их в Настройках. Предварительный запрос в in-app означает, что вы используете эту единственную попытку только для тех пользователей, которые уже дали вам свое согласие.

Используйте это руководство, если вы хотите создать один кроссплатформенный HTML-запрос в Панели управления и запускать его по Event как на iOS, так и на Android.

Используйте другое руководство, если:

• Ваша команда будет внедрять запрос только для iOS в коде приложения (не редактируемый в Панели управления, не запускаемый по событию Journey): Основы push-уведомлений для iOS.
• Вам нужно повторно вовлечь пользователей, которые уже отключили push-уведомления или никогда не давали на них разрешения (только для восстановления, а не для первого запроса): Создание всплывающих окон для восстановления подписки.

Перед началом

Требуется помощь разработчика

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

Pushwoosh никогда не показывает системный диалог запроса разрешений самостоятельно. В Панели управления нет настроек для его отсрочки. Диалог появляется только тогда, когда пользователь нажимает кнопку согласия в вашем in-app.

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

1. Убедитесь, что приложение не запрашивает разрешение на push-уведомления раньше (в том числе при первом запуске).
2. Согласуйте имя кастомного Event и время его срабатывания, например, onboarding_completed сразу после онбординга или locked_feature_tapped, когда пользователь нажимает на функцию, для которой нужны уведомления. Ваша команда вызовет postEvent с этим именем. Узнайте больше о Events.

Создание in-app

Кнопки в этом руководстве работают на кастомном JavaScript, который функционирует только в HTML-шаблоне in-app. Нативный шаблон in-app не может выполнить этот код, поэтому не создавайте шаблон с помощью опции Нативный in-app.

1. Перейдите в Контент → In-Apps и нажмите Создать in-app, чтобы сразу открыть встроенный редактор.
2. Введите имя шаблона.
3. Откройте вкладку Блоки на правой панели и добавьте текстовый блок или заголовок с вашим предложением включить push-уведомления.

4. Добавьте блок кнопки для действия согласия и еще один для действия отказа. Обе кнопки могут выполнять свой JavaScript сразу после загрузки in-app, не ожидая ничего другого.

Совет

Чтобы выделить кнопку согласия как основное действие, как на скриншоте выше, выберите кнопку отказа, включите Фон в ее панели стилей и установите значение transparent. Также включите Цвет текста и выберите цвет, который будет хорошо читаться на фоне шаблона.

5. Выберите кнопку согласия и установите Тип действия на Кастомный Javascript.
6. Вставьте только приведенный ниже код в поле onClick.

pushwoosh.registerForPushNotifications();
pushwoosh.closeInApp();

7. Выберите кнопку отказа и установите Тип действия на Кастомный Javascript.
8. Вставьте только это в поле onClick:

pushwoosh.closeInApp();

После сохранения шаблона:

• Кнопка согласия: появится системный диалог запроса разрешений.
• Кнопка отказа: in-app закроется, и системный диалог не появится.

In-app для предварительного запроса разрешений, показанный перед системным запросом

Совет

Только для загрузки ZIP / разработчиками: если вы создаете необработанный HTML-файл для загрузки в виде ZIP, используйте полные теги вместо поля onClick в редакторе:

<button onclick="pushwoosh.registerForPushNotifications(); pushwoosh.closeInApp();">Включить уведомления</button>
<button onclick="pushwoosh.closeInApp();">Не сейчас</button>

Не показывать запрос пользователям, которые уже подписались

Добавьте условие отображения, чтобы in-app скрывался для пользователей, которые уже разрешили push-уведомления, даже если последующий триггер снова покажет шаблон. Статус согласия на push-уведомления берется из Push Alerts Enabled, стандартного логического Tag, который SDK устанавливает на основе системного разрешения на уведомления устройства.

1. На панели Слои щелкните первый блок, затем, удерживая Shift, щелкните все остальные блоки, чтобы выбрать весь шаблон целиком.
2. Включите Показывать этот блок по условию. Установленное вами правило будет применяться ко всему выделению сразу.
3. Установите правило Push Alerts Enabled is false.
4. В разделе Если значение неизвестно выберите Показывать блок. Новая установка без значения Tag все равно должна видеть запрос.

Осторожно

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

Запуск in-app перед запросом разрешения

Устройство, которое еще не прошло регистрацию, не имеет push-токена, поэтому вы не можете связаться с ним с помощью push-уведомления. Запускайте in-app по кастомному Event, о котором вы договорились с разработчиками.

1. Попросите вашу команду разработчиков вызвать postEvent с согласованным именем Event в тот момент, когда вы хотите сделать запрос.
2. Перейдите в Customer Journey Builder → Создать кампанию и начните с входа на основе триггера, который отслеживает это Event.
3. Добавьте элемент In-app и выберите созданный вами шаблон. Узнайте больше об отправке in-app через Customer Journey.
4. Запустите Journey, когда будете готовы показать запрос.

Примечание

In-app не появляется в тот же момент, когда срабатывает Event. Доставка происходит при следующем открытии приложения на устройстве после этого.

Пример сценария: запрос разрешения на push-уведомления сразу после онбординга

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

1. Создайте Event onboarding_completed и убедитесь, что ваша команда разработчиков вызывает его, когда пользователь завершает процесс онбординга. Узнайте больше о создании Events
2. Установите onboarding_completed в качестве триггера для вашего Journey, используя вход на основе триггера.
3. Добавьте элемент In-app и выберите созданный вами шаблон для предварительного запроса разрешений.
4. Запустите Journey.

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

Проверка работы

Системный запрос является одноразовым, поэтому для тестирования обеих кнопок потребуется два тестовых устройства (или две свежие установки), которые еще не дали или не отклонили разрешение на push-уведомления, по одному для каждой кнопки. На каждом устройстве:

1. Вызовите согласованное Event из приложения.
2. Перезапустите приложение и убедитесь, что Journey доставляет ваш in-app.

Затем:

3. На первом устройстве нажмите кнопку согласия и убедитесь, что появляется системный диалог запроса разрешений.
4. На втором устройстве нажмите кнопку отказа и убедитесь, что in-app закрывается без системного диалога.
5. После следующего открытия приложения убедитесь, что Push Alerts Enabled соответствует состоянию разрешений на каждом устройстве.

Создание сегмента пользователей, у которых push-уведомления все еще отключены

Отфильтруйте по Push Alerts Enabled, чтобы найти пользователей, которые отклонили или никогда не давали разрешение. Tag имеет значение false, когда push-уведомления еще не разрешены, в том числе до того, как пользователь увидел системный диалог, поэтому устройство, ожидающее предварительного запроса, уже попадает в этот сегмент.

1. В конструкторе сегментов добавьте фильтр по Tag Push Alerts Enabled.
2. Установите оператор на is false. Узнайте больше о создании сегментов по Tags.

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

Смотрите также

• Основы push-уведомлений для iOS: нативная альтернатива только для iOS этому кроссплатформенному HTML-подходу.
• Создание всплывающих окон для восстановления подписки: восстановление пользователей, которые уже отключили push-уведомления (не первый запрос), с использованием того же Tag Push Alerts Enabled.
• Создание in-app с помощью JavaScript: полное руководство по JavaScript bridge.