Bonnes pratiques pour les notifications push
Cette page présente les bonnes pratiques et les cas d’usage des notifications push pour que vos messages suscitent l’engagement plutôt que l’agacement.
Les notifications push sont des outils puissants pour interagir avec les utilisateurs de votre application, mais elles doivent être utilisées avec précaution afin de garantir la diffusion de messages pertinents et opportuns. Avant d’envoyer votre notification push, consultez les bonnes pratiques suivantes pour connaître les points importants à vérifier.

Vos notifications push doivent respecter les directives de l’Apple App Store et les politiques du Google Play Store, notamment en ce qui concerne l’utilisation des notifications push comme publicités, spam, promotions, etc. Sur cette page, consultez la section Réglementations relatives aux notifications push.
Rédigez votre notification push
En tant que bonne pratique, Braze recommande de limiter chaque ligne de texte, aussi bien pour le titre optionnel que pour le corps du message, à environ 30 à 40 caractères dans une notification push mobile. Notez que le compteur de caractères du compositeur ne tient pas compte des caractères Liquid. Cela signifie que le nombre final de caractères d’un message dépend de la façon dont Liquid est rendu pour chaque utilisateur. En cas de doute, faites court et concis.
Réduire la taille du payload des notifications push
La taille maximale du payload dépend de la plateforme.
| Plateforme | Taille maximale du payload |
|---|---|
| Web | 3 807 octets |
| Android | 3 930 octets |
| iOS | 3 960 octets |
| Kindle | 5 985 octets |
Si votre notification push dépasse la taille maximale du payload, le message risque de ne pas être envoyé. En tant que bonne pratique, limitez votre payload à quelques centaines d’octets.
Qu’est-ce qu’un payload de notification push ?
Les fournisseurs de services push déterminent si votre notification push peut être affichée à un utilisateur en examinant la taille en octets de l’ensemble du payload. Le payload est limité à 4 Ko (4 096 octets) pour la plupart des services push, notamment :
- Apple Push Notification service (APNs)
- Firebase Cloud Messaging (FCM) d’Android
- Notification push Web
- Push Huawei
Ces services push refuseront toute notification dépassant cette limite.
Braze réserve une partie du payload pour l’intégration et l’analyse. En conséquence, notre taille maximale de payload est de 3 807 octets. Si votre notification push dépasse cette taille, le message risque de ne pas être envoyé. En tant que bonne pratique, limitez votre payload à quelques centaines d’octets.
Les éléments suivants de votre notification push composent votre payload :
- Le texte, comme le titre et le corps du message
- Le rendu final de toute personnalisation Liquid
- Les URL des images (mais pas la taille de l’image elle-même)
- Les URL des cibles de clic
- Les noms des boutons
- Les paires clé-valeur
Conseils pour réduire la taille du payload
Pour réduire la taille du payload :
- Rédigez un message bref. Une bonne règle générale est de le rendre exploitable et utile en moins de 40 caractères.
- Supprimez les espaces superflus et les retours à la ligne de votre texte.
- Réfléchissez au rendu de Liquid au moment de l’envoi. Étant donné que le rendu final de toute personnalisation Liquid varie d’un utilisateur à l’autre, Braze ne peut pas déterminer si un payload de notification push dépassera la limite de taille lorsque du Liquid est inclus. Si votre Liquid génère un message plus court, cela peut convenir. Cependant, si votre Liquid produit un message plus long, votre notification push risque de dépasser la limite de taille du payload. Testez toujours votre notification push sur un appareil réel avant de l’envoyer aux utilisateurs.
- Envisagez de raccourcir les URL à l’aide d’un outil de raccourcissement d’URL.
Optimiser le ciblage
Collecter les données utilisateur pertinentes
Les notifications push doivent être utilisées avec soin pour cibler les utilisateurs avec des notifications opportunes et pertinentes. Braze collecte des informations utiles sur les appareils et l’utilisation, qui peuvent être utilisées pour cibler des Segments pertinents. Ces informations doivent être complétées par des événements personnalisés et des attributs personnalisés spécifiques à votre application. En exploitant ces données, vous pouvez cibler vos messages avec précision pour augmenter les taux d’ouverture et réduire le nombre d’utilisateurs qui désactivent les notifications push.
Créer une page de paramètres de notification
Vous pouvez créer une page de paramètres dans votre application qui permet aux utilisateurs d’indiquer les notifications qu’ils souhaitent recevoir. Une approche courante consiste à créer un attribut personnalisé booléen dans Braze correspondant au statut du paramètre de l’application. Par exemple, une application d’actualités pourrait proposer des paramètres d’abonnement pour les dernières nouvelles, les actualités sportives ou la politique.
Lorsque l’application d’actualités souhaite créer une Campaign ciblant uniquement les utilisateurs intéressés par la politique, il suffit d’ajouter le filtre d’attribut Subscribes to Politics au Segment. Lorsqu’il est défini sur vrai, seuls les utilisateurs qui se sont abonnés aux notifications les recevront.
Pour plus d’informations sur la définition des attributs personnalisés, consultez les articles suivants pour iOS, Android ou la REST API.
Augmenter les abonnements et la pertinence
Obtenir l’autorisation de l’utilisateur
Les statistiques générales relatives à l’activation des notifications push indiquent si l’utilisateur a approuvé les notifications auprès de son système d’exploitation. Si les utilisateurs désactivent les notifications sur iOS, ils seront automatiquement retirés de notre système, car Apple n’autorise pas l’envoi du jeton push.
Android 13 et versions ultérieures nécessitent l’obtention d’une autorisation avant de pouvoir afficher les notifications push. Les versions antérieures d’Android abonnent les utilisateurs aux notifications par défaut.
Préparer les utilisateurs aux notifications push
Vous n’avez qu’une seule occasion de demander à un utilisateur l’autorisation pour les notifications push, et après un refus, il est très difficile de le convaincre de réactiver les notifications push dans les paramètres de son appareil. C’est pourquoi vous devriez préparer les utilisateurs aux notifications push à l’aide d’un message in-app avant d’afficher l’invite système. Consultez Messages in-app d’amorce push pour en savoir plus sur l’augmentation des abonnements.
Ajouter des contrôles d’abonnement push
Pour éviter que les utilisateurs ne désactivent les notifications au niveau de l’appareil, ce qui supprime complètement leur jeton push de premier plan, permettez-leur de contrôler leur abonnement push directement dans votre application. Consultez Mettre à jour les états d’abonnement push pour plus de détails.
Utiliser la planification avancée ou ajouter des délais
En fonction de la taille de votre audience et du délai entre la planification et l’envoi de votre notification push, des retards dans la distribution des notifications push peuvent survenir. Le temps nécessaire pour envoyer les notifications push dépend de la puissance de traitement allouée. Par exemple, si votre notification push utilise plusieurs appels de contenu connecté, cela peut augmenter la complexité du templating de la notification push et entraîner des vitesses limitées par la rapidité avec laquelle vos API tierces renvoient les données.
Un payload push plus petit et une priorité de notification plus élevée peuvent aider à réduire les délais et à faire monter en charge vos messages. Vous pouvez ajouter Push Enabled = true dans votre filtre d’audience pour réduire la taille de l’audience afin que seuls les utilisateurs avec les notifications push activées soient pris en compte pour l’envoi de la Campaign.
Nous recommandons également de minimiser le nombre d’appels API en optimisant les données dont vous avez besoin. Si possible, essayez d’obtenir toutes les données nécessaires en un seul appel API plutôt que d’effectuer plusieurs appels.
Comprendre les états d’abonnement push
L’état d’abonnement push ne garantit pas qu’une notification push sera distribuée : les utilisateurs doivent également avoir les notifications push activées pour recevoir des notifications. En effet, un profil utilisateur peut avoir plusieurs appareils avec des autorisations push de premier plan différentes, mais un seul état d’abonnement push.
Si un utilisateur ne dispose pas d’un jeton push de premier plan valide pour une application (c’est-à-dire qu’il désactive les jetons push au niveau de l’appareil via les paramètres, en choisissant de ne pas recevoir de notifications), son état d’abonnement peut toujours être considéré comme subscribed aux notifications push. Cependant, cet utilisateur ne sera pas Foreground Push Enabled for App dans Braze, car le jeton push de premier plan n’est pas valide.
De plus, si un profil utilisateur ne possède aucun jeton push valide ou enregistré pour d’autres applications, le filtre Foreground Push Enabled dans la segmentation sera également défini sur false.
Mettre en place une politique de désengagement pour les utilisateurs non réactifs
Même lorsque vous envoyez uniquement des notifications push pertinentes et opportunes, certains utilisateurs peuvent rester insensibles et les percevoir comme du spam. Supposons qu’un utilisateur montre un historique d’ignorance répétée de vos notifications push. Dans ce cas, il est judicieux de cesser de lui envoyer des notifications push avant qu’il ne soit agacé par les communications de votre application ou ne la désinstalle complètement.
Pour ce faire, créez une politique de désengagement qui finit par arrêter l’envoi de notifications push aux utilisateurs n’ayant pas eu d’ouverture directe ou influencée depuis longtemps.
- Identifiez les utilisateurs non réactifs en fonction des ouvertures directes ou influencées.
- Réduisez progressivement l’envoi de notifications push à ces utilisateurs.
- Avant de supprimer complètement les notifications push, envoyez une dernière notification expliquant pourquoi ils n’en recevront plus. Cela donne aux utilisateurs la possibilité de manifester leur intérêt pour la poursuite des notifications push en ouvrant cette notification.
- Une fois la politique de désengagement en vigueur, utilisez un message in-app pour rappeler à ces utilisateurs que, même s’ils ne recevront plus de notifications push, les canaux de communication in-app continueront de leur transmettre des informations intéressantes et utiles.
Bien que vous puissiez être réticent à l’idée de cesser d’envoyer des notifications push à des utilisateurs qui se sont initialement abonnés, n’oubliez pas que d’autres canaux de communication peuvent atteindre ces utilisateurs plus efficacement, surtout s’ils ont précédemment ignoré vos notifications push. Si l’utilisateur ouvre vos e-mails, les Campaigns par e-mail sont un bon moyen de le contacter en dehors de votre application. Sinon, les messages in-app constituent la meilleure façon de diffuser du contenu sans risquer que l’utilisateur désinstalle votre application.
Définir des événements de conversion pour les ouvertures d’application
Lorsque vous attribuez des événements de conversion à une Campaign de notification push, vous pouvez suivre les ouvertures d’application pendant une certaine période après la réception de la Campaign. La définition d’un événement de conversion pour les ouvertures d’application fournit des informations différentes des statistiques de résultats que vous recevez normalement après une Campaign de notification push.
Bien que tous les résultats d’une Campaign de notification push détaillent les ouvertures directes et les ouvertures totales d’un message (qui incluent à la fois les ouvertures directes et les ouvertures influencées), le suivi des conversions comptabilise tout type d’ouverture, qu’elle soit directe ou influencée.
De plus, en utilisant l’événement de conversion « ouvre l’application », vous suivez les ouvertures d’application qui se produisent avant la date limite de conversion (par exemple, trois jours). Cela diffère d’une ouverture influencée dans la mesure où le délai dont dispose un utilisateur pour enregistrer une ouverture influencée peut varier d’une personne à l’autre, en fonction du comportement d’engagement passé de chaque utilisateur.
Réglementations relatives aux notifications push
Étant donné que les notifications push sont un type de communication intrusif qui arrive directement sur le téléphone ou le navigateur de vos clients, il existe des directives encadrant l’envoi de notifications push via les applications et les sites.
Réglementations relatives aux notifications push mobiles pour les applications
| Politiques de l’Apple App Store |
|---|
| 3.2.2 Inacceptable : (i) Créer une interface pour afficher des applications tierces, des extensions ou des plug-ins de manière similaire à l’App Store ou sous forme de collection d’intérêt général. |
| 4.5.4 Les notifications push ne doivent pas être nécessaires au fonctionnement de l’application et ne doivent pas être utilisées pour envoyer des informations personnelles sensibles ou confidentielles. Les notifications push ne doivent pas être utilisées à des fins de promotion ou de marketing direct, sauf si les clients ont explicitement accepté de les recevoir via un texte de consentement affiché dans l’interface utilisateur de votre application, et que vous fournissez dans votre application un moyen de se désabonner de ces messages. |
| 4.10 Vous ne pouvez pas monétiser les fonctionnalités intégrées fournies par le matériel ou le système d’exploitation, telles que les notifications push, l’appareil photo ou le gyroscope, ni les services et technologies Apple, tels que l’accès à Apple Music, le stockage iCloud ou les API Screen Time. |
| Politique du Google Play Store |
|---|
| Utilisation non autorisée ou imitation de fonctionnalités système Nous n’autorisons pas les applications ou les publicités qui imitent ou interfèrent avec les fonctionnalités système, telles que les notifications ou les avertissements. Les notifications au niveau du système ne peuvent être utilisées que pour les fonctionnalités essentielles d’une application, par exemple une application de compagnie aérienne qui informe les utilisateurs d’offres spéciales, ou un jeu qui informe les utilisateurs de promotions en jeu. |
Articles connexes
Vous n’avez pas trouvé ce que vous cherchiez ? Consultez ces articles supplémentaires sur les bonnes pratiques :