Sie haben Ihre Liste von Push-Abonnenten mühsam durch einzelne Opt-ins aufgebaut, und jedes Opt-in hat echte Akquisitionskosten verursacht. Wenn es also an der Zeit ist, den Anbieter für Push-Benachrichtigungen zu wechseln, ist die Angst spezifisch: Kündigen Sie den alten Vertrag und die Liste verschwindet damit. Ihr aktueller Anbieter wird Ihnen vielleicht sogar genau das sagen.
Das stimmt nicht, und dieser Leitfaden zeigt Ihnen, warum auf Browser-Ebene. Ein Web-Push-Abonnement ist an Ihre Domain gebunden, nicht an Ihren Anbieter. Sobald Sie die Mechanik verstehen, löst sich jeder Wechsel in eines von zwei klaren Szenarien auf, eine kurze Liste von schriftlichen Fragen für Ihren aktuellen Anbieter und eine einwöchige Checkliste, die Ihr Team ohne Probleme durchführen kann.
Eine ehrliche Anmerkung vorab. Jedes Verkaufsteam eines Anbieters, auch unseres, wird Ihnen sagen, dass die Migration einfach ist. Die meisten hören dort auf. Dieser Beitrag zeigt Ihnen stattdessen den Mechanismus, damit Ihr Entwickler jede Behauptung überprüfen kann, auch die, die wir am Ende aufstellen.
Was ein Web-Push-Abonnement tatsächlich ist
Wenn ein Besucher auf Ihrer Website auf „Zulassen“ klickt, erstellt der Browser ein Web-Push-Abonnement, das auf drei Teilen basiert:
- Ihr Ursprung. Die genaue Domain, auf der die Berechtigung erteilt wurde (
https://ihreseite.com). Die Berechtigung lebt im Browser und ist an den Ursprung gebunden. Sie erwähnt keinen Anbieter. - Ein Service Worker. Eine kleine JavaScript-Datei, die auf Ihrer Domain gehostet wird und Benachrichtigungen empfängt und anzeigt. Welcher Service Worker registriert ist, steuert die Zustellung.
- Ein Anwendungsserver-Schlüssel. Die öffentliche Hälfte eines VAPID-Schlüsselpaars. Der Push-Dienst des Browsers akzeptiert nur Sendeanfragen, die mit dem passenden privaten Schlüssel signiert sind. Wer diesen privaten Schlüssel besitzt, kann die Nachricht an das Abonnement senden. (Die Übersicht über Push-Benachrichtigungen von web.dev behandelt das vollständige Protokoll.)
Der Abonnementdatensatz selbst besteht aus drei Zeichenfolgen: einer Endpunkt-URL sowie zwei kurzen Schlüsseln, p256dh und auth. Das ist das gesamte Asset. Ihre gesamte Liste ist eine Tabelle dieser Datensätze.
Eine Regel entscheidet über alles Weitere: Browser akzeptieren Sendeanfragen nur vom Inhaber des passenden privaten VAPID-Schlüssels. Das bedeutet, dass jeder Anbieterwechsel in genau zwei Szenarien mündet, je nachdem, wo sich diese Schlüssel befinden.
Szenario A: Ihre VAPID-Schlüssel werden übernommen, sodass Sie Push-Abonnenten am ersten Tag importieren
Szenario A gilt, wenn die Schlüssel Ihnen gehören: Sie haben Ihre eigenen VAPID-Schlüssel oder Ihr eigenes Firebase-Projekt bei der Einrichtung konfiguriert, oder Ihr abgehender Anbieter stimmt zu, das Schlüsselpaar zu übergeben. Einige Teams richten dies von Anfang an bewusst ein; der Ansatz wird in unserem Leitfaden zur Implementierung von Web-Push ohne Vendor-Lock-in behandelt.
Mit dem Private Key in der Hand kann Ihr neuer Anbieter Push-Abonnenten direkt importieren: jeder Endpunkt, p256dh und auth Datensatz wird übertragen, und Sie können Ihre gesamte bestehende Liste vom ersten Tag an ansprechen. Das schließt ruhende Abonnenten ein, die seit Monaten nicht mehr besucht haben. Niemand muss sich erneut anmelden. Niemand bemerkt es.
Eine Nuance, die klar gesagt werden sollte. Selbst in Szenario A wird die dauerhafte Migration durch Wiederbesuche abgeschlossen, da jeder Abonnent schließlich auf dem neuen Service Worker landen muss. Die importierten Schlüssel verschaffen Ihnen Reichweite am ersten Tag, während dieser Übergang leise im Hintergrund abläuft.
Szenario B: Schlüssel bleiben zurück, und die stille Neuabonnement übernimmt
Szenario B ist die übliche Standardeinstellung: Der Anbieter hat die VAPID-Schlüssel generiert und behält sie. Ohne den Private Key sind exportierte Datensätze kryptografisch nutzlos. Die Reichweite am ersten Tag ist null, und die Warnung Ihres alten Anbieters klingt noch etwa einen Absatz lang wahr.
Hier ist, was tatsächlich passiert. Wenn jeder Abonnent Ihre Website das nächste Mal besucht, übernimmt der Service Worker des neuen Anbieters: Er registriert die alte Registrierung ab, kündigt das alte Abonnement und abonniert den Besucher unter den neuen Schlüsseln neu. Leise, in einem einzigen Besuch, ohne eine zweite Berechtigungsaufforderung.
Warum der neue Service Worker keine zweite Aufforderung benötigt
Die Benachrichtigungsberechtigung wird Ihrem Ursprung erteilt, nicht einem Anbieter. Der Browser vertraut bereits Ihrer Domain. Das Austauschen des Service Workers und der Schlüssel unter einer bereits erteilten Berechtigung ist für den Besucher unsichtbar, da der Browser dies als Umstrukturierung der eigenen Infrastruktur Ihrer Website behandelt. Genau das ist es auch.
Zwei Fallen, die Ihr Entwickler kennen sollte
Ein Ursprung, ein Abonnement. Ein Browser kann nicht zwei Push-Abonnements für denselben Ursprung speichern. Das Abonnieren mit einem anderen Schlüssel schlägt fehl, bis das alte Abonnement freigegeben ist. Daher funktioniert „beide Anbieter parallel betreiben“ auf Listenebene, aber niemals innerhalb eines einzelnen Browsers: Jeder Abonnent ist entweder beim alten oder beim neuen Anbieter, und jeder Wiederbesuch verschiebt einen weiteren.
Opt-ins für Anbieter-Subdomains werden nie übertragen. Abonnements, die auf yoursite.vendor.com gesammelt wurden, gehören zum Ursprung des Anbieters, und kein Anbieter kann sie migrieren. Diese Basis muss von Grund auf neu aufgebaut werden. Dies ist die größte Falle bei jeder Push-Benachrichtigungs-Migration und das stärkste Argument dafür, Abonnements diesmal an eine Domain zu binden, die Sie kontrollieren. Wenn Sie mehrere Marken oder regionale Domains betreiben, formt dieselbe Ursprungslogik Ihre gesamte Architektur; wir behandeln dies in Web Push über mehrere Domains hinweg.
Hier sind die beiden Szenarien nebeneinander:
| Szenario A: Schlüssel reisen mit | Szenario B: Schlüssel bleiben zurück | |
|---|---|---|
| Wann es zutrifft | Eigene VAPID-Schlüssel / eigenes Firebase-Projekt oder der Anbieter gibt das Paar frei | Vom Anbieter generiert und behalten (die übliche Standardeinstellung) |
| Reichweite am ersten Tag | Ihre gesamte Liste, einschließlich ruhender Abonnenten | Null, bis Besucher zurückkehren |
| Bei jedem Wiederbesuch | Abonnent wechselt leise zu den neuen Schlüsseln | Stille Neuabonnement unter den neuen Schlüsseln, keine zweite Aufforderung |
| Wen Sie zurückgewinnen | Alle | Alle, die wieder besuchen |
| Wen Sie verlieren | Niemand | Abonnenten, die nie zurückkehren (die sowieso keine erreichbaren Einnahmen mehr waren) |
Warum Zielgruppen mit täglichen Besuchen die Migration von Push-Benachrichtigungen am schnellsten abschließen
In Szenario B ist die Übernahmeuhr die Rückkehrhäufigkeit Ihrer Zielgruppe. Nichts anderes. Ein E-Commerce-Abonnent besucht vielleicht monatlich, daher erstreckt sich die Übernahme über Monate. Ein Wettender prüft täglich Quoten, Linien und Ergebnisse. Ein Nachrichtenleser kehrt zu jedem Schlagzeilenzyklus zurück.
Dieser Rückkehrrhythmus ist der Grund, warum Wett- und Nachrichtenseiten die am besten positionierten Vertikalen im Internet sind, um Push-Benachrichtigungsanbieter zu wechseln: Die gleiche Besuchsfrequenz, die Push-Benachrichtigungen für Wettseiten zu einer Retention-Engine macht, komprimiert auch eine Migration, die für andere Seiten ein Quartal dauert, auf ein oder zwei Wochen. Wett- und Glücksspielseiten auf PushEngage haben über 3,5 Milliarden Benachrichtigungen gesendet, daher sind diese Übernahmemchanismen für uns tägliche Produktionsrealität, keine Theorie.
| Muster des Zielgruppenrückkehrverhaltens | Typische Übernahme der aktiven Basis |
|---|---|
| Tägliche Besucher (Live-Quoten, Eilmeldungen, tägliche Aktionen) | Tage bis etwa eine Woche |
| Mehrere Besuche pro Woche (Wettende am Wochenende, Stammkunden) | 1–2 Wochen |
| Wöchentlich oder seltener (saisonale Besucher, abgewanderte Nutzer) | Wochen, beschleunigt durch alte Anbieter-Sendungen und Großveranstaltungen |
| Inaktiv (kein Besuch seit Monaten) | Nur unter Szenario A wiederherstellbar |
Dies sind typische Muster für Zielgruppen mit täglichen Besuchen, keine Garantien; Ihre Kurve hängt von Ihrem Traffic-Rhythmus ab und Sie werden sie im Dashboard live beobachten. Sie können die Kurve auch beeinflussen: Planen Sie den Übergang für die Woche vor einem wichtigen Spielwochenende und der Traffic der Veranstaltung übernimmt für Sie. Sportwettenanbieter, die eine Match-Day-Push-Sequenz planen, wissen bereits, welche Wochenenden das sind.
App-Push ist einfacher: Ihre Tokens gehörten Ihnen schon immer
Wenn Sie auch App-Push-Nachrichten senden, atmen Sie tief durch. Dieser Teil ist strukturell einfach, da kein Anbieter ihn als Geisel nehmen kann.
APNs-Zertifikate und Schlüssel werden Ihrem Apple Developer-Konto zugeordnet. Ihr FCM-Projekt lebt in Ihrer Google-Konsole. Ein Push-Anbieter ist eine Schicht über den Anmeldeinformationen, die Ihnen gehören. Ein Wechsel bedeutet also, eine neue Schicht auf dieselben Anmeldeinformationen zu verweisen. Geräte-Tokens werden sauber exportiert und importiert, ohne Neuinstallationen und ohne eine zweite Berechtigungsaufforderung.
Zwei praktische Hinweise. Erstens, filtern Sie Token-Exporte auf Geräte, die ungefähr 270 Tage aktiv waren, bevor Sie sie importieren, da FCM Tokens, die länger als ca. 270 Tage inaktiv sind, als veraltet behandelt. Ein Dump von Fünfjahres-Tokens bläht Ihre Abonnentenzahl auf, und bei Preismodellen, die nur aktive Abonnenten zählen, profitiert niemand davon. Zweitens, die vollständige SDK-Abdeckung erfolgt mit der Geschwindigkeit, mit der Benutzer Ihre App aktualisieren, typischerweise ein bis zwei Wochen für eine tägliche App mit automatischen Updates.
Wenn Ihre iOS-App derzeit über Firebase sendet, ist der Schritt-für-Schritt-Ablauf ein eigenes Thema; siehe unseren Leitfaden zur Migration von Firebase Cloud Messaging unter iOS, anstatt ihn aus diesem Beitrag zu improvisieren.
Bevor Sie Push-Benachrichtigungsanbieter wechseln, stellen Sie diese sechs Fragen schriftlich
Anbieter-Export und Schlüsselrichtlinien variieren und ändern sich. Anstatt einer Tabelle von Anbieter-Urteilen zu vertrauen (einschließlich einer, die wir veröffentlichen könnten), holen Sie sich die Antworten Ihres eigenen Anbieters zu Protokoll. E-Mail funktioniert; ein Support-Ticket funktioniert besser. Wenn Sie gleichzeitig Ziele bewerten, sind dieselben Fragen ein nützliches Mittel, um Alternativen zu OneSignal zu vergleichen.
- Können Sie meine vollständigen Web-Push-Abonnementdatensätze exportieren – Endpunkt-URL sowie die
p256dh- undauth-Schlüssel für jeden Abonnenten – oder nur interne IDs? Interne IDs sind außerhalb des Systems des Anbieters bedeutungslos. - Werden Sie das VAPID-Schlüsselpaar veröffentlichen, unter dem meine Abonnements erstellt wurden? Diese eine Antwort entscheidet über Szenario A gegenüber Szenario B.
- Auf welchem FCM- oder Firebase-Projekt läuft mein Web-Push, auf meinem oder Ihrem? Wenn es Ihres ist, befinden sich die Schlüssel möglicherweise bereits in Ihrer eigenen Konsole.
- Kann ich Segmente, Tags, Abonnentenattribute und Unterdrückungslisten separat exportieren? Sie werden nicht automatisch mit den Abonnementdatensätzen mitgeführt.
- Kann ich die Push-Geräte-Tokens meiner App exportieren und in welchem Format?
- Was passiert mit meinen Daten, wenn ich herabstufen oder kündigen – gibt es eine automatische Löschung oder ein Aufbewahrungsfenster? Einige Anbieter löschen inaktive Abonnentendaten in niedrigeren Stufen. Exportieren Sie immer zuerst.
Die Checkliste für die Migrationswoche
Drucken Sie diesen Abschnitt. Acht Schritte in der richtigen Reihenfolge.
- Exportieren Sie alles, bevor Sie etwas herabstufen oder kündigen. Abonnementdatensätze, App-Tokens, Segmente, Tags, Attribute, Unterdrückungslisten. Der Exportzugriff erlischt mit Ihrem Vertrag.
- Holen Sie sich die Antwort zu den VAPID-Schlüsseln schriftlich. Sie entscheidet über Ihr Szenario und ob Sie Push-Abonnenten am ersten Tag importieren können.
- Verschieben Sie zuerst die Unterdrückungslisten, nicht zuletzt. Für Wett- und Glücksspielanbieter ist dies nicht verhandelbar: selbst ausgeschlossene Spieler müssen auf der neuen Plattform unterdrückt werden, bevor eine einzige Kampagne wieder aufgenommen wird, nicht nachträglich abgeglichen werden.
- Filtern Sie App-Tokens vor dem Import auf ca. 270 Tage Aktivität.
- Installieren Sie das neue SDK und den Service Worker und führen Sie ihn mit einem vorhandenen Service Worker zusammen (einer PWA-Shell, dem Worker des alten Anbieters), anstatt ihn zu überschreiben.
- Löschen Sie nicht den Service Worker des alten Anbieters am ersten Tag. Wiederkehrende Besucher haben immer noch Registrierungen, die darauf verweisen; die Übernahme deregistriert sie ordnungsgemäß. Wenn Sie die Datei zu früh entfernen, erzeugen Sie Konsolenfehler anstelle von Migrationen. Entfernen Sie sie beim endgültigen Abbau.
- Lassen Sie den alten Anbieter während des parallelen Fensters weiter senden. Kontraintuitiv, aber entscheidend: Jede Benachrichtigung, die der alte Anbieter sendet, führt zu einem erneuten Besuch, und jeder erneute Besuch schließt die Migration eines weiteren Abonnenten ab. Ihr abgehender Anbieter wird zu Ihrem besten Migrationswerkzeug.
- Messen Sie die Übernahme täglich und wechseln Sie am Plateau. Verfolgen Sie die neue aktive Basis im Vergleich zur alten aktiven Basis. Wenn sich die Kurve abflacht, beenden Sie den Abbau, kündigen Sie den alten Vertrag und archivieren Sie die Exporte.
Was der Wechsel kostet, wenn PushEngage ihn für Sie übernimmt
Bei PushEngage ist die Migration ein kostenloser White-Glove-Service, der in bezahlten Tarifen enthalten ist. Sie erhalten einen Migrationsingenieur, keinen Hilfeartikel: Er kümmert sich um das Export-Mapping, die Schlüsselverwaltung, die Zusammenführung des Service-Workers und den Übernahmeplan. Das ist wichtig, denn die Ausfallmodi sind subtil – ein einfacher Import mit falsch zugeordneten Payload-Formaten kann technisch erfolgreiche, aber leere Benachrichtigungen liefern, was genau die Art von stillem Fehler ist, die ein Spezialist erkennt, bevor Ihre Abonnenten es tun.
Das Scoping-Gespräch dauert etwa fünfzehn Minuten: Abonnentenzahlen pro Kanal, aktueller Anbieter und die oben genannten Schlüsselthemen. Am Ende wissen Sie, ob Sie Szenario A oder B sind, und Sie haben einen datierten Plan.
Wenn Sie bereit sind, den Anbieter für Push-Benachrichtigungen zu wechseln, beginnen Sie mit den sechs schriftlichen Fragen in diesem Beitrag und sehen Sie, wie Ihr aktueller Anbieter antwortet. Betrachten Sie dann, was eine Web-Push-Benachrichtigungsplattform, die auf Segmentierung und Umsatzzuordnung aufgebaut ist, mit der Liste tun würde, die Sie bereits besitzen, und vergleichen Sie die PushEngage-Preise mit Ihrer aktuellen Rechnung. Jeder bezahlte Tarif beinhaltet eine 14-tägige Geld-zurück-Garantie, sodass die Push-Benachrichtigungs-Migration selbst der risikoärmste Teil der Entscheidung ist.
