Din portfölj ser förmodligen ut ungefär så här: en flaggskepps-sportbok på .com, ett licensierat regionalt varumärke på .ca, en vitmärkt kasino som du lanserade i våras och en omprofilering planerad till Q4. Ett kundåterhållningsteam äger allt. Och om du kör webbpushning över flera domäner på standard sätt, äger du också fyra frånkopplade prenumerantlistor, var och en växer på egen hand, ingen av dem kommunicerar med de andra.
Den fragmenteringen är inte ett konfigurationsfel du har gjort. Det är så webbens pusharkitektur fungerar. Webbläsaren fäster varje prenumeration till en enda domän, och ingen instrumentpanelsinställning ändrar det.
Det finns dock ett understött sätt att kringgå det. Den här artikeln täcker mekanismerna: varför en webbpushprenumeration binds till ett ursprung, vad som faktiskt överlever en domänändring (mer än du tror), vad som går sönder (mindre än du fruktar, men den del som ackumuleras), och arkitekturen för stabilt ursprung som växer en prenumerantlista över varje varumärke du driver idag och varje varumärke du lanserar framöver.
Varför en webbpushprenumeration binds till en domän
När en besökare klickar på Tillåt, prenumererar webbläsaren dem inte till ditt varumärke. Den prenumererar dem till ett ursprung: det exakta protokollet och värdnamnet i adressfältet. Push-API:et skapar prenumerationen mot en service worker som är registrerad på det ursprunget, med hjälp av din plattforms applikationsservernyckel. Posten som webbläsaren returnerar har tre delar: en slutpunkts-URL på webbläsarleverantörens push-tjänst, plus två krypteringsvärden (p256dh och auth) som låser nyttolaster till den enda webbläsaren.
Notifieringsbehörighet följer samma regel. Den beviljas per ursprung, inte per företag. sportsbook.com och sportsbook.ca är främlingar på protokollnivå, även när de delar en logotyp, en plånbok och en spelardatabas. Var och en frågar separat, prenumererar separat och bygger en separat lista.
Ursprung, push-notifierings-service worker och VAPID-nycklar: den tredelade låsningen
Tre saker fäster en webbpushprenumeration på plats. Ursprunget som skapade den. Push-notifierings-service workern som tar emot meddelanden för den. Och VAPID-nycklarna som din sändningsplattform innehar. Prenumerationen skapas under den publika nyckeln, och push-tjänsten accepterar en sändning endast när den är autentiserad med den matchande privata nyckeln. Din plattform bevisar att den innehar nyckelparet vid varje sändning; själva prenumerationsposten bär bara den publika halvan.
Webbläsaren upprätthåller också en prenumeration per ursprung. Att anropa subscribe igen med en annan applikationsservernyckel misslyckas tills den befintliga prenumerationen tas bort. Den begränsningen är viktig senare, när vi kommer till konsolidering: på samma ursprung kan en ny service worker tyst ta över en befintlig prenumerant. Över ursprung kan det aldrig ske.
Vad en domänmigrering bryter i webbpushning (och vad den inte gör)
Här är den del som de flesta team gör fel med en domänmigrering: de antar att den gamla listan dör. Det gör den inte. Prenumeranter som anmälde sig på den gamla domänen fortsätter att ta emot dina aviseringar.
Leveransen rör aldrig din webbplats. När du skickar gör din plattform en begäran, autentiserad med dina VAPID-nycklar, till push-tjänsten som hanterar varje prenumeration (Googles för Chrome, Mozillas för Firefox, Apples för Safari), och den tjänsten levererar den krypterade nyttolasten till service worker som redan är installerad i prenumerantens webbläsare. Den gamla domänen kan omdirigeras, parkeras eller vara helt borta. Aviseringen landar ändå.
Klickdestinationen är också din. Klick-URL:er ställs in per kampanj, så en prenumerant som anmälde sig på en domän du pensionerade för två år sedan kan klicka på dagens avisering och landa på dagens live-webbplats.
| Efter en domänändring | Fungerar fortfarande? |
|---|---|
| Leverans till befintliga prenumeranter | Ja – push-meddelanden dirigeras via webbläsartillverkarnas push-tjänster, inte via din webbplats |
| Klickbar destination | Ja – klick-URL:en ställs in per kampanj; peka den mot den aktuella domänen |
| Gamla ursprungsprenumeranter som automatiskt går med i den nya domänens lista | Nej – behörighet är per ursprung, så att gå med i den nya listan är en ny opt-in |
| Nya registreringar på det gamla ursprunget | Nej – och det är förlusten som förvärras |
Så en domänmigrering kostar dig inte de prenumeranter du har. Den kostar dig maskinen som producerade dem. Den dag trafiken flyttas, börjar registreringar på den nya domänen om från noll medan den gamla listan sakta förfaller. Kör det över en portfölj av varumärken och varje egendom betalar den återställningsskatten oberoende.
Den verkliga kostnaden: varje ny domän börjar sin lista från noll
Fragmenterad insamling skulle vara ett irritationsmoment i en kanal med låg omsättning. Betting är inte en kanal med låg omsättning. Mellan betting- och spelsajter på PushEngage, under ett 90-dagarsfönster, raderade avregistreringar ungefär 91 % av ny prenumerantanskaffning över segmentet. En lista i denna vertikal är ett badkar med öppen avlopp; det enda som håller nivån uppe är kranen som rinner kontinuerligt.
Fragmentering stänger av kranen, en egendom i taget. Varje varumärkes lista växer bara medan den specifika domänen tjänar opt-ins. En migrering återställer dess kran till noll. En ny white-label börjar från noll. Under tiden fortsätter webbläsarna att dränera: Chromes automatiska återkallande av behörighet, aviserat i oktober 2025, tar tyst bort aviseringstillstånd från webbplatser med mycket lågt engagemang och hög aviseringstrafik. En lista som inte samlar in växer inte. Den krymper.
CAC-inramningen gör insatserna tydliga. Du betalade för att skaffa varje enskild besökare, och opt-in är den enda hållbara retargeting-tillgången som besöket lämnar efter sig. Fallet för push i denna vertikal vilar på att den tillgången växer. Fragmentering skriver av en del av den varje gång en domän ändras.
Arkitekturen med stabil ursprung: en prenumerationsdomän för varje varumärke
Lösningen är att sluta skapa prenumerationer på varumärkesdomäner helt och hållet. Förankra varje prenumeration till en enda stabil HTTPS-ursprung som din grupp kontrollerar, en som kommer att överleva alla enskilda varumärkesdomäner, och låt varje egenskap mata den.
PushEngage levererar detta som flödet för anpassad underdomän, byggt för just detta fall: flera domäner som behöver enhetlig prenumerationsadministration under en kontrollerad domän. Installationen:
- Välj ett stabilt, varumärkesneutralt ursprung som du äger, till exempel
notify.yourbrandgroup.com. Välj ett namn som du är nöjd med att prenumeranter ser, eftersom webbläsare visar det prenumererande ursprunget på aviseringar. - Ladda upp PushEngage service worker-filen till den domänens rot och aktivera funktionen under Webbplatsinställningar » Avancerade inställningar. Det stabila ursprunget får sitt eget installationsutdrag med
isSubscriptionOnSubDomain: true. - Lägg till PushEngage-utdraget på varje varumärkesdomän. När en besökare godkänner på någon av dem, dirigeras flödet genom det stabila ursprunget, där den faktiska prenumerationen skapas.
Två krav är icke-förhandlingsbara i detta läge. För det första är godkännande endast dubbelsteg: webbläsarens tillåtelseprompt måste utlösas på det ursprung som äger prenumerationen, så en enkelstegs inbyggd prompt på varumärkesdomänen är inte möjlig. För det andra förblir Snabbinstallation aktiverad.
Var ärlig om avvägningen. Dubbelsteg lägger till ett klick före tillåtelseprompten, och det konverterar lägre i ögonblicket för fångst. Det är värt att läsa tillsammans med de bredare spakarna för att höja din opt-in-grad. Men en enkelstegs prenumerant som fångas på en domän du senare migrerar bort från är en deprecierande tillgång. En dubbelstegs prenumerant på det stabila ursprunget överlever varje omprofilering, varje regional lansering, varje migrering du någonsin kommer att köra. Över alla tidshorisonter som inkluderar en domänändring, vinner den konsoliderade listan på total räckvidd.
Pushmeddelanden för flera webbplatser, en prenumerantlista
När det stabila ursprunget är på plats, slutar pushmeddelanden för flera webbplatser att innebära flera listor. Varje varumärkesdomän matar samma prenumerantbas. Att lansera en ny regional domän eller white-label nästa kvartal innebär att lägga till utdraget; dess opt-ins landar i den konsoliderade listan från dag ett. Att pensionera en domän innebär att ingenting händer med listan alls: fångsten fortsätter på de överlevande egenskaperna, leveransen fortsätter genom push-tjänsterna, och klick-URL:er pekar dit du är live.
Konsolidera prenumerantlistorna du redan fragmenterat
De flesta operatörer kommer fram till denna arkitektur med historik: live-listor spridda över gamla domäner, vissa slumrande, vissa hos en annan leverantör. Konsolidering körs på tre spår parallellt.
| Spår | Vad du gör | Vad det ger dig |
|---|---|---|
| 1. Håll gamla listor fungerande | Fortsätt skicka till varje gammal ursprungslista; peka klick-URL:er mot den nuvarande live-domänen | Betald räckvidd fortsätter att producera sessioner istället för att skrivas av |
| 2. Fånga nytt på det stabila ursprunget | Byt varje live-egenskaps opt-in till flödet för stabilt ursprung | Fragmentering upphör den dag det driftsätts; all ny förvärv landar i en lista |
| 3. Låt gamla listor flöda in sig själva | Varje sändning till en gammal lista driver en återbesökning till en aktuell domän, där prompten för stabil ursprung väntar | Aktiva prenumeranter konsoliderar sig själva, ingen tvingad ompermission |
Spår 3 är det tysta arbetshästet. Webbläsarbehörighet är per ursprung, så prenumeranter från gamla ursprung behöver tekniskt sett ett nytt godkännande för att gå med i den konsoliderade listan, men du behöver aldrig kräva det. Med tanke på hur snabbt spelpubliken cyklar, blir den konsoliderade listan majoriteten av din aktiva räckvidd inom månader, helt enkelt för att aktiva spelare fortsätter att besöka.
Om vissa fragment lever med en annan push-leverantör på en domän du äger, kan de också följa med. PushEngages standardväg är en tyst återprenumeration: vid prenumerantens nästa besök tar SDK:s push-meddelandetjänst-worker över och återprenumererar dem utan en andra behörighetsprompt, eftersom behörighet på ursprungsnivå kvarstår. För OneSignal kan PushEngage hämta listan direkt via OneSignals API. Migrering är "white-glove" och gratis på betalda planer.
Kampanjer per varumärke inom en konsoliderad lista
En lista betyder inte ett meddelande. Det betyder en tillgång med bättre målinriktning än vad fyra fragment någonsin skulle kunna hantera.
Fånga det ursprungliga varumärket som en prenumerantattribut vid opt-in, och kohorter per varumärke finns från dag ett. Därifrån gör segmentering vad separata listor aldrig kunde: varumärke korsat med geografi, insättningsbeteende, sessionens aktualitet eller ligapreferens. Det är modellen som #1 lägger fram i spelboken för push-meddelanden för spelsajter. Flaggskeppets odds-boost-kampanj går till flaggskeppets spelare; kasinots white-label cashback-påminnelse går till dess spelare; en portföljöomfattande spelschema-varning går till alla som följer ligan, oavsett vilket varumärke de registrerade sig under.
Fördelen är inte kosmetisk. På spelsajter med PushEngage ser den mediala spelsändaren cirka 2,1 % CTR på visade meddelanden; den övre decilen gör 6,9 % – ungefär tredubbelt. Den spridningen är ett målinriktningsgap, inte ett kanalgap, och du kan inte bygga beteendekohorter över fyra frånkopplade fragment. Konsolidering är vad som gör segmentering som en leveransbar övning fungerande i portföljskala. Det spelar större roll nu när Chrome värderar varje sändande ursprung dagligen och stryper störande sändare (live sedan januari 2026). Ett stabilt ursprung koncentrerar din sändar-rykte; segmenterade, relevanta sändningar är vad som håller det friskt.
En lista gör också ansvarsfullt spelande operationellt enklare, och det är en funktion, inte en fotnot. En självutesluten spelare som undertrycks på ett portföljöomfattande segment undertrycks överallt samtidigt, inte varumärke för varumärke där ett fragment kan slinka igenom. Tysta timmar och frekvensbegränsningar gäller på prenumerantnivå över varje varumärkes kampanjer. Och kampanjerna själva bör hålla linjen: ingen "win-back" inramad kring att jaga förluster, inget nedräkningstryck på insättningsprompter.
Kör webb-push över flera domäner utan att dela upp din lista
Hela installationen är mindre än den låter: en DNS-post för den stabila ursprunget, service worker-filen vid dess rot, växlingen i Avancerade inställningar, kodavsnittet isSubscriptionOnSubDomain och standardavsnittet på varje varumärkesdomän med dubbelstegsopt-in konfigurerat och Quick Install påslaget. Team skickar vanligtvis ut det samma dag, utan omplattformning. Det är hela arbetet för att köra push-meddelanden för flera webbplatser från ett ursprung.
Vad du får tillbaka är det som fragmentering tyst beskattar: en prenumerantlista som växer. Varje varumärke matar den, varje domänändring studsar av den, och varje kampanj kan rikta sig mot hela portföljen eller ett varumärke åt gången. Om du vill se mekaniken mot din egen domänkarta, börja med översikten över webb push-meddelanden och prisplanerna. Betalda planer har en 14-dagars pengarna-tillbaka-garanti, så arkitekturen kan bevisa sig på din trafik innan beslutet är slutgiltigt.
