Remarque : Il n'y a pas de documentation héritée disponible pour cet élément, vous voyez donc la documentation actuelle.
Vous pouvez amener vos abonnés aux notifications push de vos applications iOS et Android existantes vers PushEngage en réutilisant les mêmes identifiants Apple et Firebase que votre application utilise déjà. Comme les jetons d'appareil sont émis par Apple et Google plutôt que par votre fournisseur de notifications push, conserver ces identifiants permet à vos jetons de continuer à fonctionner après le changement. Ce guide explique comment la migration fonctionne et les étapes pour la configurer. La migration est un processus backend géré conjointement avec notre équipe.
Avant de commencer
- Créez votre compte PushEngage.
- Ayez accès à vos identifiants de notifications push Apple, spécifiquement votre App Push ID et le certificat p12 de votre compte développeur Apple.
- Ayez accès à vos paramètres Firebase Android, spécifiquement votre Firebase Sender ID.
- Ayez un moyen d'exporter vos données d'abonnés depuis votre fournisseur actuel.
Comment fonctionne la migration d'applications mobiles
Les jetons d'appareil pour les notifications push d'application proviennent du service de notifications push Apple (APNs) et de Firebase Cloud Messaging (FCM), pas de votre fournisseur actuel. Si vous configurez PushEngage avec les mêmes identifiants APNs et FCM que vous utilisez déjà, ces jetons restent valides et la migration se fait en backend.
La permission de notification est également conservée. Si un utilisateur a déjà accordé la permission de notification dans votre application, il n'aura pas besoin de l'accorder à nouveau après la migration.
Étapes pour migrer
Étape 1 : Exportez vos abonnés de votre fournisseur actuel
Exportez vos données d'abonnés en utilisant l'une des méthodes proposées par votre fournisseur :
- Exportation API, en utilisant l'ID d'application et la clé API de votre fournisseur actuel.
- Exportation CSV, avec un fichier incluant
identifier,device_type,language, et tout autre champ pertinent.
Étape 2 : Configurez FCM Android dans PushEngage
- Connectez-vous au tableau de bord PushEngage.
- Allez dans Paramètres » Installation » SDK Android.
- Configurez les paramètres FCM Android de Google en utilisant le même Firebase Sender ID que vous utilisez déjà.
Étape 3 : Configurez APNs iOS dans PushEngage
- Dans le tableau de bord PushEngage, allez dans Paramètres » Installation » SDK iOS.
- Configurez les paramètres APNs iOS d'Apple en utilisant le même App Push ID de votre configuration actuelle.
- Téléchargez le certificat p12 de votre compte développeur Apple, le même que vous utilisez déjà.
Notes importantes sur le passage à la nouvelle version de l'application
La migration des notifications push d'application dépend de la version de votre application qu'un abonné utilise, alors planifiez soigneusement votre passage à la nouvelle version.
- Anciennes versions de l'application avec le SDK du fournisseur précédent. Après la migration, les abonnés utilisant toujours d'anciennes versions de l'application ne recevront pas les notifications envoyées depuis PushEngage, car la charge utile PushEngage ne pourra pas être décodée par l'ancien SDK.
- Nouvelles versions de l'application avec le SDK PushEngage. Si vous envoyez depuis le tableau de bord de votre ancien fournisseur après la migration, ces notifications n'apparaîtront pas sur les nouvelles versions de l'application, car l'ancien payload ne peut pas être décodé par le SDK PushEngage.
En bref, envoyez depuis PushEngage pour les utilisateurs de la nouvelle version de l'application, et attendez-vous à ce que les utilisateurs qui n'ont pas mis à jour migrent au fur et à mesure qu'ils mettent à jour l'application.
Questions fréquemment posées
Les abonnés doivent-ils à nouveau accorder la permission de notification ?
Non. Si la permission a déjà été accordée dans votre application, elle n'a pas besoin d'être accordée à nouveau après la migration.
Tous les abonnés recevront-ils des notifications juste après la migration ?
Les utilisateurs de la nouvelle version de l'application avec le SDK PushEngage le feront. Les utilisateurs toujours sur une ancienne version de l'application avec le SDK de l'ancien fournisseur ne recevront pas les notifications PushEngage tant qu'ils n'auront pas mis à jour l'application.
Pourquoi dois-je réutiliser les mêmes identifiants APNs et Firebase ?
Parce que les jetons d'appareil sont liés à ces identifiants. La réutilisation du même identifiant d'application Push, du certificat p12 et de l'ID de l'expéditeur Firebase maintient la validité de vos jetons existants, ce qui rend la migration possible sans demander aux utilisateurs de se réenregistrer.
De quelles données ai-je besoin de la part de mon fournisseur actuel ?
Soit une exportation API utilisant l'ID d'application et la clé API de votre fournisseur, soit un CSV incluant au moins identifier, device_type et language, ainsi que tout autre champ pertinent.
Si vous rencontrez des problèmes, n'hésitez pas à nous contacter en cliquant ici. Notre équipe d'assistance pourra vous aider.
