Afficher une in-app avant la demande d'autorisation push

Une in-app de pré-autorisation est un message que vous affichez avant la demande d’autorisation push du système. Utilisez-la pour expliquer pourquoi les notifications push sont utiles, puis ne demandez l’autorisation qu’après que l’utilisateur a dit oui dans votre in-app.

Sur iOS, la demande du système n’apparaît qu’une seule fois par installation. Si l’utilisateur appuie sur Ne pas autoriser, l’application ne peut plus afficher cette demande. Les notifications push restent désactivées jusqu’à ce qu’il les active dans les Réglages. Demander d’abord via une in-app signifie que vous n’utilisez cette unique chance que sur les utilisateurs qui vous ont déjà dit oui.

Utilisez ce guide si vous souhaitez concevoir une seule demande HTML multiplateforme dans le Panneau de Contrôle et la déclencher par un événement sur iOS et Android.

Utilisez un autre guide si :

• Votre équipe déploiera une demande uniquement pour iOS dans le code de l’application (non modifiable dans le Panneau de Contrôle, non démarrée par un événement Journey) : Guide de démarrage push pour iOS.
• Vous devez réengager les utilisateurs qui ont déjà désactivé les notifications push ou ne les ont jamais autorisées (récupération uniquement, pas la première demande) : Créer des pop-ups de récupération d’opt-out.

Avant de commencer

Assistance d'un développeur requise

Vous créez le modèle dans le Panneau de Contrôle. Partagez le guide des événements et la méthode postEvent avec votre équipe de développement — ils s’occuperont des deux prérequis ci-dessous.

Pushwoosh n’affiche jamais la boîte de dialogue d’autorisation du système par lui-même. Il n’y a rien à configurer dans le Panneau de Contrôle pour la retarder. La boîte de dialogue n’apparaît que lorsque l’utilisateur appuie sur le bouton d’acceptation dans votre in-app.

Travaillez avec votre équipe de développement sur ces prérequis :

1. Confirmez que l’application ne demande pas l’autorisation push plus tôt (y compris au premier lancement).
2. Convenez d’un nom d’événement personnalisé et du moment où le déclencher, par exemple onboarding_completed juste après l’intégration, ou locked_feature_tapped lorsque l’utilisateur appuie sur une fonctionnalité qui nécessite des notifications. Votre équipe appellera postEvent avec ce nom. En savoir plus sur les événements.

Créer l’in-app

Les boutons de ce guide fonctionnent avec du JavaScript personnalisé, qui ne fonctionne que dans un modèle d’in-app basé sur du HTML. Un modèle d’in-app natif ne peut pas exécuter ce code, donc ne créez pas le modèle avec In-app natif.

1. Allez dans Contenu → In-Apps et cliquez sur Créer une in-app pour ouvrir directement l’éditeur intégré.

2. Saisissez un nom de modèle.

3. Ouvrez l’onglet Blocs dans le panneau de droite et ajoutez un bloc de texte ou de titre avec votre argumentaire pour l’activation des notifications push.

4. Ajoutez un bloc de bouton pour l’action d’acceptation et un autre pour l’action de refus. Les deux boutons peuvent exécuter leur JavaScript dès que l’in-app se charge, sans rien d’autre à attendre.

Conseil

Pour distinguer le bouton d’acceptation comme action principale, comme dans la capture d’écran ci-dessus, sélectionnez le bouton de refus, activez Arrière-plan dans son panneau Styles, et réglez-le sur transparent. Activez également Couleur du texte et choisissez une couleur qui reste lisible sur l’arrière-plan du modèle.

5. Sélectionnez le bouton d’acceptation et réglez le Type d’action sur Javascript personnalisé.
6. Collez uniquement le code ci-dessous dans onClick.

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

7. Sélectionnez le bouton de refus et réglez le Type d’action sur Javascript personnalisé.
8. Collez uniquement ceci dans onClick :

pushwoosh.closeInApp();

Après avoir enregistré le modèle :

• Bouton Accepter : la boîte de dialogue d’autorisation du système apparaît.
• Bouton Refuser : l’in-app se ferme et aucune boîte de dialogue du système n’apparaît.

Une in-app de pré-autorisation affichée avant la demande du système

Conseil

Pour le téléversement ZIP / développeur uniquement : si vous créez un fichier HTML brut pour le téléversement ZIP, utilisez les balises complètes au lieu du champ onClick de l’éditeur :

<button onclick="pushwoosh.registerForPushNotifications(); pushwoosh.closeInApp();">Enable notifications</button>
<button onclick="pushwoosh.closeInApp();">Not now</button>

Ne pas afficher la demande aux utilisateurs qui ont déjà accepté

Ajoutez une condition d’affichage pour que l’in-app se masque pour les utilisateurs qui ont déjà accordé l’autorisation push, même si un déclencheur ultérieur affiche à nouveau le modèle. Le statut de consentement push provient de Push Alerts Enabled, un tag booléen par défaut que le SDK définit à partir de l’autorisation de notification système de l’appareil.

1. Dans le panneau Calques, cliquez sur le premier bloc, puis faites un Maj-clic sur chaque autre bloc pour sélectionner l’ensemble du modèle.
2. Activez Afficher ce bloc sous condition. La règle que vous définissez ci-dessous s’applique à toute la sélection en une seule fois.
3. Définissez la règle sur Push Alerts Enabled est faux.
4. Sous Si la valeur est inconnue, choisissez Afficher le bloc. Une nouvelle installation sans valeur de tag devrait toujours voir la demande.

Attention

Push Alerts Enabled se met à jour à la prochaine ouverture de l’application par l’appareil, et non au moment où l’utilisateur bascule le commutateur d’autorisation dans les réglages du système. Un utilisateur qui active les notifications push depuis les réglages peut encore voir ce bloc une fois de plus jusqu’à ce qu’il rouvre l’application.

Déclencher l’in-app avant que l’autorisation ne soit demandée

Un appareil qui n’a pas encore été enregistré n’a pas de token push, vous ne pouvez donc pas l’atteindre avec une notification push. Déclenchez l’in-app par l’événement personnalisé que vous avez convenu avec l’équipe de développement.

1. Demandez à votre équipe de développement d’appeler postEvent avec le nom d’événement convenu au moment où vous souhaitez faire la demande.
2. Allez dans Customer Journey Builder → Créer une campagne et commencez avec une Entrée basée sur un déclencheur qui écoute cet événement.
3. Ajoutez un élément In-app et sélectionnez le modèle que vous avez créé. En savoir plus sur l’envoi d’in-apps via Customer Journey.
4. Lancez le Journey lorsque vous êtes prêt à afficher la demande.

Note

L’in-app n’apparaît pas à l’instant où l’événement se déclenche. La livraison a lieu à la prochaine ouverture de l’application par l’appareil après cela.

Scénario d’exemple : demander l’autorisation push juste après l’intégration

Imaginez que vous souhaitiez demander l’autorisation push au moment où un utilisateur termine son intégration, au lieu d’interrompre le tutoriel lui-même.

1. Créez l’événement onboarding_completed et confirmez que votre équipe de développement le déclenche lorsque l’utilisateur termine le processus d’intégration. En savoir plus sur la création d’événements
2. Définissez onboarding_completed comme déclencheur pour votre Journey, en utilisant une Entrée basée sur un déclencheur.
3. Ajoutez un élément In-app et sélectionnez le modèle de pré-autorisation que vous avez créé.
4. Lancez le Journey.

Chaque utilisateur qui termine l’intégration voit la demande une fois. La condition d’affichage de la section Ne pas afficher la demande aux utilisateurs qui ont déjà accepté l’empêche de se déclencher à nouveau pour les utilisateurs qui ont déjà accordé l’autorisation push.

Vérifier que cela a fonctionné

La demande du système est unique, donc tester les deux boutons nécessite deux appareils de test (ou deux nouvelles installations) qui n’ont pas encore accordé ou refusé les notifications push, un pour chaque bouton. Sur chaque appareil :

1. Déclenchez l’événement convenu depuis l’application.
2. Rouvrez l’application et confirmez que le Journey livre votre in-app.

Ensuite :

3. Sur le premier appareil, appuyez sur le bouton d’acceptation et confirmez que la boîte de dialogue d’autorisation du système apparaît.
4. Sur le second appareil, appuyez sur le bouton de refus et confirmez que l’in-app se ferme sans boîte de dialogue du système.
5. Après la prochaine ouverture de l’application, confirmez que Push Alerts Enabled correspond à l’état d’autorisation sur chaque appareil.

Créer un segment d’utilisateurs qui ont toujours les notifications push désactivées

Filtrez sur Push Alerts Enabled pour trouver les utilisateurs qui ont refusé ou n’ont jamais accordé l’autorisation. Le tag est false lorsque les notifications push ne sont pas encore autorisées, y compris avant que l’utilisateur n’ait vu la boîte de dialogue du système, donc un appareil en pré-autorisation tombe déjà dans ce segment.

1. Dans le constructeur de segments, ajoutez un filtre par le tag Push Alerts Enabled.
2. Réglez l’opérateur sur est faux. En savoir plus sur la création de segments par tags.

Utilisez ce segment pour retenir une demande répétée auprès des utilisateurs qui n’ont toujours pas activé les notifications push, ou pour lancer un Journey de reconquête périodique. Consultez le segment de récupération d’opt-out pour un exemple concret avec le même tag.

Voir aussi

• Guide de démarrage push pour iOS : l’alternative native, uniquement pour iOS, à cette approche HTML multiplateforme.
• Créer des pop-ups de récupération d’opt-out : récupérer les utilisateurs qui ont déjà désactivé les notifications push (pas la première demande), en utilisant le même tag Push Alerts Enabled.
• Créer des in-apps avec JavaScript : la référence complète du pont JavaScript.