Notifications mobiles : autorisation, moment, limites
Quand demander l'autorisation, quel évènement mérite une notification et où la fréquence doit s'arrêter : garder l'attention sans la perdre.
Équipe rabbitclipPublié: 6 min de lecture
En bref
Une stratégie de notification consiste à définir à l'avance quand l'autorisation est demandée, quel évènement devient une notification et où la fréquence d'envoi s'arrête. La demande d'autorisation n'a pas sa place sur l'écran d'accueil ; elle vient après que la personne a déjà vu un bénéfice dans l'application, car chaque notification redemande de l'attention, et si rien n'est rendu en retour, l'application est supprimée ou les notifications sont désactivées.
Apple et Android lient tous deux l'autorisation à une seule boîte de dialogue système : une fois refusée, l'application ne peut plus la montrer à nouveau, la personne doit ouvrir les réglages elle-même pour l'activer. Cela fait du moment, du texte et du contexte de la première demande une décision sans deuxième chance.
Cet article couvre le bon moment pour demander l'autorisation, les évènements qui méritent une notification, la façon dont le moment et la fréquence sont fixés, ce que la personnalisation change réellement, les erreurs qui reviennent et ce qu'il faut faire une fois l'autorisation refusée.
Quand demander l'autorisation de notification
La demande arrive juste après qu'une personne termine une action : une commande passée, un rendez-vous réservé, un article ajouté à une liste d'envies. À ce moment, la personne attend déjà un bénéfice de l'application, alors la question de suivre ce statut par notification apparaît comme une suite naturelle plutôt qu'une interruption.
Une demande affichée sur l'écran d'accueil ou lors de la première session obtient le taux d'acceptation le plus bas, car la personne n'a pas encore vu ce que l'application lui apporte. Dans une application de salle de sport, déplacer la demande juste après la première réservation de cours, plutôt qu'au premier lancement, augmente nettement le taux d'acceptation.
Un écran de pré-permission affiché avant la boîte de dialogue système est également courant : il explique à quoi sert la notification, et la boîte de dialogue système ne se déclenche que lorsque la personne est prête. Cet écran compense en partie le fait qu'un refus ne peut pas être redemandé.
Quels évènements méritent une notification
Un évènement mérite une notification seulement s'il a un sens spécifiquement pour cette personne. Une commande expédiée, un rendez-vous qui approche, un article laissé dans le panier qui se fait rare en stock : tout cela concerne une action propre à la personne.
Une annonce générale, un rappel de campagne ou une mise à jour de l'application appartiennent à une autre catégorie : ils partent vers tout le monde en même temps et ne portent aucune urgence personnelle. Dans l'application d'un fabricant de vêtements de travail, envoyer une notification de nouvelle collection à la même fréquence qu'une notification de commande expédiée use la confiance que porte la seconde.
Cette distinction impose deux canaux de notification séparés dans l'application : la personne peut laisser les notifications transactionnelles actives tout en désactivant les notifications marketing. Sans cette option, elle a tendance à désactiver les deux, perdant aussi l'information transactionnelle.
Comment le moment et la fréquence se déterminent
Le moment ne dépend pas du fait que la personne regarde son téléphone à cet instant, mais du fait que la notification a un sens à ce moment précis. Dans une application de réservation de restaurant, un rappel une heure avant la table est utile ; le même message à minuit devient une intrusion.
Il n'existe pas un chiffre unique pour la fréquence, cela dépend du cas. Les notifications transactionnelles partent dès l'évènement, les notifications marketing restent généralement limitées à quelques fois par semaine. Dans l'application d'une chaîne de spas, envoyer plus d'une notification marketing par jour fait nettement grimper le taux de désactivation ; chaque application doit le mesurer pour elle-même.
Le fuseau horaire compte aussi : envoyer selon une seule horloge serveur plutôt que selon le fuseau de la personne peut faire atterrir une notification de campagne à trois heures du matin, ce qui ne rend pas service à la marque ; une application multi-pays ne peut pas se fier à une heure d'envoi fixe.
Ce que la personnalisation change réellement
La personnalisation ne consiste pas à insérer le prénom dans le message, mais à construire un message différent selon ce que la personne a réellement fait. Dans une application d'achat, le message envoyé à quelqu'un qui a laissé un article dans son panier ne devrait pas ressembler à celui envoyé à quelqu'un qui parcourt les nouveautés ; l'un pointe vers une action inachevée, l'autre vers la découverte.
L'envoi par cohorte regroupe les personnes selon la dernière connexion, l'historique d'achat ou un intérêt déclaré, et envoie un message différent à chaque groupe. Sans ce regroupement, un seul message envoyé à tout le monde finit par être hors sujet pour certains et trop tardif pour d'autres.
La personnalisation implique aussi de collecter des données ; ce qui est collecté et comment cela est conservé relève d'un sujet distinct, qui doit être clairement précisé dans la politique de confidentialité de l'application au titre du RGPD.
Erreurs fréquentes
Trois erreurs reviennent : demander l'autorisation au premier lancement avant tout bénéfice visible, garder les notifications transactionnelles et marketing sur un seul canal, et ne proposer aucun écran permettant de gérer ses propres préférences.
- Demander l'autorisation au premier lancement, avant tout bénéfice visible
- Ne pas séparer les notifications transactionnelles des notifications marketing
- Ne laisser aucun moyen de contrôler soi-même la fréquence
- Envoyer la même information par push, e-mail et message in-app en même temps
- Envoyer en masse sans tenir compte du fuseau horaire de la personne
Que faire une fois l'autorisation refusée
Un refus ne met pas fin à la relation : un badge in-app, une mise à jour de statut dans une vue liste ou un e-mail peuvent porter la même information. Dans une application de gestion d'immeuble, une personne sans autorisation de notification peut tout de même voir le rappel de charges sur l'écran d'accueil dès l'ouverture de l'application.
Un lien renvoyant vers les réglages peut être proposé avec délicatesse dans l'application, mais l'afficher à chaque lancement devient une gêne. Le montrer une fois puis attendre est l'approche la plus juste pour l'expérience utilisateur.
Une stratégie de notification commence par une autorisation demandée au bon moment, se poursuit en répartissant les évènements dans le bon canal, et tient tant que la fréquence reste sous le contrôle de la personne. Lors d'un appel découverte avec rabbitclip, le flux de notification existant est examiné et les évènements méritant une notification sont clarifiés ensemble.
Questions fréquentes
Combien de fois peut-on demander l'autorisation de notification ?
La boîte de dialogue système ne peut plus être montrée après un refus ; la personne doit l'activer elle-même dans les réglages, d'où l'importance du moment de la première demande.
Quelle différence entre une notification push et un message in-app ?
Une notification push apparaît même téléphone verrouillé, un message in-app seulement application ouverte ; les deux servent des niveaux d'urgence différents.
Faut-il séparer les notifications transactionnelles des notifications marketing ?
Oui ; sans canaux séparés, les personnes ont tendance à désactiver les deux ensemble et à perdre aussi l'information transactionnelle.
Comment la fréquence des notifications affecte-t-elle la rétention ?
Une fréquence trop élevée pousse à désactiver complètement les notifications ; la bonne fréquence doit être mesurée séparément pour chaque application et groupe d'utilisateurs.
