Comprendre la distribution des notifications push
Découvrez la diffusion des notifications push, notamment le mode de diffusion et les raisons pour lesquelles elle peut échouer.
Distribution des notifications push
La diffusion des notifications push correspond au moment où une notification push est diffusée avec succès sur l’appareil d’un destinataire.
Un profil peut avoir plus d’un jeton push s’il a votre application mobile installée sur plusieurs appareils. Des notifications push seront tentées pour tous les appareils disposant d’un jeton stocké sur le profil.
Le concept de délivrabilité ne s’applique pas aux notifications push comme il s’applique à l’e-mail, car aucun tri n’est effectué une fois que l’appareil du destinataire a bien reçu la notification.
Lorsque vous envoyez une notification push via une campagne ou un flux, Klaviyo vérifie la notification push, puis l’envoie au service Apple Push Notification Service (APNs) pour iOS, ou au service de notification push Android, Firebase Cloud Messaging (FCM), afin qu’elle soit remise sur l’appareil du destinataire. Vous pouvez voir certaines notifications push ignorées s’il y a un problème de livraison.
APNs et FCM accepteront soit la notification et tenteront de la transmettre à l’appareil du destinataire, soit rejetteront la notification avec une série d’erreurs possibles.
Klaviyo a uniquement des insights sur le fait que ces services acceptent la notification ou la rejettent. Klaviyo ne peut pas confirmer si la notification échoue après qu’APNs ou FCM a accepté la notification push.
Vous souhaitez demander une fonctionnalité pour les notifications push de Klaviyo ? Remplissez ce formulaire Google pour nous en parler !
Motifs de rejet
Si Klaviyo reçoit une réponse d’erreur de la part d’APNs ou de FCM après l’envoi d’une notification, un événement intitulé Notification push rejetée est créé pour chaque jeton affecté par l’échec de la livraison. Cela apparaîtra dans le fil d’activité du profil du destinataire, avec l’activité du destinataire pour le flux ou la campagne dont la notification a été envoyée.
L’événement Push rejeté inclut des métadonnées qui affichent le message du code d’erreur (par ex., ExpiredToken) renvoyé par APNs ou Firebase. Si vous constatez des problèmes de distribution, travaillez avec votre développeur d’application pour résoudre l’erreur en fonction de la description dans l’événement.
Pour afficher les métadonnées d’un événement, cliquez sur Détails de l’activité pour l’événement dans le journal d’activité du profil.
Notification push silencieuse
Vous pouvez consulter le taux de livraison et le taux de rebond d’une notification push silencieuse individuelle ; toutefois, les notifications push silencieuses sont exclues de tout reporting de performance agrégé dans Klaviyo. Cela inclut des éléments comme le taux d’ouverture des notifications Push mobiles au fil du temps, puisqu’elles n’ont pas d’ouvertures ni de conversion.
Veuillez noter que vous verrez des événements différents pour les notifications push silencieuses que pour les notifications push standard, à savoir Received Silent Push et Bounced Silent Push.
Si vous rencontrez des problèmes de notifications push silencieuses sur iOS, notez qu’iOS ne garantit pas la distribution des notifications push silencieuses. Il se peut qu’elles ne soient pas distribuées en fonction de l’état actuel de l’appareil, comme le niveau de batterie et la connexion réseau.
iOS
Pour les notifications push iOS envoyées via APNs, des rejets peuvent se produire pour au moins l’une des raisons listées dans la référence d’Apple sur la gestion des réponses aux notifications d’APNs.
Code de statut | Chaîne d’erreur APNs | Description d’APNs |
400 | BadDeviceToken | Le jeton d’appareil spécifié n’était pas valide. Vérifiez que la requête contient un jeton valide et que le jeton correspond à l’environnement. |
400 | Mauvais sujet | La valeur apns-topic n’est pas valide. |
400 | DeviceTokenNotForTopic | Le jeton de l’appareil ne correspond pas au sujet spécifié. |
400 | En-têtes en double | Un ou plusieurs en-têtes ont été répétés. |
400 | IdleTimeout | Délai d’inactivité écoulé. |
400 | Type de notification push non valide | La valeur apns-push-type n’est pas valide. |
400 | Charge utile vide | La charge utile du message était vide. |
403 | Certificat non valide | Le certificat était mauvais. |
403 | BadCertificateEnvironment | Le certificat client correspondait au mauvais environnement. |
403 | Jeton de fournisseur non valide | Le jeton du fournisseur n’est pas valide ou la signature du jeton n’a pas pu être vérifiée. |
404 | BadPath | La demande contenait une valeur :path incorrecte. |
405 | Méthode non autorisée | La méthode spécifiée :method n'était pas POST. |
410 | Jeton expiré | Le jeton de l’appareil a expiré. |
410 | Non enregistré | Le jeton d’appareil est inactif pour le sujet spécifié. |
429 | Trop de mises à jour du jeton du fournisseur | Le jeton du fournisseur est mis à jour trop souvent. |
500 | Erreur interne du serveur | Une erreur interne du serveur s’est produite. |
503 | Service indisponible | Le service est indisponible. |
Android
Pour les notifications push Android envoyées via FCM, des refus peuvent se produire pour au moins l’une des raisons répertoriées dans la référence de Google sur les codes d’erreur FCM.
Code de statut | Chaîne d’erreur FCM | Description de FCM |
400 | INVALID_ARGUMENT | Vérifiez le format du jeton d’enregistrement que vous transmettez au serveur. Assurez-vous qu’il correspond au jeton d’enregistrement que l’application cliente reçoit lors de l’enregistrement auprès de Firebase Notifications. Ne le tronquez pas et n’ajoutez pas de caractères supplémentaires. |
400 | INVALID_ARGUMENT | Assurez-vous que le message a été adressé à un jeton d’enregistrement dont le nom du package correspond à la valeur transmise dans la requête. |
400 | INVALID_ARGUMENT | Vérifiez que la taille totale des données de payload incluses dans un message ne dépasse pas les limites de FCM : 4096 octets pour la plupart des messages, ou 2048 octets dans le cas des messages envoyés à des topics. Cela inclut à la fois les clés et les valeurs. |
400 | INVALID_ARGUMENT | Vérifiez que les données de la charge utile ne contiennent pas une clé (telle que from, ou gcm, ou toute valeur dont le préfixe est google) qui est utilisée en interne par FCM. Notez que certains mots (tels que collapse_key) sont également utilisés par FCM, mais sont autorisés dans la charge utile ; dans ce cas, la valeur de la charge utile sera remplacée par la valeur FCM. |
400 | INVALID_ARGUMENT | Vérifiez que la valeur utilisée dans ttl est un entier représentant une durée en secondes comprise entre 0 et 2 419 200 (4 semaines). |
400 | INVALID_ARGUMENT | Vérifiez que les paramètres fournis ont le bon nom et le bon type. |
403 | SENDER_ID_MISMATCH | L’identifiant d’expéditeur authentifié est différent de l’identifiant d’expéditeur du jeton d’inscription. |
404 | NON ENREGISTRÉ | L’instance d’application a été désinscrite de FCM. Cela signifie généralement que le jeton utilisé n’est plus valide et qu’un nouveau doit être utilisé. |
429 | QUOTA_EXCEEDED | Limite d’envoi dépassée pour le destinataire du message. Une extension de type google.rpc.QuotaFailure est renvoyée afin de préciser quel quota a été dépassé. |
500 | INTERNE | Une erreur interne inconnue s’est produite. |
503 | Indisponible | Le serveur est surchargé. |
Vous verrez également un événement Push rejeté si le destinataire est manquant ou possède un jeton push non valide.
Bonnes pratiques
Collecter le consentement des utilisateurs
Pour envoyer une notification push standard à un profil, vous devez d’abord obtenir son consentement explicite .
Pour recueillir le consentement pour l’envoi de notifications push, vous devez afficher aux clients une demande d’autorisation lors de leur première interaction avec votre application mobile.
La bonne pratique consiste à y inclure une mention légale qui fournit les informations suivantes. Les utilisateurs peuvent alors accepter ou refuser la demande :
- Types de notifications envoyées par votre marque
Indiquez de façon détaillée quelles sont les différentes notifications push que votre marque prévoit d’envoyer (par exemple, modifications apportées au compte, rappels et offres spéciales). - Raisons pour lesquelles les utilisateurs devraient donner leur accord
Indiquez pourquoi un client aurait intérêt à accorder ces autorisations (par exemple, pour recevoir des informations importantes ou bénéficier d’un accès anticipé aux offres).
Pour en savoir plus, consultez notre article sur le consentement pour l’envoi de notifications push.
Envoyer des notifications pertinentes
Lors de l’envoi de campagnes de notification push, il est important de tirer parti de la segmentation de Klaviyo afin d’envoyer un contenu personnalisé et pertinent à vos abonnés.
Par exemple, si vous savez que vous avez un segment de clients réguliers fidèles, vous pourriez utiliser des notifications push pour les informer de nouvelles offres ou promotions avant tout le monde.
En veillant à ce que le contenu que vous envoyez aux clients soit pertinent par rapport à leurs centres d’intérêt et à leurs préférences, vous pouvez réduire la probabilité que les clients se désabonnent et maximiser votre capacité à atteindre vos clients avec des notifications push.
Surveiller et analyser les performances
Il est essentiel de surveiller en continu les performances de vos notifications push avec Klaviyo afin d’identifier rapidement les problèmes de distribution et les baisses des principaux indicateurs push.
La meilleure façon de procéder est de surveiller les événements de notification push suivants :
- Received push
- Notification push ouverte
- Rebond de notification push
Vous pouvez configurer un rapport sur plusieurs indicateurs dans Klaviyo afin de surveiller l’évolution de vos performances pour ces événements au fil du temps.