Migration vers OneSignal

• Les développeurs implémentant le SDK OneSignal
• Les spécialistes du marketing gérant les campagnes et l’analytique

​

Prérequis

• Créez un compte sur OneSignal
• Invitez votre équipe

​

Étapes de migration

​

1. Auditez votre configuration de messagerie actuelle

• Les plateformes que vous prenez en charge : iOS, Android, Web, email, SMS, etc.
• Le code gérant les événements de notifications push et de messages in-app :
  • Affichage en premier plan et gestion des clics
  • Utilisation des liens profonds pour le push, l’email, etc.
  • Gestion des tokens push et des charges utiles
• Comment vous collectez les adresses email, les numéros de téléphone, les tokens push, etc.
• Les domaines email et la propriété DNS
• Les expéditeurs SMS et les mécanismes d’opt-in

• Les types de messages que vous envoyez (transactionnels, marketing, etc.) et les modèles pour chacun
• Comment vous segmentez et ciblez les utilisateurs
• Les métriques d’analytique ou de conversion que vous suivez

​

2. Mappez votre terminologie vers OneSignal

​

3. Ajoutez le SDK OneSignal (développeurs)

• login — Définissez l’ID externe pour identifier un utilisateur sur plusieurs appareils et canaux.
• addEmail — Créez un abonnement email à partir d’une adresse collectée dans votre application ou site.
• addSms — Créez un abonnement SMS à partir d’un numéro de téléphone collecté dans votre application ou site.

​

4. Supprimez votre implémentation héritée

• Migration propre — Supprimez entièrement votre ancien SDK et remplacez-le par OneSignal dans une seule version de l’application. C’est l’approche recommandée.
• Migration progressive — Conservez les deux SDK temporairement, en envoyant depuis chaque fournisseur à différents groupes d’utilisateurs selon la version de l’application. Utilisez cette option uniquement si vous ne pouvez pas supprimer l’ancien SDK en une seule version.

​

Conflits et format des tokens push

• Obtenez l’identifiant du token push de l’appareil en utilisant notre SDK mobile Frontend
• Obtenez l’identifiant de l’appareil en utilisant notre API Voir l’utilisateur

​

Conflit avec le SDK Firebase Messaging

• Supprimez les anciens récepteurs Firebase de AndroidManifest.xml.
• N’appelez pas FirebaseMessaging.getToken() ou FirebaseMessaging.deleteToken().
• Assurez-vous que OneSignal est le seul SDK gérant le cycle de vie du token push.

​

Gestion des charges utiles push

​

Migration progressive (applications mobiles uniquement)

• Laissez OneSignal gérer les tokens push exclusivement. Partagez le token avec votre ancien système si nécessaire (voir Conflits de tokens push ci-dessus).
• Mettez à jour les filtres de charge utile pour que votre SDK hérité ignore les pushs OneSignal (voir Gestion des charges utiles push ci-dessus).
• Envoyez depuis votre ancien fournisseur aux utilisateurs sur l’ancienne version de l’application et depuis OneSignal aux utilisateurs sur la nouvelle version.
• Fixez une date limite claire et un plan d’élimination progressive.

​

5. Migration du push web

1. Supprimez le code du SDK hérité et les fichiers Service Worker de votre site web.
2. Ajoutez le code suivant pour désenregistrer l’ancien Service Worker. Remplacez sw.js par le nom du fichier Service Worker de votre ancien fournisseur.

if ('serviceWorker' in navigator) {
  navigator.serviceWorker.getRegistrations().then(function(registrations) {
    for (let registration of registrations) {
      if (registration.active.scriptURL.includes("sw.js")) {
        registration.unregister();
      }
    }
  });
}

​

Migration entre applications OneSignal

• Les abonnements push web ne peuvent pas être transférés directement entre les applications. Chaque abonnement est lié à la fois au domaine (origine) de votre site et à l’ID d’application OneSignal.
• Pour migrer, mettez à jour le code d’initialisation OneSignal de votre site pour utiliser l’appId de l’App B :

OneSignal.init({
  appId: "YOUR_APP_B_ID",
});

• Lorsqu’un utilisateur revisite votre site, l’autorisation push existante du navigateur permettra à OneSignal de l’enregistrer silencieusement dans l’App B.
• Aucune nouvelle invite d’autorisation n’apparaîtra, mais les utilisateurs doivent visiter votre site au moins une fois pour que l’abonnement soit créé dans l’App B.
• Les abonnés continueront à apparaître dans l’App A jusqu’à ce qu’ils deviennent inactifs.

​

6. Configuration des emails et SMS

​

7. Importer les utilisateurs existants (optionnel)

​

Considérations par plateforme

• Les adresses email doivent provenir d’utilisateurs actifs et valides. N’importez pas les adresses email qui n’ont jamais cliqué ou ouvert d’emails auparavant.
• Les numéros de téléphone doivent être dans un format spécifique et les utilisateurs doivent avoir consenti à recevoir des SMS.
• Les abonnements iOS peuvent commencer à recevoir des notifications push immédiatement après l’importation. Les fonctionnalités comme le suivi des clics de notification et les livraisons confirmées nécessitent que notre SDK soit actif sur l’appareil.
• Les abonnements Android/Huawei/Amazon doivent avoir notre SDK actif sur l’appareil pour recevoir des notifications, soit par une mise à jour automatique, soit par une mise à jour manuelle.
• Les abonnements web ne peuvent pas être importés. Si vous suivez ce qui est indiqué dans Migration du push web, l’abonnement push web sera créé et le token push récupéré via notre SDK lorsque l’utilisateur reviendra sur le site.

​

Étapes d’importation

1. Consultez les documents Utilisateurs et Abonnements.
2. Exportez les données des utilisateurs de test depuis l’ancien système.
3. Formatez les données pour l’API Créer un utilisateur de OneSignal.
4. Importez les utilisateurs de test en premier. Une fois vérifiés, répétez le processus pour les utilisateurs restants avant la mise en production.

​

8. Testez la migration

1. Activez la journalisation de débogage dans le SDK OneSignal.
2. Testez sur de vrais appareils pour toutes les plateformes (Android, iOS, Web, etc.).
3. Vérifiez la gestion des notifications en premier plan et en arrière-plan.

• Envoyez des notifications de test depuis OneSignal aux utilisateurs importés avant d’ajouter le SDK OneSignal.
  • Vous devriez recevoir le push sur iOS mais vous n’obtiendrez pas de livraison confirmée ni d’analytique de clics.
  • Vous pouvez recevoir le push sur Android si vous avez un autre SDK push et n’avez pas encore implémenté les exigences de Gestion des charges utiles. La notification manque probablement de données et ne fonctionne pas comme prévu lorsqu’on clique dessus.
• Envoyez des notifications de test depuis OneSignal aux utilisateurs importés après avoir ajouté le SDK OneSignal.
  • Vous devriez recevoir le push sur Android et iOS avec une livraison confirmée et une analytique de clics.
• Testez le comportement des notifications avec l’application dans différents états.
• Vérifiez que les liens profonds et les actions personnalisées fonctionnent correctement.

• Envoyez depuis votre fournisseur actuel et OneSignal.
• Vérifiez l’absence de notifications en double.
• Vérifiez que les notifications de chaque fournisseur s’affichent correctement.
• Testez les scénarios de connexion/déconnexion des utilisateurs.

​

Liste de vérification pré-lancement

• Élaborez un plan de messagerie pour inciter aux mises à jour de l’application
• Envisagez d’utiliser les notifications push et les messages in-app de votre ancien système pour rappeler gentiment aux utilisateurs de mettre à jour.

• Vérifiez que l’analytique des notifications push et des messages in-app fonctionne comme prévu.
  • Les événements de clic et la livraison confirmée sont suivis sur Android et iOS.
• Vérifiez que les événements de clic et les événements reçus en premier plan sont gérés correctement pour les messages envoyés depuis les deux fournisseurs.
• Si vous importez des utilisateurs, exportez les utilisateurs Android et iOS qui ont été actifs dans votre application au cours des 270 derniers jours pour éviter d’importer des tokens expirés. Consultez la FAQ sur les tokens FCM expirés pour plus de détails.

​

Lancez votre application/site

• La plupart des utilisateurs verront leur application se mettre à jour automatiquement vers la dernière version.
• Lorsque les utilisateurs ouvrent votre application mise à jour, ils ne seront pas invités à s’abonner aux notifications push si les autorisations ont déjà été accordées — soit via les invites d’autorisation requises, soit via les paramètres de notification de l’application.

• Les utilisateurs seront créés automatiquement dans OneSignal lorsqu’ils ouvriront la version mise à jour de l’application. Ils ne seront pas invités à s’abonner au push s’ils étaient précédemment abonnés.
• Vous devrez attendre qu’ils ouvrent l’application mise à jour avant de pouvoir leur envoyer des messages.
• Continuez à envoyer des notifications et des messages in-app depuis le fournisseur push précédent pendant quelques jours jusqu’à ce que suffisamment d’utilisateurs apparaissent dans OneSignal. Envoyez des alertes supplémentaires leur demandant de mettre à jour l’application vers la dernière version.

​

Surveillez les résultats

• Surveillez les taux d’erreur et les plantages après le déploiement.
• Surveillez les invalidations de tokens inattendues.
• Vérifiez l’analytique d’intégration du SDK.

• Notez la date de lancement de l’application et confirmez avec vos développeurs quelle voie de migration a été suivie (propre ou progressive) et si des utilisateurs ont été importés.
• Dans votre plateforme précédente, créez un segment d’utilisateurs qui n’ont pas encore mis à jour vers la nouvelle version de l’application. Continuez à envoyer depuis votre ancien fournisseur à ce groupe, en les incitant à mettre à jour.
• Arrêtez d’envoyer depuis le fournisseur précédent une fois que le nombre d’abonnés se stabilise dans OneSignal.
• Si vous suivez une migration progressive, supprimez le SDK de l’ancien fournisseur lors de votre prochaine version de l’application après la date limite.

​

FAQ

​

Puis-je utiliser OneSignal en parallèle avec mon fournisseur push actuel ?

​

Puis-je importer des abonnés push web ?

​

Dois-je redemander l’autorisation push aux utilisateurs après la migration ?

​

Le réchauffement des emails est-il requis ?

​

Puis-je obtenir une adresse IP dédiée ?

​

Combien de temps dois-je continuer à envoyer depuis mon ancien fournisseur ?