Ihr Portfolio sieht wahrscheinlich ungefähr so aus: ein Flaggschiff-Sportwettenanbieter auf der .com, eine lizenzierte regionale Marke auf der .ca, ein Casino-White-Label, das Sie letzten Frühling gestartet haben, und ein Rebranding, das für Q4 geplant ist. Ein Retention-Team besitzt alles davon. Und wenn Sie Web Push über mehrere Domains auf die Standardweise betreiben, besitzen Sie auch vier getrennte Abonnentenlisten, die jeweils für sich wachsen und keine davon mit den anderen kommuniziert.
Diese Fragmentierung ist kein Konfigurationsfehler, den Sie gemacht haben. So funktioniert die Push-Architektur des Webs. Der Browser heftet jedes Abonnement an eine einzelne Domain, und keine Dashboard-Einstellung ändert das.
Es gibt jedoch einen unterstützten Weg, dies zu umgehen. Dieser Artikel behandelt die Mechanik: warum ein Web-Push-Abonnement an einen Ursprung gebunden ist, was eine Domainänderung tatsächlich überlebt (mehr als Sie denken), was kaputt geht (weniger als Sie befürchten, aber der Teil, der sich anhäuft) und die Stable-Origin-Architektur, die eine Abonnentenliste über jede Marke, die Sie heute betreiben, und jede Marke, die Sie als nächstes starten, hinweg wachsen lässt.
Warum ein Web-Push-Abonnement an eine Domain gebunden ist
Wenn ein Besucher auf Zulassen klickt, abonniert der Browser ihn nicht für Ihre Marke. Er abonniert ihn für einen Ursprung: das exakte Protokoll und den Hostnamen in der Adressleiste. Die Push-API erstellt das Abonnement gegen einen Service Worker, der auf diesem Ursprung registriert ist, unter Verwendung des Anwendungsserver-Schlüssels Ihrer Plattform. Der vom Browser zurückgegebene Datensatz besteht aus drei Teilen: einer Endpunkt-URL im Push-Dienst des Browseranbieters sowie zwei Verschlüsselungswerten (p256dh und auth), die Payloads an diesen einen Browser binden.
Die Benachrichtigungsberechtigung folgt derselben Regel. Sie wird pro Ursprung erteilt, nicht pro Unternehmen. sportsbook.com und sportsbook.ca sind auf Protokollebene Fremde, auch wenn sie ein Logo, eine Geldbörse und eine Spielerdatenbank teilen. Jeder fordert separat auf, abonniert separat und erstellt eine separate Liste.
Ursprung, Push-Benachrichtigungs-Service-Worker und VAPID-Schlüssel: die Drei-Teile-Sperre
Drei Dinge fixieren ein Web-Push-Abonnement. Der Ursprung, der es erstellt hat. Der Push-Benachrichtigungs-Service-Worker, der Nachrichten dafür empfängt. Und die VAPID-Schlüssel, die Ihre sendende Plattform besitzt. Das Abonnement wird unter dem öffentlichen Schlüssel erstellt, und der Push-Dienst akzeptiert eine Sendung nur, wenn sie mit dem übereinstimmenden privaten Schlüssel authentifiziert ist. Ihre Plattform beweist bei jeder Sendung, dass sie das Schlüsselpaar besitzt; der Abonnementdatensatz selbst enthält nur die öffentliche Hälfte.
Der Browser erzwingt auch ein Abonnement pro Ursprung. Ein erneuter Aufruf von subscribe mit einem anderen Anwendungsserver-Schlüssel schlägt fehl, bis das vorhandene Abonnement entfernt wird. Diese Einschränkung ist später wichtig, wenn wir zur Konsolidierung kommen: Auf demselben Ursprung kann ein neuer Service Worker lautlos einen vorhandenen Abonnenten übernehmen. Über Ursprünge hinweg kann er das niemals.
Was eine Domainmigration bei Web Push kaputt macht (und was nicht)
Hier ist der Teil, den die meisten Teams bei einer Domainmigration falsch machen: Sie gehen davon aus, dass die alte Liste stirbt. Das tut sie nicht. Abonnenten, die sich auf der alten Domain angemeldet haben, erhalten weiterhin Ihre Benachrichtigungen.
Die Zustellung berührt niemals Ihre Website. Wenn Sie senden, sendet Ihre Plattform eine Anfrage, die mit Ihren VAPID-Schlüsseln authentifiziert ist, an den Push-Dienst, der jedes Abonnement verwaltet (Google für Chrome, Mozilla für Firefox, Apple für Safari), und dieser Dienst liefert die verschlüsselte Nutzlast an den Service Worker, der bereits im Browser des Abonnenten installiert ist. Die alte Domain kann umgeleitet, geparkt oder vollständig verschwunden sein. Die Benachrichtigung kommt trotzdem an.
Das Klickziel gehört ebenfalls Ihnen. Klick-URLs werden pro Kampagne festgelegt, sodass ein Abonnent, der sich vor zwei Jahren auf einer von Ihnen eingezogenen Domain angemeldet hat, die Benachrichtigung von heute anklicken und auf der heutigen Live-Website landen kann.
| Nach einer Domainänderung | Funktioniert immer noch? |
|---|---|
| Zustellung an bestehende Abonnenten | Ja – Pushes werden über die Push-Dienste der Browseranbieter geleitet, nicht über Ihre Website |
| Klickziel | Ja – die Klick-URL wird pro Kampagne festgelegt; richten Sie sie auf die aktuelle Domain |
| Abonnenten der alten Herkunft treten automatisch der Liste der neuen Domain bei | Nein – die Berechtigung gilt pro Herkunft, daher ist die Teilnahme an der neuen Liste eine neue Opt-in-Anmeldung |
| Neue Anmeldungen auf der alten Herkunft | Nein – und das ist der Verlust, der sich vervielfacht |
Eine Domainmigration kostet Sie also nicht die Abonnenten, die Sie haben. Sie kostet Sie die Maschine, die sie produziert hat. An dem Tag, an dem der Traffic wechselt, beginnt die Erfassung von Anmeldungen auf der neuen Domain wieder bei Null, während die alte Liste langsam verfällt. Wenn Sie das über ein Portfolio von Marken laufen lassen, zahlt jede Eigenschaft diese Zurücksetzungssteuer unabhängig.
Die wahren Kosten: Jede neue Domain beginnt ihre Liste bei Null
Fragmentierte Erfassung wäre in einem Kanal mit geringer Abwanderung ärgerlich. Wetten ist kein Kanal mit geringer Abwanderung. Auf Wett- und Glücksspielseiten auf PushEngage wurden in einem 90-Tage-Fenster durch Abmeldungen etwa 91 % der neuen Abonnentengewinnung im Segment ausgelöscht. Eine Liste in dieser Branche ist eine Badewanne mit offenem Abfluss; das Einzige, was den Pegel hält, ist der ständig laufende Wasserhahn.
Fragmentierung schaltet den Wasserhahn ab, eine Eigenschaft nach der anderen. Die Liste jeder Marke wächst nur, solange diese spezielle Domain Opt-ins verdient. Eine Migration setzt ihren Wasserhahn auf Null zurück. Ein neues White-Label beginnt bei Null. In der Zwischenzeit laufen die Browser weiter ab: Chromes automatische Widerrufung der Berechtigung, angekündigt im Oktober 2025, entfernt stillschweigend die Benachrichtigungsberechtigung von Websites mit sehr geringem Engagement und hohem Benachrichtigungsvolumen. Eine Liste, die nicht erfasst, ist nicht flach. Sie schrumpft.
Der CAC-Rahmen macht die Einsätze deutlich. Sie haben für die Akquise jedes einzelnen dieser Besucher bezahlt, und die Opt-in-Anmeldung ist das einzige dauerhafte Retargeting-Asset, das der Besuch hinterlässt. Der Fall für Push in dieser Branche beruht auf der Kumulation dieses Assets. Fragmentierung schreibt jedes Mal einen Teil davon ab, wenn sich eine Domain ändert.
Die Stable-Origin-Architektur: eine Abonnement-Domain für jede Marke
Die Lösung besteht darin, überhaupt keine Abonnements mehr auf Markendomains zu erstellen. Verankern Sie jedes Abonnement an einem einzigen stabilen HTTPS-Ursprung, den Ihre Gruppe kontrolliert, einem, der jede einzelne Markendomain überdauert, und lassen Sie jede Eigenschaft ihn speisen.
PushEngage liefert dies als den benutzerdefinierten Subdomain-Flow, der genau für diesen Fall entwickelt wurde: mehrere Domains, die eine einheitliche Abonnentenverwaltung unter einer kontrollierten Domain benötigen. Die Einrichtung:
- Wählen Sie einen stabilen, markenneutralen Ursprung, den Sie besitzen, z. B.
notify.yourbrandgroup.com. Wählen Sie einen Namen, den Abonnenten sehen sollen, da Browser den abonnierenden Ursprung auf Benachrichtigungen anzeigen. - Laden Sie die PushEngage Service Worker-Datei in das Stammverzeichnis dieser Domain hoch und aktivieren Sie die Funktion unter Site Settings » Advanced Settings. Der stabile Ursprung erhält seinen eigenen Installations-Snippet mit
isSubscriptionOnSubDomain: true. - Fügen Sie den PushEngage-Snippet zu jeder Markendomain hinzu. Wenn ein Besucher auf einer dieser Domains zustimmt, wird der Flow über den stabilen Ursprung geleitet, wo das eigentliche Abonnement erstellt wird.
Zwei Anforderungen sind in diesem Modus nicht verhandelbar. Erstens ist die Zustimmung nur zweistufig möglich: Die Berechtigungsaufforderung des Browsers muss auf dem Ursprung ausgelöst werden, dem das Abonnement gehört. Daher ist ein einstufiger nativer Prompt auf der Markendomain nicht möglich. Zweitens bleibt Quick Install aktiviert.
Seien Sie ehrlich über den Kompromiss. Zweistufig fügt einen Klick vor der Berechtigungsaufforderung hinzu und konvertiert im Moment der Erfassung geringer. Es lohnt sich, neben den allgemeineren Hebeln zum Erhöhen Ihrer Opt-in-Rate gelesen zu werden. Aber ein einstufiger Abonnent, der auf einer Domain erfasst wird, von der Sie sich später weg migrieren, ist ein abwertendes Gut. Ein zweistufiger Abonnent auf dem stabilen Ursprung überlebt jede Rebranding, jede regionale Einführung, jede Migration, die Sie jemals durchführen werden. Über jeden Horizont, der eine Domainänderung beinhaltet, gewinnt die konsolidierte Liste beim Gesamtreichweite.
Push-Benachrichtigungen für mehrere Websites, eine Abonnentenliste
Sobald der stabile Ursprung vorhanden ist, bedeuten Push-Benachrichtigungen für mehrere Websites keine mehreren Listen mehr. Jede Markendomain speist denselben Abonnentenstamm. Die Einführung einer neuen regionalen Domain oder eines White-Labels im nächsten Quartal bedeutet, den Snippet hinzuzufügen; seine Opt-ins landen vom ersten Tag an in der konsolidierten Liste. Die Stilllegung einer Domain bedeutet, dass mit der Liste überhaupt nichts passiert: Die Erfassung wird auf den überlebenden Eigenschaften fortgesetzt, die Zustellung erfolgt weiterhin über die Push-Dienste und die Klick-URLs zeigen dorthin, wo Sie gerade live sind.
Konsolidierung der bereits fragmentierten Abonnentenlisten
Die meisten Betreiber erreichen diese Architektur mit einer Geschichte: Live-Listen, die über alte Domains verstreut sind, einige ruhend, einige bei einem anderen Anbieter. Die Konsolidierung läuft parallel auf drei Spuren.
| Spur | Was Sie tun | Was es Ihnen bringt |
|---|---|---|
| 1. Alte Listen am Laufen halten | Senden Sie weiterhin an jede alte Ursprungsliste; richten Sie Klick-URLs auf die aktuelle Live-Domain | Bezahlte Reichweite produziert weiterhin Sitzungen, anstatt abgeschrieben zu werden |
| 2. Neue auf dem stabilen Ursprung erfassen | Schalten Sie die Zustimmung jeder Live-Eigenschaft auf den stabilen Ursprungs-Flow um | Die Fragmentierung stoppt am Tag des Versands; die gesamte neue Akquisition landet in einer Liste |
| 3. Lassen Sie alte Listen sich selbst auffüllen | Jeder Versand an eine alte Liste führt zu einem erneuten Besuch einer aktuellen Domain, wo die Aufforderung zum stabilen Ursprung wartet | Aktive Abonnenten konsolidieren sich, keine erzwungene erneute Zustimmung |
Track 3 ist das stille Arbeitstier. Die Browser-Berechtigung ist pro Ursprung, daher benötigen Abonnenten mit altem Ursprung technisch gesehen eine neue Opt-in-Bestätigung, um der konsolidierten Liste beizutreten, aber Sie müssen diese niemals anfordern. Angesichts der schnellen Fluktuation von Wettpublikum wird die konsolidierte Liste innerhalb weniger Monate zur Mehrheit Ihrer aktiven Reichweite, einfach weil aktive Spieler immer wieder vorbeischauen.
Wenn einige Fragmente bei einem anderen Push-Anbieter auf einer Domain leben, die Ihnen gehört, können sie auch mitkommen. Der Standardpfad von PushEngage ist ein stilles erneutes Abonnieren: Beim nächsten Besuch eines Abonnenten übernimmt der Push-Benachrichtigungs-Service-Worker des SDK und abonniert sie erneut, ohne eine zweite Zustimmungsaufforderung, da die ursprungsbezogene Berechtigung bestehen bleibt. Für OneSignal kann PushEngage die Liste direkt über die API von OneSignal abrufen. Die Migration ist "white-glove" und auf kostenpflichtigen Plänen kostenlos.
Kampagnen pro Marke innerhalb einer konsolidierten Liste
Eine Liste bedeutet nicht eine Nachricht. Sie bedeutet ein Asset mit besserer Zielgruppenansprache, als es vier Fragmente jemals verwalten könnten.
Erfassen Sie die ursprüngliche Marke als Abonnentenattribut bei der Opt-in-Bestätigung, und Kohorten pro Marke existieren vom ersten Tag an. Von dort aus leistet die Segmentierung, was separate Listen niemals konnten: Marke gekreuzt mit Geografie, Einzahlungsverhalten, Aktualität der Sitzung oder Ligapräferenz. Das ist das Modell, das #1 im Playbook für Push-Benachrichtigungen für Wettseiten darlegt. Die Flaggschiff-Kampagne mit Quoten-Boost geht an die Wettspieler des Flaggschiffs; die Cashback-Erinnerung des Casino-White-Labels geht an seine Spieler; eine portfolio-weite Spielplan-Benachrichtigung geht an alle, die der Liga folgen, unabhängig davon, unter welcher Marke sie sich angemeldet haben.
Der Vorteil ist nicht kosmetisch. Auf Wettseiten mit PushEngage erzielt der durchschnittliche Absender von Wettseiten eine Klickrate von ca. 2,1 % bei angesehenen Benachrichtigungen; das oberste Dezil erreicht 6,9 % – etwa das Dreifache. Dieser Unterschied ist eine Lücke in der Zielgruppenansprache, keine Lücke im Kanal, und Sie können keine Verhaltenskohorten über vier getrennte Fragmente hinweg aufbauen. Konsolidierung ist das, was Segmentierung als Zustellbarkeitspraxis im Portfolio-Maßstab praktikabel macht. Das ist umso wichtiger, da Chrome jeden Sendeursprung täglich bewertet und störende Absender drosselt (seit Januar 2026 aktiv). Ein stabiler Ursprung konzentriert Ihre Absender-Reputation; segmentierte, relevante Sendungen halten diese gesund.
Eine Liste vereinfacht auch den Betrieb von verantwortungsvollem Glücksspiel, und das ist ein Merkmal, keine Fußnote. Ein selbst ausgeschlossener Spieler, der in einem portfolio-weiten Segment unterdrückt wird, ist überall gleichzeitig unterdrückt, nicht markenweise, wo ein Fragment durchrutschen kann. Ruhezeiten und Frequenzgrenzen gelten auf Abonnenten-Ebene für die Kampagnen jeder Marke. Und die Kampagnen selbst sollten die Linie halten: kein "Win-Back" rund um das Jagen von Verlusten, kein Countdown-Druck bei Einzahlungsaufforderungen.
Web-Push über mehrere Domains hinweg ausführen, ohne Ihre Liste aufzuteilen
Das gesamte Setup ist kleiner, als es klingt: ein DNS-Eintrag für den stabilen Ursprung, die Service-Worker-Datei in dessen Stammverzeichnis, der Schalter in den erweiterten Einstellungen, der isSubscriptionOnSubDomain-Snippet und der Standard-Snippet auf jeder Markendomäne mit zweistufiger Opt-in-Konfiguration und aktiviertem Quick Install. Teams liefern es normalerweise am selben Tag aus, ohne Re-Platforming. Das ist der gesamte Aufwand, um Push-Benachrichtigungen für mehrere Websites von einem Ursprung aus zu betreiben.
Was Sie zurückbekommen, ist die Sache, die Fragmentierung leise besteuert: eine Abonnentenliste, die sich ansammelt. Jede Marke speist sie, jede Domainänderung prallt von ihr ab, und jede Kampagne kann das gesamte Portfolio oder eine Marke gleichzeitig ansprechen. Wenn Sie die Mechanik anhand Ihrer eigenen Domain-Map sehen möchten, beginnen Sie mit der Web-Push-Benachrichtigungs-Funktionsübersicht und den Preisplänen. Bezahlte Pläne beinhalten eine 14-tägige Geld-zurück-Garantie, sodass die Architektur sich mit Ihrem Traffic beweisen kann, bevor die Entscheidung endgültig ist.
