Uw portfolio ziet er waarschijnlijk ongeveer zo uit: een vlaggenschip sportsbook op de .com, een gelicentieerd regionaal merk op de .ca, een casino white-label dat u vorig voorjaar lanceerde, en een rebrand gepland voor Q4. Eén retentieteam is eigenaar van dit alles. En als u web push op meerdere domeinen op de standaardmanier gebruikt, bent u ook eigenaar van vier losgekoppelde abonneelijsten, die elk op zichzelf groeien, zonder dat ze met elkaar communiceren.
Die fragmentatie is geen configuratiefout die u hebt gemaakt. Het is hoe de push-architectuur van het web werkt. De browser koppelt elk abonnement aan één enkel domein, en geen enkele dashboardinstelling verandert dat.
Er is echter een ondersteunde manier om dit te omzeilen. Dit artikel behandelt de mechanica: waarom een web push-abonnement is gekoppeld aan één origin, wat een domeinwijziging daadwerkelijk overleeft (meer dan u denkt), wat er misgaat (minder dan u vreest, maar het deel dat zich opstapelt), en de stabiele-origin-architectuur die één abonneelijst groeit voor elk merk dat u vandaag runt en elk merk dat u vervolgens lanceert.
Waarom een web push-abonnement is gekoppeld aan één domein
Wanneer een bezoeker op Toestaan klikt, abonneert de browser hen niet op uw merk. Het abonneert hen op een origin: het exacte protocol en de hostnaam in de adresbalk. De Push API maakt het abonnement aan tegen een service worker die op die origin is geregistreerd, met behulp van de applicatieserver-sleutel van uw platform. Het record dat de browser retourneert, heeft drie delen: een endpoint-URL op de pushservice van de browserleverancier, plus twee encryptiewaarden (p256dh en auth) die payloads vergrendelen op die ene browser.
Notificatietoestemming volgt dezelfde regel. Het wordt per origin verleend, niet per bedrijf. sportsbook.com en sportsbook.ca zijn vreemden op protocolniveau, zelfs als ze een logo, een portemonnee en een spelersdatabase delen. Elk vraagt afzonderlijk toestemming, abonneert zich afzonderlijk en bouwt een aparte lijst op.
Origin, push notification service worker en VAPID-sleutels: de drieledige vergrendeling
Drie dingen pinnen een web push-abonnement vast. De origin die het heeft aangemaakt. De push notification service worker die berichten voor het abonnement ontvangt. En de VAPID-sleutels die uw verzendplatform beheert. Het abonnement wordt aangemaakt onder de publieke sleutel, en de pushservice accepteert een verzending alleen wanneer deze is geverifieerd met de bijpassende privésleutel. Uw platform bewijst dat het het sleutelpaar bezit bij elke verzending; het abonnementsrecord zelf bevat alleen de publieke helft.
De browser handhaaft ook één abonnement per origin. Opnieuw abonneren met een andere applicatieserver-sleutel mislukt totdat het bestaande abonnement is verwijderd. Die beperking is later belangrijk, wanneer we bij consolidatie komen: op dezelfde origin kan een nieuwe service worker stilzwijgend een bestaande abonnee overnemen. Over origins heen kan dat nooit.
Wat een domein migratie breekt in web push (en wat niet)
Hier is het deel waar de meeste teams de mist ingaan bij een domein migratie: ze gaan ervan uit dat de oude lijst verdwijnt. Dat doet hij niet. Abonnees die zich op het oude domein hebben aangemeld, blijven uw meldingen ontvangen.
Bezorging raakt uw website nooit aan. Wanneer u verzendt, doet uw platform een aanvraag die is geauthenticeerd met uw VAPID-sleutels naar de pushservice die elk abonnement beheert (Google's voor Chrome, Mozilla's voor Firefox, Apple's voor Safari), en die service levert de versleutelde payload aan de service worker die al is geïnstalleerd in de browser van de abonnee. Het oude domein kan worden omgeleid, geparkeerd of volledig verdwenen zijn. De melding landt nog steeds.
De klikbestemming is ook van u. Klik-URL's worden per campagne ingesteld, dus een abonnee die zich heeft aangemeld op een domein dat u twee jaar geleden heeft stopgezet, kan op de melding van vandaag klikken en op de live site van vandaag landen.
| Na een domeinwijziging | Werkt het nog steeds? |
|---|---|
| Bezorging aan bestaande abonnees | Ja — pushes worden via de pushservices van de browserleveranciers gerouteerd, niet via uw site |
| Klik-doorbestemming | Ja — de klik-URL wordt per campagne ingesteld; wijs deze naar het huidige domein |
| Oude-oorsprong abonnees die automatisch lid worden van de nieuwe domeinlijst | Nee — toestemming is per oorsprong, dus lid worden van de nieuwe lijst is een nieuwe opt-in |
| Nieuwe aanmeldingen op de oude oorsprong | Nee — en dit is het verlies dat zich opstapelt |
Een domein migratie kost u dus niet de abonnees die u heeft. Het kost u de machine die ze produceerde. De dag dat het verkeer verschuift, begint de aanmeldingsregistratie op het nieuwe domein opnieuw bij nul, terwijl de oude lijst langzaam vervalt. Pas dat toe op een portfolio van merken en elke eigenschap betaalt die resetbelasting onafhankelijk.
De werkelijke kosten: elke nieuwe domein begint zijn lijst vanaf nul
Gefragmenteerde registratie zou een ergernis zijn in een kanaal met weinig churn. Gokken is geen kanaal met weinig churn. Op gok- en gamingwebsites op PushEngage, in één venster van 90 dagen, hebben uitschrijvingen ongeveer 91% van de acquisitie van nieuwe abonnees in het segment tenietgedaan. Een lijst in deze verticale is een badkuip met de kraan open; het enige dat het niveau op peil houdt, is de kraan die continu loopt.
Fragmentatie zet de kraan uit, één eigendom tegelijk. De lijst van elk merk groeit alleen zolang dat specifieke domein opt-ins verdient. Een migratie reset zijn kraan naar nul. Een nieuwe white-label begint op nul. Ondertussen blijven de browsers aftappen: de automatische intrekking van toestemming door Chrome, aangekondigd in oktober 2025, verwijdert stilzwijgend de toestemming voor meldingen van sites met zeer lage betrokkenheid en een hoog aantal meldingen. Een lijst die niet vastlegt, is niet plat. Het krimpt.
De CAC-framing maakt de inzet duidelijk. U betaalde om elke bezoeker te werven, en de opt-in is het enige duurzame retargeting-bezit dat het bezoek achterlaat. Het argument voor push in deze verticale rust op het samengestelde effect van dat bezit. Fragmentatie schrijft er telkens een deel van af wanneer een domein verandert.
De stabiele-oorsprong architectuur: één abonnementsdomein voor elk merk
De oplossing is om helemaal geen abonnementen meer aan te maken op merkdomeinen. Koppel elk abonnement aan één stabiele HTTPS-bron die uw groep beheert, een die langer meegaat dan enig individueel merkdomein, en laat elke eigenschap deze voeden.
PushEngage levert dit als de aangepaste subdomein-workflow, gebouwd voor precies dit geval: meerdere domeinen die gecentraliseerd abonneebeheer nodig hebben onder één beheerd domein. De opzet:
- Kies een stabiele, merkneutrale bron die u bezit, zoals
notify.yourbrandgroup.com. Kies een naam die u prettig vindt voor abonnees om te zien, omdat browsers de abonnerende bron weergeven op meldingen. - Upload het PushEngage service worker-bestand naar de hoofdmap van dat domein en schakel de functie in onder Site-instellingen » Geavanceerde instellingen. De stabiele bron krijgt zijn eigen installatiesnippet met
isSubscriptionOnSubDomain: true. - Voeg de PushEngage-snippet toe aan elk merkdomein. Wanneer een bezoeker zich op een van deze aanmeldt, wordt de workflow via de stabiele bron geleid, waar het daadwerkelijke abonnement wordt aangemaakt.
Twee vereisten zijn niet-onderhandelbaar in deze modus. Ten eerste is aanmelden alleen dubbelstaps: de toestemmingsprompt van de browser moet worden geactiveerd op de bron die het abonnement bezit, dus een native prompt in één stap op het merkdomein is niet mogelijk. Ten tweede blijft Snelle Installatie ingeschakeld.
Wees eerlijk over de afweging. Dubbele stap voegt een klik toe vóór de toestemmingsprompt en converteert op het moment van vastleggen lager. Het is de moeite waard om naast de bredere hefbomen voor het verhogen van uw aanmeldingspercentage te lezen. Maar een abonnee in één stap die wordt vastgelegd op een domein waar u later van migreert, is een afschrijvend bezit. Een abonnee in twee stappen op de stabiele bron overleeft elke rebrand, elke regionale lancering, elke migratie die u ooit zult uitvoeren. Over elke horizon die een domeinwijziging omvat, wint de geconsolideerde lijst op totale bereik.
Pushmeldingen voor meerdere websites, één abonneelijst
Zodra de stabiele bron aanwezig is, betekenen pushmeldingen voor meerdere websites geen meerdere lijsten meer. Elk merkdomein voedt dezelfde abonneebasis. Het lanceren van een nieuw regionaal domein of white-label in het volgende kwartaal betekent het toevoegen van de snippet; de opt-ins komen vanaf dag één in de geconsolideerde lijst terecht. Het stopzetten van een domein betekent dat er niets met de lijst gebeurt: de vastlegging gaat door op de overlevende eigendommen, de levering gaat door via de pushservices en de klik-URL's wijzen naar waar u live bent.
Het consolideren van de abonneelijsten die u al hebt gefragmenteerd
De meeste operators komen met geschiedenis bij deze architectuur aan: live lijsten verspreid over oude domeinen, sommige inactief, sommige bij een andere leverancier. Consolidatie loopt op drie sporen parallel.
| Sporen | Wat u doet | Wat het u oplevert |
|---|---|---|
| 1. Houd oude lijsten werkend | Blijf verzenden naar elke oude bronlijst; wijs klik-URL's toe aan het huidige live domein | Betaald bereik blijft sessies produceren in plaats van te worden afgeschreven |
| 2. Leg nieuw vast op de stabiele bron | Schakel de aanmeldingsfunctie van elke live eigenschap over naar de workflow van de stabiele bron | Fragmentatie stopt de dag dat het wordt verzonden; alle nieuwe acquisities komen in één lijst terecht |
| 3. Laat oude lijsten zichzelf samenvoegen | Elke verzending naar een oude lijst drijft een herbezoek naar een huidig domein, waar de stabiele-oorsprong prompt wacht | Actieve abonnees consolideren zichzelf, geen geforceerde herautorisatie |
Track 3 is het stille werkpaard. Browserpermissie is per oorsprong, dus abonnees van de oude oorsprong hebben technisch gezien een nieuwe opt-in nodig om zich bij de geconsolideerde lijst aan te sluiten, maar u hoeft er nooit om te vragen. Gezien hoe snel gokpubliek wisselt, wordt de geconsolideerde lijst binnen enkele maanden de meerderheid van uw actieve bereik, simpelweg omdat actieve spelers blijven bezoeken.
Als sommige fragmenten leven met een andere push-leverancier op een domein dat u bezit, kunnen ze ook meekomen. Het standaardpad van PushEngage is een stille herabonnering: bij het volgende bezoek van een abonnee neemt de pushmelding-service worker van de SDK het over en abonneert deze hen opnieuw zonder een tweede toestemmingsprompt, omdat toestemming op oorsprongniveau blijft bestaan. Voor OneSignal kan PushEngage de lijst rechtstreeks ophalen via de API van OneSignal. Migratie is white-glove en gratis op betaalde abonnementen.
Per-merk campagnes binnen één geconsolideerde lijst
Eén lijst betekent niet één bericht. Het betekent één asset met betere targeting dan vier fragmenten ooit zouden kunnen beheren.
Leg het oorspronkelijke merk vast als een abonneekenmerk bij opt-in, en per-merk cohorten bestaan vanaf dag één. Vanaf daar doet segmentatie wat aparte lijsten nooit konden: merk gekruist met geografie, stortingsgedrag, recentheid van sessies of voorkeur voor competities. Dat is het model dat #1 uiteenzet in de pushmeldingen voor goksites playbook. De odds-boost campagne van het vlaggenschip gaat naar de gokkers van het vlaggenschip; de cashback-herinnering van de casino white-label gaat naar zijn spelers; een portfolio-brede wedstrijdmelding gaat naar iedereen die de competitie volgt, onder welk merk ze zich ook hebben aangemeld.
Het voordeel is niet cosmetisch. Op goksites met PushEngage ziet de gemiddelde goksitesender ~2,1% CTR op bekeken meldingen; de top deciel doet 6,9% — ruwweg verdrievoudigd. Dat verschil is een targetingkloof, geen kanaalkloof, en u kunt geen gedragscohorten bouwen over vier losgekoppelde fragmenten. Consolidatie is wat segmentatie als leveringspraktijk werkbaar maakt op portfolioschaal. Dat is nu belangrijker nu Chrome elke verzendende oorsprong dagelijks beoordeelt en storende afzenders beperkt (live sinds januari 2026). Eén stabiele oorsprong concentreert uw afzendersreputatie; gesegmenteerde, relevante verzendingen houden deze gezond.
Eén lijst maakt ook verantwoord gokken operationeel eenvoudiger, en dat is een functie, geen voetnoot. Een zelf uitgesloten speler die is onderdrukt op een portfolio-breed segment, wordt overal tegelijk onderdrukt, niet merk per merk waar een fragment kan ontsnappen. Stille uren en frequentielimieten gelden op abonneeniveau voor de campagnes van elk merk. En de campagnes zelf moeten de lijn vasthouden: geen win-back rond het najagen van verliezen, geen afteldruk op stortingsprompts.
Voer web push uit op meerdere domeinen zonder uw lijst te splitsen
De hele opstelling is kleiner dan het klinkt: een DNS-record voor de stabiele oorsprong, het service worker-bestand op de root, de schakelaar in Geavanceerde instellingen, het isSubscriptionOnSubDomain-snippet en het standaard-snippet op elk merkdomein met dubbelstaps-opt-in geconfigureerd en Quick Install ingeschakeld. Teams leveren het doorgaans dezelfde dag, zonder herplatforming. Dat is de volledige inspanning om pushmeldingen voor meerdere websites vanaf één oorsprong te laten werken.
Wat je terugkrijgt, is waar fragmentatie stilletjes belastingen op heft: een abonneelijst die groeit. Elk merk voedt het, elke domeinwijziging stuit erop, en elke campagne kan zich richten op de hele portefeuille of op één merk tegelijk. Als je de mechanica wilt zien tegen je eigen domeinkaart, begin dan met het overzicht van de web pushmeldingenfunctie en de prijsplannen. Betaalde plannen hebben een 14-daagse niet-goed-geld-teruggarantie, zodat de architectuur zichzelf kan bewijzen op jouw verkeer voordat de beslissing definitief is.
