Votre portefeuille ressemble probablement à ceci : un site de paris sportifs phare sur le .com, une marque régionale sous licence sur le .ca, un casino en marque blanche que vous avez lancé au printemps dernier, et un changement de marque prévu pour le T4. Une équipe de rétention possède tout cela. Et si vous utilisez le web push sur plusieurs domaines de la manière par défaut, vous possédez également quatre listes d'abonnés déconnectées, chacune se développant de son côté, sans qu'aucune ne communique avec les autres.
Cette fragmentation n'est pas une erreur de configuration de votre part. C'est ainsi que fonctionne l'architecture push du web. Le navigateur associe chaque abonnement à un seul domaine, et aucun paramètre de tableau de bord ne change cela.
Il existe cependant un moyen pris en charge pour contourner ce problème. Cet article couvre les mécanismes : pourquoi un abonnement web push est lié à une origine, ce qui survit réellement à un changement de domaine (plus que vous ne le pensez), ce qui casse (moins que vous ne le craignez, mais la partie qui s'accumule), et l'architecture d'origine stable qui crée une seule liste d'abonnés pour toutes les marques que vous exploitez aujourd'hui et toutes les marques que vous lancerez demain.
Pourquoi un abonnement web push est lié à un seul domaine
Lorsqu'un visiteur clique sur Autoriser, le navigateur ne l'abonne pas à votre marque. Il l'abonne à une origine : le protocole et le nom d'hôte exacts dans la barre d'adresse. L'API Push crée l'abonnement par rapport à un service worker enregistré sur cette origine, en utilisant la clé de serveur d'application de votre plateforme. L'enregistrement que le navigateur renvoie comporte trois parties : une URL de point de terminaison sur le service push du fournisseur de navigateur, plus deux valeurs de chiffrement (p256dh et auth) qui verrouillent les charges utiles à ce seul navigateur.
La permission de notification suit la même règle. Elle est accordée par origine, pas par entreprise. sportsbook.com et sportsbook.ca sont des inconnus au niveau du protocole, même s'ils partagent un logo, un portefeuille et une base de données de joueurs. Chacun demande séparément, s'abonne séparément et crée une liste séparée.
Origine, service worker de notification push et clés VAPID : le verrou à trois parties
Trois éléments maintiennent un abonnement web push en place. L'origine qui l'a créé. Le service worker de notification push qui reçoit les messages pour celui-ci. Et les clés VAPID que votre plateforme d'envoi détient. L'abonnement est créé sous la clé publique, et le service push accepte un envoi uniquement lorsqu'il est authentifié avec la clé privée correspondante. Votre plateforme prouve qu'elle détient la paire de clés à chaque envoi ; l'enregistrement de l'abonnement lui-même ne contient que la moitié publique.
Le navigateur applique également un abonnement par origine. Appeler à nouveau subscribe avec une clé de serveur d'application différente échoue jusqu'à ce que l'abonnement existant soit supprimé. Cette contrainte est importante plus tard, lorsque nous aborderons la consolidation : sur la même origine, un nouveau service worker peut reprendre silencieusement un abonné existant. Entre les origines, cela n'est jamais possible.
Ce qu'une migration de domaine casse dans le web push (et ce qu'elle ne casse pas)
Voici la partie que la plupart des équipes négligent lors d'une migration de domaine : elles supposent que l'ancienne liste disparaît. Ce n'est pas le cas. Les abonnés qui ont donné leur accord sur l'ancien domaine continuent de recevoir vos notifications.
La livraison ne touche jamais votre site web. Lorsque vous envoyez, votre plateforme effectue une requête authentifiée avec vos clés VAPID auprès du service de notification push qui détient chaque abonnement (celui de Google pour Chrome, celui de Mozilla pour Firefox, celui d'Apple pour Safari), et ce service livre la charge utile cryptée au service worker déjà installé dans le navigateur de l'abonné. L'ancien domaine peut être redirigé, mis en attente ou supprimé entièrement. La notification arrive toujours.
La destination du clic vous appartient également. Les URL de clic sont définies par campagne, de sorte qu'un abonné qui a donné son accord sur un domaine que vous avez retiré il y a deux ans peut cliquer sur la notification d'aujourd'hui et atterrir sur le site en direct d'aujourd'hui.
| Après un changement de domaine | Fonctionne toujours ? |
|---|---|
| Livraison aux abonnés existants | Oui — les notifications passent par les services de notification push des fournisseurs de navigateurs, pas par votre site |
| Destination du clic | Oui — l'URL de clic est définie par campagne ; pointez-la vers le domaine actuel |
| Les abonnés de l'ancien origine rejoignent automatiquement la liste du nouveau domaine | Non — l'autorisation est par origine, donc rejoindre la nouvelle liste nécessite un nouvel accord |
| Nouvelles inscriptions sur l'ancienne origine | Non — et c'est la perte qui s'accumule |
Ainsi, une migration de domaine ne vous coûte pas les abonnés que vous avez. Elle vous coûte la machine qui les produisait. Le jour où le trafic change, la capture d'inscriptions sur le nouveau domaine redémarre à zéro tandis que l'ancienne liste se dégrade lentement. Appliquez cela à un portefeuille de marques et chaque propriété paie cette taxe de réinitialisation indépendamment.
Le vrai coût : chaque nouveau domaine recommence sa liste à zéro
Une capture fragmentée serait une nuisance dans un canal à faible taux d'attrition. Les paris ne sont pas un canal à faible taux d'attrition. Sur les sites de paris et de jeux sur PushEngage, en une fenêtre de 90 jours, les désabonnements ont effacé environ 91 % des nouvelles acquisitions d'abonnés sur le segment. Une liste dans ce secteur est une baignoire avec le siphon ouvert ; la seule chose qui maintient le niveau est le robinet qui coule en continu.
La fragmentation ferme le robinet, une propriété à la fois. La liste de chaque marque ne grandit que tant que ce domaine spécifique génère des opt-ins. Une migration réinitialise son robinet à zéro. Un nouveau marque blanche commence à zéro. Pendant ce temps, les navigateurs continuent de vider : la révocation automatique des autorisations par Chrome, annoncée en octobre 2025, supprime discrètement les autorisations de notification des sites très peu engagés et avec un volume élevé de notifications. Une liste qui ne capture pas n'est pas plate. Elle rétrécit.
Le cadre du coût d'acquisition client (CAC) rend les enjeux clairs. Vous avez payé pour acquérir chacun de ces visiteurs, et l'opt-in est le seul actif de reciblage durable que la visite laisse derrière elle. Le cas des notifications push dans ce secteur repose sur la capitalisation de cet actif. La fragmentation en annule une partie à chaque changement de domaine.
L'architecture à origine stable : un domaine d'abonnement pour chaque marque
La solution consiste à cesser complètement de créer des abonnements sur les domaines de marque. Ancrez chaque abonnement à une seule origine HTTPS stable que votre groupe contrôle, une qui survivra à tout domaine de marque individuel, et laissez chaque propriété l'alimenter.
PushEngage propose cela sous forme de flux de sous-domaine personnalisé, conçu exactement pour ce cas : plusieurs domaines nécessitant une administration unifiée des abonnés sous un domaine contrôlé. La configuration :
- Choisissez une origine stable et neutre vis-à-vis de la marque que vous possédez, telle que
notify.yourbrandgroup.com. Choisissez un nom que vous souhaitez que les abonnés voient, car les navigateurs affichent l'origine d'abonnement sur les notifications. - Téléchargez le fichier service worker de PushEngage à la racine de ce domaine et activez la fonctionnalité sous Paramètres du site » Paramètres avancés. L'origine stable obtient son propre extrait d'installation avec
isSubscriptionOnSubDomain: true. - Ajoutez l'extrait PushEngage à chaque domaine de marque. Lorsqu'un visiteur opte sur l'un d'eux, le flux est acheminé via l'origine stable, où l'abonnement réel est créé.
Deux exigences sont non négociables dans ce mode. Premièrement, l'opt-in est uniquement en double étape : l'invite de permission du navigateur doit s'afficher sur l'origine qui possède l'abonnement, donc une invite native en une seule étape sur le domaine de marque n'est pas possible. Deuxièmement, l'installation rapide reste activée.
Soyez honnête quant au compromis. Le double étape ajoute un clic avant l'invite de permission, et il convertit moins au moment de la capture. Cela vaut la peine d'être lu en parallèle des leviers plus larges pour augmenter votre taux d'opt-in. Mais un abonné en une seule étape capturé sur un domaine que vous migrez plus tard est un actif déprécié. Un abonné en double étape sur l'origine stable survit à chaque rebrand, chaque lancement régional, chaque migration que vous effectuerez. Sur n'importe quel horizon incluant un changement de domaine, la liste consolidée gagne en portée totale.
Notifications push pour plusieurs sites Web, une liste d'abonnés
Une fois l'origine stable en place, les notifications push pour plusieurs sites Web cessent de signifier plusieurs listes. Chaque domaine de marque alimente la même base d'abonnés. Lancer un nouveau domaine régional ou une marque blanche le trimestre prochain signifie ajouter l'extrait ; ses opt-ins atterrissent dans la liste consolidée dès le premier jour. Retirer un domaine ne signifie rien pour la liste : la capture continue sur les propriétés survivantes, la diffusion continue via les services push, et les URL de clic pointent là où vous êtes en direct.
Consolider les listes d'abonnés que vous avez déjà fragmentées
La plupart des opérateurs arrivent à cette architecture avec une histoire : des listes actives dispersées sur d'anciens domaines, certaines dormantes, d'autres chez un autre fournisseur. La consolidation s'exécute sur trois pistes en parallèle.
| Piste | Ce que vous faites | Ce que cela vous apporte |
|---|---|---|
| 1. Garder les anciennes listes fonctionnelles | Continuez à envoyer à chaque liste d'ancienne origine ; pointez les URL de clic vers le domaine actif actuel | La portée payante continue de produire des sessions au lieu d'être radiée |
| 2. Capturer de nouveaux sur l'origine stable | Passez l'opt-in de chaque propriété active au flux de l'origine stable | La fragmentation s'arrête le jour de sa mise en œuvre ; toute nouvelle acquisition atterrit dans une seule liste |
| 3. Laissez les anciennes listes se canaliser d'elles-mêmes | Chaque envoi vers une ancienne liste entraîne une revisite d'un domaine actuel, où l'invite d'origine stable attend | Les abonnés actifs se consolident eux-mêmes, sans ré-autorisation forcée |
Le suivi 3 est le cheval de bataille silencieux. L'autorisation du navigateur est par origine, donc les abonnés d'ancienne origine ont techniquement besoin d'un nouvel opt-in pour rejoindre la liste consolidée, mais vous n'avez jamais à l'exiger. Compte tenu de la rapidité avec laquelle les audiences de paris évoluent, la liste consolidée devient la majorité de votre portée active en quelques mois, simplement parce que les joueurs actifs continuent de visiter.
Si certains fragments résident chez un autre fournisseur de push sur un domaine que vous possédez, ils peuvent également vous accompagner. Le chemin standard de PushEngage est un réabonnement silencieux : lors de la prochaine visite d'un abonné, le service worker de notification push du SDK prend le relais et le réabonne sans deuxième invite de permission, car l'autorisation au niveau de l'origine persiste. Pour OneSignal, PushEngage peut récupérer la liste directement via l'API de OneSignal. La migration est accompagnée et gratuite sur les plans payants.
Campagnes par marque au sein d'une liste consolidée
Une liste ne signifie pas un message. Cela signifie un actif avec un ciblage meilleur que ce que quatre fragments pourraient jamais gérer.
Capturez la marque d'origine en tant qu'attribut d'abonné lors de l'opt-in, et des cohortes par marque existent dès le premier jour. À partir de là, la segmentation fait ce que des listes séparées n'ont jamais pu faire : marque croisée avec la géographie, comportement de dépôt, récence de session ou préférence de ligue. C'est le modèle que le numéro 1 expose dans le guide des notifications push pour les sites de paris. La campagne de cotes boostées du produit phare s'adresse aux parieurs du produit phare ; le rappel de cashback du marque blanche du casino s'adresse à ses joueurs ; une alerte de fixture pour tout le portefeuille s'adresse à tous ceux qui suivent la ligue, quelle que soit la marque sous laquelle ils se sont inscrits.
L'avantage n'est pas cosmétique. Sur les sites de paris utilisant PushEngage, l'expéditeur médian de site de paris voit un CTR d'environ 2,1 % sur les notifications vues ; le décile supérieur atteint 6,9 % — environ le triple. Cet écart est un écart de ciblage, pas un écart de canal, et vous ne pouvez pas construire de cohortes comportementales sur quatre fragments déconnectés. La consolidation est ce qui rend la segmentation en tant que pratique de délivrabilité réalisable à l'échelle du portefeuille. Cela est d'autant plus important maintenant que Chrome note chaque origine d'envoi quotidiennement et limite les expéditeurs perturbateurs (en vigueur depuis janvier 2026). Une origine stable concentre votre réputation d'expéditeur ; les envois segmentés et pertinents sont ce qui la maintient en bonne santé.
Une seule liste rend également le jeu responsable plus simple sur le plan opérationnel, et c'est une fonctionnalité, pas une note de bas de page. Un joueur auto-exclu supprimé sur un segment de portefeuille est supprimé partout à la fois, et non marque par marque où un fragment peut passer inaperçu. Les heures de silence et les plafonds de fréquence s'appliquent au niveau de l'abonné pour les campagnes de chaque marque. Et les campagnes elles-mêmes doivent tenir la ligne : pas de reconquête axée sur la poursuite des pertes, pas de pression de compte à rebours sur les invites de dépôt.
Exécutez des push web sur plusieurs domaines sans diviser votre liste
L'ensemble de la configuration est plus petit qu'il n'y paraît : un enregistrement DNS pour l'origine stable, le fichier service worker à sa racine, le commutateur dans Paramètres avancés, l'extrait isSubscriptionOnSubDomain, et l'extrait standard sur chaque domaine de marque avec l'option d'adhésion en deux étapes configurée et l'installation rapide activée. Les équipes le déploient généralement le jour même, sans migration de plateforme. C'est tout ce qu'il faut pour gérer les notifications push pour plusieurs sites Web à partir d'une seule origine.
Ce que vous récupérez est ce que la fragmentation taxe silencieusement : une liste d'abonnés qui se compose. Chaque marque l'alimente, chaque changement de domaine rebondit dessus, et chaque campagne peut cibler l'ensemble du portefeuille ou une seule marque à la fois. Si vous voulez voir la mécanique par rapport à votre propre carte de domaine, commencez par la présentation de la fonctionnalité de notifications push Web et les plans tarifaires. Les plans payants bénéficient d'une garantie de remboursement de 14 jours, de sorte que l'architecture peut faire ses preuves sur votre trafic avant que la décision ne soit définitive.
