Augmentez les taux d’opt-in aux notifications push sur iOS, Android et Huawei grâce à un timing stratégique, aux invites douces in-app et aux notifications provisionnelles iOS.
Une invite de permission push est la boîte de dialogue du système d’exploitation qui demande aux utilisateurs si votre application peut envoyer des notifications push. Leur réponse détermine si vous pouvez livrer des notifications qui apparaissent sous forme de bannières, s’affichent sur l’écran de verrouillage et émettent des sons.
Un appareil iOS et un appareil Android affichant l'invite de permission système.
Traitez l’invitation comme une stratégie. L’invite système ne peut être affichée qu’un nombre limité de fois : une fois sur iOS et deux fois sur Android (Google et Huawei). Si l’utilisateur refuse à chaque tentative, il devra réactiver manuellement les notifications dans les paramètres système. Une invite mal synchronisée peut vous faire perdre définitivement un abonné, et l’audience joignable est le plus grand levier de ROI pour chaque campagne push que vous menez.Apple et Google recommandent tous deux d’expliquer la valeur de vos notifications avant de demander la permission. Sans contexte, les utilisateurs sont plus susceptibles de refuser, et sur iOS une invite refusée ne peut pas être affichée à nouveau.Ce guide couvre le push pour applications mobiles. Pour le push web, voir Invites de permission web push.
Les taux d’opt-in au push dépendent bien plus de quand et de comment vous demandez que du contenu de l’invite système elle-même. Les applications qui traitent l’invitation comme une stratégie surpassent systématiquement celles qui invitent au premier lancement. Les principes ci-dessous sont les briques de base. L’exemple de stratégie ci-dessous montre comment les combiner en un playbook concret.
Demandez après un moment de valeur. Attendez que l’utilisateur vienne de vivre quelque chose qui mérite une notification : terminer l’onboarding, enregistrer un article, suivre un sujet, passer une commande ou terminer une première session. Inviter au premier lancement, avant que l’utilisateur ne comprenne ce que fait votre application, est la principale cause de faibles taux d’opt-in.
Commencez par les notifications provisionnelles sur iOS. Les notifications provisionnelles sont livrées discrètement au Centre de notifications sans aucune invite, permettant aux utilisateurs de décider s’ils souhaitent les conserver en se basant sur du contenu réel plutôt que sur une explication hypothétique. C’est souvent la voie avec la meilleure conversion sur iOS et cela devrait être votre point de départ par défaut.
Expliquez la valeur avec une invite douce in-app. Une invite douce est un message in-app OneSignal qui indique aux utilisateurs quel type de notifications vous allez leur envoyer et pourquoi elles sont importantes. Fermer une invite douce ne consomme aucune tentative d’invite système, vous pouvez donc redemander aux utilisateurs qui n’étaient pas prêts.
Redemandez aux utilisateurs qui ont fermé l’invite douce, pas l’invite système. Configurez l’invite douce pour qu’elle se réaffiche à intervalle régulier (par exemple, toutes les 2 weeks). Les utilisateurs qui n’étaient pas prêts obtiennent une nouvelle chance sans épuiser la limite de l’invite système.
Itérez sur le texte et le timing. Publiez l’invite douce, observez la conversion dans le rapport du message, puis ajustez le déclencheur, la formulation et la fréquence. De petits changements de timing et de texte modifient couramment les taux d’opt-in de dizaines de points de pourcentage.
Cet exemple combine les notifications provisionnelles pour une portée immédiate sur iOS avec une invite douce à un moment de valeur pour un opt-in complet. Utilisez-le comme point de départ et adaptez les types de notifications et les moments de valeur à votre application. Pour les applications Android et Huawei, ignorez la phase 1 et commencez à la phase 2.Phase 1 : portée silencieuse sur iOS
Activez l’autorisation provisionnelle dans le tableau de bord OneSignal sous Settings > Apple iOS > Advanced Configuration > Enable iOS 12 direct to history.
Envoyez 2 à 3 notifications de haute qualité pendant la première semaine de l’utilisateur. Choisissez du contenu qui démontre la valeur de l’abonnement : une recommandation personnalisée, une alerte de dernière minute ou un digest hebdomadaire. Les utilisateurs les reçoivent silencieusement dans le Centre de notifications sans invite.
Phase 2 : convertir à un moment de valeur
Dans Messages > In-App, créez une invite douce qui fait référence à la valeur que l’utilisateur a déjà expérimentée. Exemple de titre : « Recevez des alertes de dernière minute sur votre écran de verrouillage ».
Définissez l’audience sur Show to all users. L’action de clic Push Permission Prompt filtre automatiquement pour les utilisateurs non abonnés.
Déclenchez le message sur un événement à fort signal : ouverture ou interaction avec une notification provisionnelle, suivi d’un sujet, ajout d’un article au panier ou 5 minutes de temps de session.
Ajoutez une action de clic Push Permission Prompt au bouton CTA.
Réglez la planification sur Multiple times avec un maximum par utilisateur de 20 et un intervalle entre les affichages de 2 weeks (environ 10 mois de relance).
Phase 3 : mesurer et itérer
Après 1 à 2 semaines, consultez le rapport du message pour la conversion invite-vers-opt-in.
Instrumentez l’entonnoir complet avec les écouteurs SDK : clics sur l’invite douce, fermetures et résultat de l’invite système. Transférez les événements vers votre outil d’analyse.
Ajustez une variable à la fois (événement déclencheur, titre, texte du CTA ou intervalle entre les affichages) en fonction des chiffres.
Déclenchez l’invite douce juste après que l’utilisateur a ouvert une notification provisionnelle ou interagi avec elle. Il a déjà vu la valeur de vos notifications, ce qui augmente considérablement le taux d’« Allow » sur l’invite système.
Vous avez trois façons de développer votre base d’abonnés push avec OneSignal. La plupart des applications iOS devraient combiner les notifications provisionnelles avec une invite douce in-app ; la plupart des applications Android devraient commencer par l’invite douce.
Approche
Plateformes
Fonctionnement
Quand l’utiliser
Invite douce in-app (recommandé)
iOS, Android, Huawei
Configurez un message in-app OneSignal avec une action de clic Push Permission Prompt. Appuyer sur le bouton affiche l’invite système. Fermer le message in-app ne consomme rien, vous pouvez donc redemander plus tard.
Le choix par défaut. Permet de concevoir, planifier, cibler et réafficher l’invite sans nouvelle publication de code.
Invite programmatique
iOS, Android, Huawei
Appelez requestPermission() ou optIn() depuis le code de votre application. L’invite système apparaît immédiatement.
Flux personnalisés où votre application maîtrise le déclencheur : centres de préférences, écrans de profil ou événements in-app qui justifient une invite.
Activez-les dans le tableau de bord OneSignal. Les utilisateurs reçoivent des notifications discrètes dans le Centre de notifications sans aucune invite et deviennent des abonnés complets en appuyant sur Keep.
Onboarding iOS et portée à faible friction. Combinez-les avec une invite douce pour convertir les abonnés silencieux en abonnés push complets.
Les trois peuvent être combinés. Un motif courant à haute performance sur iOS consiste à activer les notifications provisionnelles pour une portée silencieuse immédiate, à afficher une invite douce à un moment de valeur et à exposer une invite programmatique depuis un centre de préférences pour les utilisateurs qui souhaitent s’inscrire à la demande.
Une invite douce in-app suivie de l'invite de permission système.
Supprimer toutes les invites de permission automatiques
Avant de commencer, assurez-vous que votre application ne déclenche pas déjà automatiquement l’invite de permission système :
Supprimez tout appel requestPermission() ou optIn() invoqué au démarrage de l’application.
Supprimez les appels iOS natifs à requestAuthorizationWithOptions et tout code qui génère directement des jetons push.
Supprimez les appels Android à requestPermissions et tout code qui génère directement des jetons push.
2
Créer ou modifier le message in-app
Allez dans Messages > In-App, puis soit :
Modifiez le modèle Push Permission Prompt par défaut, soit
Cliquez sur New Message pour créer le vôtre.
Modifiez le modèle Push Permission Prompt par défaut ou créez le vôtre.
Définissez l’audience sur Show to all users. OneSignal filtre automatiquement ce message pour ne l’afficher qu’aux utilisateurs qui ne sont pas abonnés au push, en fonction de l’action de clic Push Permission Prompt.
Définissez l'audience sur « Show to all users ». L'action de clic Push Permission Prompt filtre automatiquement les utilisateurs non abonnés.
L'éditeur de blocs de messages in-app pour créer des messages d'opt-in push.
4
Ajouter l'action de clic Push Permission Prompt
Ajoutez une action de clic Push Permission Prompt à n’importe quel bouton ou image de votre message. Lorsque l’utilisateur appuie dessus, l’invite de permission système apparaît.
Ajout d'une action de clic Push Permission Prompt à un bouton.
L'invite de permission système déclenchée par l'action de clic sur iOS.
Si l’utilisateur a déjà refusé l’invite de permission système le nombre maximum de fois (une fois sur iOS, deux fois sur Android), l’action de clic l’envoie à la place vers les paramètres de notification de votre application. Cela équivaut à appeler requestPermission(fallbackToSettings: true) depuis le SDK.
Les messages in-app avec une action de clic Push Permission Prompt ne sont pas affichés aux utilisateurs qui ont déjà autorisé les notifications.
5
Choisir un déclencheur
L’audience contrôle qui est éligible pour voir le message. Les déclencheurs contrôlent quand il apparaît. Cherchez à déclencher l’invite à un moment de valeur : un moment où l’utilisateur vient de vivre quelque chose qui mérite une notification.
Options de déclencheur pour contrôler quand le message est affiché.
Options de déclencheur, classées approximativement de la plus faible à la plus forte conversion :
À l’ouverture de l’application. Simple, mais rarement optimal. À n’utiliser que si la valeur de l’application est évidente en quelques secondes.
Après une durée de session définie. Une bonne valeur par défaut. Attend que l’utilisateur ait exploré l’application avant de demander.
Sur un événement utilisateur spécifique. Le meilleur pour la conversion. Déclenchez après des actions à fort signal comme terminer l’onboarding, enregistrer un article, suivre un sujet ou finaliser un premier achat.
Par programmation, en utilisant les méthodes SDK de déclencheur de message in-app. Contrôle total sur le timing et le contexte, y compris la combinaison de plusieurs signaux avant de solliciter.
Par exemple, pour attendre que l’utilisateur ait passé au moins 5 minutes dans l’application :
Déclencheur configuré pour afficher le message après 5 minutes de temps de session.
6
Planification et fréquence
Contrôlez la fréquence d’apparition du message :
Only once. Faible chance de convertir les utilisateurs qui n’étaient pas prêts la première fois.
Every time conditions are met. Trop agressif et peut agacer les utilisateurs.
Multiple times (recommandé). Définissez un maximum par utilisateur avec un intervalle entre les affichages. Par exemple, 20 affichages avec un intervalle de 2 weeks relancent les utilisateurs non abonnés pendant environ 10 mois à un rythme agressif. Allongez l’intervalle (par exemple, 30 days ou 60 days) pour les applications à moindre engagement ou utilitaires, où un rythme de 2 semaines paraît insistant.
Paramètres de planification et de fréquence pour le message in-app.
Vous pouvez déclencher manuellement l’invite de permission système en utilisant les méthodes SDK requestPermission() ou optIn(). Cela est utile pour les flux personnalisés tels que :
Passez fallbackToSettings: true à requestPermission() afin que les utilisateurs qui ont déjà refusé soient redirigés vers les paramètres de notification de l’application au lieu de ne rien faire silencieusement.
Si un abonnement a été désinscrit au niveau du SDK via optOut() (affiché comme notification_types: -2 sur l’enregistrement de l’abonnement), requestPermission() seul ne changera pas le statut de l’abonnement. Utilisez plutôt optIn(). Cette méthode demande la permission et efface l’état de désinscription.
Les notifications push provisionnelles ont été introduites dans iOS 12. Elles vous permettent de livrer des notifications au Centre de notifications sans afficher d’invite de permission. Les utilisateurs voient du contenu réel de votre application et décident de conserver, mettre en silencieux ou désactiver les notifications en fonction de cette expérience.Pourquoi cela fonctionne comme stratégie :
Pas d’invite système à échouer. Vous pouvez commencer à toucher les utilisateurs dès leur première session sans décision d’opt-in initiale.
Les utilisateurs décident en fonction de la valeur réelle, pas d’une explication hypothétique.
Vous pouvez toujours afficher une invite douce plus tard pour convertir les utilisateurs provisionnels en abonnés push complets, avec bannières, son et alertes sur l’écran de verrouillage.
Compromis. Les notifications provisionnelles ont une visibilité réduite. Elles sont livrées silencieusement au Centre de notifications uniquement : pas de bannière, pas de son et pas d’alerte sur l’écran de verrouillage tant que l’utilisateur n’accorde pas la permission complète.
Une notification provisionnelle invitant l'utilisateur à conserver ou désactiver les notifications.
Pour activer l’autorisation provisionnelle, allez dans le tableau de bord OneSignal sous Settings > Apple iOS > Advanced Configuration et cochez Enable iOS 12 direct to history. Pour la présentation complète, incluant la manière dont les utilisateurs interagissent avec les notifications provisionnelles et comment elles se combinent avec l’invite standard, voir Notifications push provisionnelles iOS.
Que se passe-t-il si un utilisateur refuse l’invite de permission système ?
Sur iOS, refuser l’invite de permission système désactive définitivement les notifications push de votre application. L’invite ne peut pas être affichée à nouveau. Sur Android, l’utilisateur a droit à une chance supplémentaire (deux au total). Une fois toutes les tentatives utilisées, l’utilisateur doit réactiver manuellement les notifications dans Paramètres > Notifications sur son appareil. L’action de clic Push Permission Prompt et requestPermission(fallbackToSettings: true) gèrent tous deux ce cas en envoyant l’utilisateur directement à ses paramètres de notification.
Puis-je personnaliser l’invite de permission système native ?
Non. L’invite de permission système sur iOS et Android est contrôlée par le système d’exploitation et ne peut pas être personnalisée. Vous ne pouvez personnaliser que l’invite douce (le message in-app affiché avant elle). Utilisez l’invite douce pour expliquer la valeur de vos notifications, définir les attentes et augmenter les chances d’un « Allow » sur l’invite système.
Puis-je encore inviter les utilisateurs qui reçoivent des notifications provisionnelles ?
Oui, et vous devriez le faire. Les utilisateurs provisionnels sont des candidats de choix pour une invite douce car ils ont déjà vu de vraies notifications de votre application. Voir Utiliser les notifications provisionnelles iOS pour le motif recommandé. Programmez l’invite douce juste après que l’utilisateur a ouvert une notification provisionnelle ou interagi avec elle.
Comment relancer les utilisateurs qui ont précédemment refusé le push ?
Une fois l’invite de permission système épuisée (une fois sur iOS, deux fois sur Android), vous ne pouvez plus l’afficher. Utilisez à la place la méthode SDK requestPermission(fallbackToSettings: true) ou l’action de clic Push Permission Prompt sur un message in-app. Toutes deux ouvrent les paramètres de notification de votre application afin que l’utilisateur puisse activer manuellement les notifications. Associez cela à un message in-app expliquant pourquoi les notifications sont précieuses.
Toutes les versions d’Android nécessitent-elles une invite de permission système ?
Non. Uniquement Android 13 (niveau d’API 33) et versions ultérieures. Android 13 a introduit la permission de notification à l’exécution, exigeant le consentement explicite de l’utilisateur pour les notifications push.
Publication : août 2022 (appareils Pixel).
Requis pour le SDK cible : depuis le 31 août 2023, toutes les nouvelles applications et mises à jour sur Google Play doivent cibler le niveau d’API 33 ou supérieur.
