Din portefølje ser sandsynligvis sådan ud: en flagskibs-sportsbog på .com, et licenseret regionalt brand på .ca, en casino white-label, du lancerede sidste forår, og en rebranding planlagt til Q4. Ét retention-team ejer det hele. Og hvis du kører web push på tværs af flere domæner på standardmåden, ejer du også fire adskilte abonnentlister, der hver især vokser for sig selv, og ingen af dem taler med de andre.
Den fragmentering er ikke en konfigurationsfejl, du har lavet. Det er sådan, webbets push-arkitektur fungerer. Browseren fastgør hvert abonnement til et enkelt domæne, og ingen dashboard-indstilling ændrer det.
Der er dog en understøttet måde at omgå det på. Denne artikel dækker mekanismerne: hvorfor et web push-abonnement er bundet til ét oprindelsessted, hvad der faktisk overlever en domæneændring (mere end du tror), hvad der går i stykker (mindre end du frygter, men den del der akkumuleres), og den stabile oprindelsesarkitektur, der vokser én abonnentliste på tværs af hvert brand, du kører i dag, og hvert brand, du lancerer næste gang.
Hvorfor et web push-abonnement er bundet til ét domæne
Når en besøgende klikker Tillad, abonnerer browseren dem ikke på dit brand. Den abonnerer dem på et oprindelsessted: den nøjagtige protokol og værtsnavn i adresselinjen. Push API'en opretter abonnementet mod en service worker, der er registreret på det oprindelsessted, ved hjælp af din platforms applikationsservernøgle. Den post, browseren returnerer, har tre dele: en slutpunkt-URL på browserudbyderens push-tjeneste, plus to krypteringsværdier (p256dh og auth), der låser payloads til den ene browser.
Notifikationstilladelse følger den samme regel. Den gives pr. oprindelsessted, ikke pr. firma. sportsbook.com og sportsbook.ca er fremmede på protokolniveau, selv når de deler et logo, en wallet og en spillerdatabase. Hver især spørger separat, abonnerer separat og opbygger en separat liste.
Oprindelsessted, push-notifikation service worker og VAPID-nøgler: den tre-delte lås
Tre ting fastgør et web push-abonnement på plads. Oprindelsesstedet, der oprettede det. Push-notifikation service worker, der modtager beskeder for det. Og VAPID-nøglerne, din afsendelsesplatform holder. Abonnementet oprettes under den offentlige nøgle, og push-tjenesten accepterer en afsendelse, kun når den er godkendt med den matchende private nøgle. Din platform beviser, at den holder nøgleparret ved hver afsendelse; selve abonnementsposten bærer kun den offentlige halvdel.
Browseren håndhæver også ét abonnement pr. oprindelsessted. At kalde subscribe igen med en anden applikationsservernøgle fejler, indtil det eksisterende abonnement er fjernet. Den begrænsning betyder noget senere, når vi kommer til konsolidering: på samme oprindelsessted kan en ny service worker overtage en eksisterende abonnent lydløst. På tværs af oprindelsessteder kan den aldrig.
Hvad en domænemigrering bryder i web push (og hvad den ikke gør)
Her er den del, de fleste teams tager fejl med en domænemigrering: de antager, at den gamle liste dør. Det gør den ikke. Abonnenter, der har tilmeldt sig på det gamle domæne, fortsætter med at modtage dine notifikationer.
Levering rører aldrig din hjemmeside. Når du sender, foretager din platform en anmodning, der er godkendt med dine VAPID-nøgler, til push-tjenesten, der holder hver abonnement (Googles til Chrome, Mozillas til Firefox, Apples til Safari), og den tjeneste leverer den krypterede nyttelast til service worker, der allerede er installeret i abonnentens browser. Det gamle domæne kan omdirigeres, parkeres eller være helt væk. Notifikationen lander stadig.
Klikdestinationen er også din. Klik-URL'er er indstillet pr. kampagne, så en abonnent, der har tilmeldt sig på et domæne, du udfasede for to år siden, kan klikke på dagens notifikation og lande på dagens live-side.
| Efter en domæneændring | Fungerer stadig? |
|---|---|
| Levering til eksisterende abonnenter | Ja — pushes rutes gennem browserudbydernes push-tjenester, ikke gennem dit websted |
| Klik-gennem destination | Ja — klik-URL'en er indstillet pr. kampagne; peg den mod det aktuelle domæne |
| Gamle-oprindelses-abonnenter, der automatisk tilmelder sig det nye domænes liste | Nej — tilladelse er pr. oprindelse, så tilmelding til den nye liste er en ny tilmelding |
| Nye tilmeldinger på den gamle oprindelse | Nej — og dette er tabet, der hober sig op |
Så en domænemigrering koster dig ikke de abonnenter, du har. Den koster dig den maskine, der producerede dem. Den dag trafikken flytter, genstarter tilmeldingsfangst på det nye domæne fra nul, mens den gamle liste langsomt forfalder. Kør det på tværs af en portefølje af brands, og hver ejendom betaler denne nulstillingsskat uafhængigt.
Den reelle omkostning: hvert nyt domæne starter sin liste fra nul
Fragmenteret fangst ville være en irritation i en kanal med lavt churn. Betting er ikke en kanal med lavt churn. På tværs af betting- og spilwebsteder på PushEngage, i et 90-dages vindue, slettede afmeldinger ca. 91% af ny abonnentanskaffelse på tværs af segmentet. En liste i denne vertikal er et badekar med afløbet åbent; det eneste, der holder niveauet oppe, er vandhanen, der kører kontinuerligt.
Fragmentering slukker for vandhanen, én ejendom ad gangen. Hvert brands liste vokser kun, mens det specifikke domæne tjener tilmeldinger. En migrering nulstiller dets vandhane til nul. En ny white-label starter fra nul. I mellemtiden fortsætter browserne med at dræne: Chromes automatiske tilbagekaldelse af tilladelser, annonceret i oktober 2025, fjerner stille og roligt notifikationstilladelse fra websteder med meget lavt engagement og høj notifikationsvolumen. En liste, der ikke fanger, er ikke flad. Den skrumper.
CAC-rammen gør indsatsen klar. Du betalte for at erhverve hver eneste af disse besøgende, og tilmeldingen er det eneste holdbare retargeting-aktiv, som besøget efterlader. Sagen for push i denne vertikal hviler på, at dette aktiv vokser. Fragmentering afskriver en del af det, hver gang et domæne ændres.
Den stabile oprindelsesarkitektur: ét abonnementsdomæne for hvert brand
Løsningen er at stoppe med at oprette abonnementer på domænedomæner helt. Forankr hvert abonnement til en enkelt stabil HTTPS-oprindelse, som din gruppe kontrollerer, en der vil overleve ethvert individuelt domænedomæne, og lad hver ejendom føde den.
PushEngage leverer dette som flowet for brugerdefinerede underdomæner, bygget til netop dette tilfælde: flere domæner, der har brug for samlet abonnentadministration under ét kontrolleret domæne. Opsætningen:
- Vælg en stabil, mærke-neutral oprindelse, du ejer, f.eks.
notify.yourbrandgroup.com. Vælg et navn, du er glad for, at abonnenter ser, fordi browsere viser den abonnere oprindelse på notifikationer. - Upload PushEngage-serviceworker-filen til det domænes rod, og aktiver funktionen under Siteindstillinger » Avancerede indstillinger. Den stabile oprindelse får sit eget installationsuddrag med
isSubscriptionOnSubDomain: true. - Tilføj PushEngage-uddraget til hvert domænedomæne. Når en besøgende vælger at tilmelde sig på et af dem, rutes flowet gennem den stabile oprindelse, hvor det faktiske abonnement oprettes.
To krav er ikke-omsættelige i denne tilstand. For det første er tilmelding kun med dobbelt trin: browserens tilladelsesprompt skal udløses på den oprindelse, der ejer abonnementet, så en enkelt-trins indbygget prompt på domænedomænet er ikke mulig. For det andet forbliver Hurtig Installation aktiveret.
Vær ærlig om kompromiset. Dobbelt-trin tilføjer et klik før tilladelsesprompten, og den konverterer lavere i øjeblikket for fangst. Det er værd at læse sammen med de bredere håndtag til at øge din tilmeldingsrate. Men en enkelt-trins abonnent fanget på et domæne, du senere flytter væk fra, er et faldende aktiv. En dobbelt-trins abonnent på den stabile oprindelse overlever enhver rebrand, enhver regional lancering, enhver migration, du nogensinde vil køre. Over enhver horisont, der inkluderer en domæneændring, vinder den konsoliderede liste på total rækkevidde.
Push-notifikationer til flere websteder, én abonnentliste
Når den stabile oprindelse er på plads, betyder push-notifikationer til flere websteder ikke længere flere lister. Hvert domænedomæne føder den samme abonnentbase. At lancere et nyt regionalt domæne eller white-label næste kvartal betyder at tilføje udtrækket; dets tilmeldinger lander i den konsoliderede liste fra dag ét. At pensionere et domæne betyder, at intet sker med listen overhovedet: fangst fortsætter på de overlevende ejendomme, levering fortsætter gennem push-tjenesterne, og klik-URL'er peger, hvor end du er live.
Konsolidering af de abonnentlister, du allerede har fragmenteret
De fleste operatører ankommer til denne arkitektur med historie: live lister spredt over gamle domæner, nogle inaktive, nogle hos en anden leverandør. Konsolidering kører på tre spor parallelt.
| Spor | Hvad du gør | Hvad det giver dig |
|---|---|---|
| 1. Hold gamle lister i gang | Fortsæt med at sende til hver gammel oprindelsesliste; peg klik-URL'er mod det aktuelle live-domæne | Betalt rækkevidde bliver ved med at producere sessioner i stedet for at blive afskrevet |
| 2. Fang nye på den stabile oprindelse | Skift hver live-ejendoms tilmelding til flowet for den stabile oprindelse | Fragmentering stopper den dag, det skibes; al ny erhvervelse lander i én liste |
| 3. Lad gamle lister finde sig selv | Hver afsendelse til en gammel liste driver et genbesøg til et aktuelt domæne, hvor den stabile oprindelsesprompt venter | Aktive abonnenter konsoliderer sig selv, ingen tvungen gen-tilladelse |
Spor 3 er den stille arbejdshest. Browser-tilladelse er pr. oprindelse, så abonnenter med gammel oprindelse har teknisk set brug for en ny opt-in for at deltage i den konsoliderede liste, men du behøver aldrig at kræve det. I betragtning af hvor hurtigt betting-publikum cykler, bliver den konsoliderede liste størstedelen af din aktive rækkevidde inden for måneder, simpelthen fordi aktive spillere bliver ved med at besøge.
Hvis nogle fragmenter lever med en anden push-udbyder på et domæne, du ejer, kan de også komme med. PushEngages standardvej er en lydløs gen-abonnement: ved abonnentens næste besøg overtager SDK'ens push-notifikationstjeneste-worker og gen-abonnerer dem uden en anden tilladelsesprompt, fordi oprindelsesniveau-tilladelse består. For OneSignal kan PushEngage hente listen direkte via OneSignals API. Migration er "white-glove" og gratis på betalte planer.
Kampagner pr. brand inden for én konsolideret liste
Én liste betyder ikke én besked. Det betyder ét aktiv med bedre målretning, end fire fragmenter nogensinde kunne håndtere.
Fang det oprindelige brand som en abonnentattribut ved opt-in, og kohorter pr. brand eksisterer fra dag ét. Derfra gør segmentering, hvad separate lister aldrig kunne: brand krydset med geografi, indbetalingsadfærd, session-recency eller ligapræference. Det er modellen, som #1 lægger ud i push-notifikationer til betting-sider playbook. Flagskibets odds-boost-kampagne går til flagskibets spillere; casinoets white-label cashback-påmindelse går til dets spillere; en portefølje-dækkende kampopdatering går til alle, der følger ligaen, uanset hvilket brand de tilmeldte sig under.
Fordelen er ikke kosmetisk. På tværs af betting-sider på PushEngage ser den mediale betting-site-afsender ~2,1% CTR på viste notifikationer; den øverste decil klarer 6,9% — cirka tredobbelt. Den spredning er et målretningsgab, ikke et kanalgab, og du kan ikke bygge adfærdsmæssige kohorter på tværs af fire frakoblede fragmenter. Konsolidering er det, der gør segmentering som en leveringspraksis anvendelig i porteføljestørrelse. Det betyder mere nu, hvor Chrome scorer hver afsendelsesoprindelse dagligt og drosler forstyrrende afsendere (live siden januar 2026). Én stabil oprindelse koncentrerer din afsender-reputation; segmenterede, relevante afsendelser er det, der holder den sund.
Én liste gør også ansvarligt spil operationelt enklere, og det er en funktion, ikke en fodnote. En selvudelukket spiller, der er undertrykt på et portefølje-dækkende segment, er undertrykt overalt på én gang, ikke brand for brand, hvor et fragment kan slippe igennem. Stilletider og frekvensgrænser gælder på abonnentniveau på tværs af alle brands kampagner. Og selve kampagnerne bør holde linjen: ingen "win-back" indrammet omkring jagt på tab, ingen nedtællingspres på indbetalingsprompter.
Kør web push på tværs af flere domæner uden at opdele din liste
Hele opsætningen er mindre, end det lyder: en DNS-post til den stabile oprindelse, service worker-filen ved dens rod, kontakten i Avancerede indstillinger, isSubscriptionOnSubDomain-snippet, og standard-snippet på hvert branddomæne med dobbelttrins-opt-in konfigureret og Quick Install slået til. Teams leverer det typisk samme dag, uden re-platforming. Det er hele indsatsen for at køre push-meddelelser for flere websteder fra én oprindelse.
Det, du får tilbage, er den ting, som fragmentering stille og roligt beskatter: en abonnentliste, der vokser. Hvert brand bidrager til den, hver domæneændring preller af på den, og hver kampagne kan målrette hele porteføljen eller ét brand ad gangen. Hvis du vil se mekanikken mod dit eget domænekort, skal du starte med oversigten over web push-meddelelsesfunktionen og prisplanerne. Betalte planer har en 14-dages pengene-tilbage-garanti, så arkitekturen kan bevise sig på din trafik, før beslutningen er endelig.
