Vous avez constitué votre liste d'abonnés push, un opt-in difficilement gagné à la fois, et chaque opt-in a coûté de l'argent réel en acquisition. Ainsi, lorsqu'il est temps de changer de fournisseur de notifications push, la peur est spécifique : annuler l'ancien contrat et la liste disparaît avec lui. Votre fournisseur actuel peut même vous dire exactement cela.
Ce n'est pas vrai, et ce guide vous montre pourquoi au niveau du navigateur. Un abonnement web push est lié à votre domaine, pas à votre fournisseur. Une fois que vous comprenez les mécanismes, chaque changement se résout en l'un des deux scénarios clairs, une courte liste de questions écrites pour votre fournisseur actuel et une checklist d'une semaine que votre équipe peut exécuter sans problème.
Une note honnête dès le départ. L'équipe de vente de chaque fournisseur, y compris la nôtre, vous dira que la migration est facile. La plupart s'arrêtent là. Cet article vous montre le mécanisme à la place, afin que votre développeur puisse vérifier chaque affirmation, y compris celles que nous faisons à la fin.
Ce qu'est réellement un abonnement web push
Lorsqu'un visiteur clique sur « Autoriser » sur votre site, le navigateur crée un abonnement web push basé sur trois éléments :
- Votre origine. Le domaine exact sur lequel l'autorisation a été accordée (
https://votresite.com). L'autorisation réside dans le navigateur, attachée à l'origine. Elle ne mentionne aucun fournisseur. - Un service worker. Un petit fichier JavaScript hébergé sur votre domaine qui reçoit et affiche les notifications. Quel que soit le service worker enregistré, il contrôle la livraison.
- Une clé de serveur d'application. La moitié publique d'une paire de clés VAPID. Le service push du navigateur n'accepte que les envois signés avec la clé privée correspondante. Quiconque détient cette clé privée peut envoyer des messages à l'abonnement. (L'aperçu des notifications push de web.dev couvre le protocole complet.)
L'enregistrement de l'abonnement lui-même se compose de trois chaînes : une URL de point de terminaison plus deux courtes clés, p256dh et auth. C'est l'ensemble de l'actif. Votre liste entière est un tableau de ces enregistrements.
Une règle décide de tout ce qui suit : les navigateurs n'acceptent les envois que de la part du détenteur de la clé privée VAPID correspondante. Ce qui signifie que chaque changement de fournisseur se résout en exactement deux scénarios, en fonction de l'emplacement de ces clés.
Scénario A : vos clés VAPID voyagent, donc vous importez les abonnés push dès le premier jour
Le scénario A s'applique lorsque les clés vous appartiennent : vous avez configuré vos propres clés VAPID ou votre propre projet Firebase lors de la configuration, ou votre fournisseur sortant accepte de vous céder la paire de clés. Certaines équipes mettent cela en place délibérément dès le premier jour ; l'approche est couverte dans notre guide sur l'implémentation du web push sans dépendance vis-à-vis d'un fournisseur.
Avec la clé privée en main, votre nouveau fournisseur peut importer directement les abonnés push : chaque endpoint, enregistrement p256dh et auth est transféré, et vous pouvez envoyer des messages à toute votre liste existante dès le premier jour. Cela inclut les abonnés dormants qui ne vous ont pas rendu visite depuis des mois. Personne ne se réabonne. Personne ne s'en rend compte.
Une nuance qui mérite d'être dite clairement. Même dans le scénario A, la migration durable s'achève toujours par des visites de retour, car chaque abonné doit finalement atterrir sur le nouveau service worker. Les clés importées vous donnent une portée dès le premier jour pendant que ce transfert se déroule silencieusement en arrière-plan.
Scénario B : les clés restent en arrière, et la réinscription silencieuse prend le relais
Le scénario B est le défaut courant : le fournisseur a généré les clés VAPID et les conserve. Sans la clé privée, les enregistrements exportés sont cryptographiquement inutiles. La portée dès le premier jour est nulle, et l'avertissement de votre ancien fournisseur semble vrai pendant encore un paragraphe.
Voici ce qui se passe réellement. La prochaine fois que chaque abonné visite votre site, le service worker du nouveau fournisseur prend le relais : il désenregistre l'ancien enregistrement, se désabonne de l'ancien abonnement et réabonne le visiteur sous les nouvelles clés. Silencieusement, en une seule visite, sans deuxième invite de permission.
Pourquoi le nouveau service worker n'a pas besoin d'une deuxième invite
La permission de notification est accordée à votre origine, pas à un fournisseur. Le navigateur fait déjà confiance à votre domaine. Remplacer le service worker et les clés sous une permission déjà accordée est invisible pour le visiteur, car le navigateur le traite comme si votre site réorganisait sa propre plomberie. C'est exactement ce que c'est.
Deux pièges que votre développeur devrait connaître
Une origine, un abonnement. Un navigateur ne peut pas conserver deux abonnements push pour la même origine. S'abonner avec une clé différente échoue jusqu'à ce que l'ancien abonnement soit libéré. Ainsi, « exécuter les deux fournisseurs en parallèle » fonctionne au niveau de la liste, jamais à l'intérieur d'un seul navigateur : chaque abonné est sur l'ancien ou le nouveau fournisseur, et chaque visite de retour en déplace un de plus.
Les opt-ins de sous-domaine du fournisseur ne bougent jamais. Les abonnements collectés sur yoursite.vendor.com appartiennent à l'origine du fournisseur, et aucun fournisseur ne peut les migrer. Cette base est reconstruite à partir de zéro. C'est le plus grand piège dans toute migration de notification push, et l'argument le plus fort pour ancrer les abonnements à un domaine que vous contrôlez cette fois-ci. Si vous exploitez plusieurs marques ou domaines régionaux, la même logique d'origine façonne toute votre architecture ; nous en parlons dans web push sur plusieurs domaines.
Voici les deux scénarios côte à côte :
| Scénario A : les clés voyagent | Scénario B : les clés restent en arrière | |
|---|---|---|
| Quand cela s'applique | Clés VAPID propres / projet Firebase propre, ou le fournisseur libère la paire | Le fournisseur a généré et conserve les clés (le défaut courant) |
| Portée le Jour 1 | Votre liste entière, y compris les abonnés dormants | Zéro, jusqu'à ce que les visiteurs reviennent |
| À chaque visite de retour | L'abonné passe silencieusement aux nouvelles clés | Réinscription silencieuse sous les nouvelles clés, sans deuxième invite |
| Qui vous récupérez | Tout le monde | Tous ceux qui reviennent |
| Qui vous perdez | Personne | Abonnés qui ne reviennent jamais (qui n’étaient de toute façon plus une source de revenus atteignable) |
Pourquoi les audiences à visites quotidiennes terminent le plus rapidement une migration de notifications push
Dans le scénario B, l’horloge de reprise est la fréquence de retour de votre audience. Rien d’autre. Un abonné e-commerce peut visiter mensuellement, donc la reprise s’étend sur plusieurs mois. Un parieur consulte les cotes, les lignes et les résultats quotidiennement. Un lecteur d’actualités revient pour chaque cycle de gros titres.
Ce rythme de retour est la raison pour laquelle les sites de paris et d’actualités sont les secteurs les mieux positionnés sur Internet pour changer de fournisseur de notifications push : la même fréquence de visite qui fait des notifications push pour les sites de paris un moteur de rétention compresse également une migration qui prend un trimestre à d’autres sites en une semaine ou deux. Les sites de paris et de jeux sur PushEngage ont envoyé plus de 3,5 milliards de notifications, donc ces mécanismes de reprise sont une réalité de production quotidienne pour nous, pas de la théorie.
| Schéma de retour de l’audience | Reprise typique de la base active |
|---|---|
| Visiteurs quotidiens (cotes en direct, actualités de dernière minute, promotions quotidiennes) | Quelques jours à environ une semaine |
| Plusieurs visites par semaine (parieurs du week-end, habitués) | 1–2 semaines |
| Hebdomadaire ou moins (visiteurs saisonniers, utilisateurs inactifs) | Semaines, accéléré par les envois de l’ancien fournisseur et les grands événements |
| Inactif (aucune visite depuis des mois) | Récupérable uniquement dans le scénario A |
Ce sont des schémas typiques pour les audiences à visites quotidiennes, pas des garanties ; votre courbe dépend de votre rythme de trafic, et vous la verrez en direct dans le tableau de bord. Vous pouvez également infléchir la courbe : planifiez la transition la semaine précédant un week-end de grande compétition et le trafic événementiel fera la reprise pour vous. Les sites de paris sportifs qui planifient une séquence de push pour le jour du match savent déjà quels week-ends il s’agit.
Le push d’application est plus simple : vos jetons vous ont toujours appartenu
Si vous envoyez également des push d’application, respirez. Cette partie est structurellement facile, car aucun fournisseur ne peut la retenir en otage.
Les certificats et clés APNs sont émis pour votre compte Apple Developer. Votre projet FCM réside dans votre console Google. Un fournisseur de push est une couche au-dessus des identifiants que vous possédez, donc changer signifie pointer une nouvelle couche vers les mêmes identifiants. Les jetons d’appareil s’exportent et s’importent proprement, sans réinstallation ni seconde invite de permission.
Deux notes pratiques. Premièrement, filtrez les exportations de jetons pour les appareils actifs depuis environ 270 jours avant d’importer, car FCM traite les jetons inactifs au-delà d’environ 270 jours comme obsolètes. Un vidage de jetons sur cinq ans gonfle votre nombre d’abonnés, et sur une tarification qui ne compte que les abonnés actifs, personne n’en bénéficie. Deuxièmement, une couverture SDK complète arrive à la vitesse à laquelle les utilisateurs mettent à jour votre application, généralement une semaine ou deux pour une application à usage quotidien avec mises à jour automatiques.
Si votre application iOS envoie actuellement via Firebase, le flux étape par étape est un sujet en soi ; consultez notre guide pour migrer depuis Firebase Cloud Messaging sur iOS plutôt que de l’improviser à partir de cet article.
Avant de changer de fournisseur de notifications push, posez ces six questions par écrit
Les exportations de fournisseurs et les politiques clés varient et changent. Au lieu de faire confiance à un tableau de verdicts de fournisseurs (y compris celui que nous pourrions publier), obtenez les réponses de votre propre fournisseur par écrit. L'e-mail fonctionne ; un ticket de support fonctionne mieux. Si vous évaluez des destinations en même temps, les mêmes questions constituent un filtre utile lors de la comparaison des alternatives à OneSignal.
- Pouvez-vous exporter mes enregistrements complets d'abonnements aux notifications push web — URL de point de terminaison plus les clés
p256dhetauthpour chaque abonné — ou seulement des identifiants internes ? Les identifiants internes sont dénués de sens en dehors du système du fournisseur. - Allez-vous publier la paire de clés VAPID sous laquelle mes abonnements ont été créés ? Cette seule réponse décide du scénario A par rapport au scénario B.
- Sur quel projet FCM ou Firebase mon push web s'exécute-t-il, le mien ou le vôtre ? Si c'est le vôtre, les clés peuvent déjà être dans votre propre console.
- Puis-je exporter séparément les segments, les balises, les attributs des abonnés et les listes de suppression ? Ils ne sont pas automatiquement inclus avec les enregistrements d'abonnement.
- Puis-je exporter les jetons de mes appareils de notification push d'application, et dans quel format ?
- Que devient mon contenu si je rétrograde ou annule — y a-t-il une suppression automatique ou une période de rétention ? Certains fournisseurs suppriment les données des abonnés inactifs dans les niveaux inférieurs. Exportez d'abord, toujours.
La liste de contrôle de la semaine de migration
Imprimez cette section. Huit étapes, dans l'ordre.
- Exportez tout avant d'annuler ou de rétrograder quoi que ce soit. Enregistrements d'abonnement, jetons d'application, segments, balises, attributs, listes de suppression. L'accès à l'exportation disparaît avec votre contrat.
- Obtenez la réponse concernant les clés VAPID par écrit. Elle décide de votre scénario et si vous pouvez importer des abonnés push dès le premier jour.
- Déplacez les listes de suppression en premier, pas en dernier. Pour les opérateurs de paris et de jeux, c'est non négociable : les joueurs auto-exclus doivent être supprimés sur la nouvelle plateforme avant la reprise d'une seule campagne, pas réconciliés après.
- Filtrez les jetons d'application sur environ 270 jours d'activité avant l'importation.
- Installez le nouveau SDK et le nouveau service worker, et fusionnez avec tout service worker existant (une coque PWA, le service worker de l'ancien fournisseur) plutôt que de le remplacer.
- Ne supprimez pas le fichier de service worker de l'ancien fournisseur le premier jour. Les visiteurs de retour ont toujours des enregistrements qui y pointent ; la prise de contrôle les désenregistre gracieusement. Supprimez le fichier trop tôt et vous générerez des erreurs de console au lieu de migrations. Retirez-le lors du démontage final.
- Laissez l'ancien fournisseur envoyer pendant la fenêtre parallèle. Contre-intuitif mais essentiel : chaque notification envoyée par l'ancien fournisseur entraîne une nouvelle visite, et chaque nouvelle visite complète la migration d'un abonné supplémentaire. Votre fournisseur sortant devient votre meilleur outil de migration.
- Mesurez la prise de contrôle quotidiennement et basculez au plateau. Suivez la nouvelle base active par rapport à l'ancienne base active. Lorsque la courbe s'aplatit, terminez le démontage, annulez l'ancien contrat et archivez les exportations.
Le coût du changement lorsque PushEngage s'en charge pour vous
Chez PushEngage, la migration est un service haut de gamme inclus gratuitement dans les plans payants. Vous bénéficiez d'un ingénieur de migration, pas d'un article du centre d'aide : il gère le mappage d'exportation, la gestion des clés, la fusion du service worker et le plan de reprise. Cela compte car les modes d'échec sont discrets — une importation brute avec des formats de charge utile incompatibles peut délivrer des notifications techniquement réussies mais vides, ce qui est exactement la catégorie d'échec silencieux qu'un spécialiste détecte avant vos abonnés.
L'appel de cadrage dure environ quinze minutes : nombre d'abonnés par canal, fournisseur actuel et la question des clés ci-dessus. À la fin, vous savez si vous êtes dans le scénario A ou B, et vous avez un plan daté.
Si vous êtes prêt à changer de fournisseur de notifications push, commencez par les six questions écrites dans cet article et voyez comment votre fournisseur actuel répond. Ensuite, regardez ce qu'une plateforme de notifications push web axée sur la segmentation et l'attribution des revenus ferait avec la liste que vous possédez déjà, et comparez les tarifs de PushEngage à votre facture actuelle. Chaque plan payant est assorti d'une garantie de remboursement de 14 jours, de sorte que la migration des notifications push elle-même est la partie la moins risquée de la décision.
