U hebt uw lijst met push-abonnees één voor één opgebouwd met moeilijke opt-ins, en elke opt-in kostte echt geld voor acquisitie. Dus als het tijd is om van provider voor pushmeldingen te wisselen, is de angst specifiek: zeg het oude contract op en de lijst verdwijnt ermee. Uw huidige leverancier kan u zelfs precies dat vertellen.
Het is niet waar, en deze gids laat u zien waarom op browseniveau. Een abonnement op web pushmeldingen is gekoppeld aan uw domein, niet aan uw leverancier. Zodra u de mechanismen ziet, wordt elke wisseling opgelost in een van de twee duidelijke scenario's, een korte lijst met schriftelijke vragen voor uw huidige leverancier, en een checklist van een week die uw team zonder drama kan uitvoeren.
Eerlijke opmerking vooraf. Het verkoopteam van elke leverancier, inclusief het onze, zal u vertellen dat migratie eenvoudig is. De meesten stoppen daar. Deze post toont u in plaats daarvan het mechanisme, zodat uw ontwikkelaar elke bewering kan verifiëren, inclusief de beweringen die wij aan het einde doen.
Wat een abonnement op web pushmeldingen werkelijk is
Wanneer een bezoeker op uw site op "Toestaan" klikt, maakt de browser een abonnement op web pushmeldingen dat is opgebouwd uit drie delen:
- Uw oorsprong. Het exacte domein waarop de toestemming is verleend (
https://uwsite.com). De toestemming leeft in de browser, gekoppeld aan de oorsprong. Er wordt geen leverancier vermeld. - Een service worker. Een klein JavaScript-bestand dat op uw domein wordt gehost en meldingen ontvangt en weergeeft. Welke service worker is geregistreerd, regelt de levering.
- Een applicatieserver-sleutel. De publieke helft van een VAPID-sleutelpaar. De pushservice van de browser accepteert alleen verzendingen die zijn ondertekend met de bijbehorende privésleutel. Wie die privésleutel bezit, kan de melding naar het abonnement sturen. (web.dev's overzicht van pushmeldingen behandelt het volledige protocol.)
Het abonnement zelf bestaat uit drie strings: een endpoint-URL plus twee korte sleutels, p256dh en auth. Dat is het volledige bezit. Uw hele lijst is een tabel met die records.
Eén regel bepaalt alles wat daarna komt: browsers accepteren verzendingen alleen van de houder van de bijbehorende VAPID-privésleutel. Wat betekent dat elke leverancierswissel wordt opgelost in precies twee scenario's, afhankelijk van waar die sleutels zich bevinden.
Scenario A: uw VAPID-sleutels reizen mee, dus u importeert push-abonnees op dag één
Scenario A is van toepassing wanneer de sleutels van u zijn om mee te nemen: u hebt uw eigen VAPID-sleutels of uw eigen Firebase-project geconfigureerd bij de installatie, of uw uitgaande leverancier stemt ermee in het sleutelpaar over te dragen. Sommige teams hebben dit vanaf dag één bewust ingesteld; de aanpak wordt behandeld in onze gids voor het implementeren van web push zonder vendor lock-in.
Met de privésleutel bij de hand kan uw nieuwe provider push-abonnees rechtstreeks importeren: elk eindpunt, p256dh en auth record wordt overgezet, en u kunt uw hele bestaande lijst vanaf dag één berichten. Dat omvat ook slapende abonnees die al maanden niet meer zijn langsgekomen. Niemand meldt zich opnieuw aan. Niemand merkt het.
Eén nuance die duidelijk moet worden vermeld. Zelfs in Scenario A voltooit de duurzame migratie nog steeds via herbezoeken, omdat elke abonnee uiteindelijk op de nieuwe service worker moet landen. De geïmporteerde sleutels geven u bereik op dag één terwijl die overgang geruisloos op de achtergrond plaatsvindt.
Scenario B: sleutels blijven achter en de stille herabonnering neemt het over
Scenario B is de gebruikelijke standaard: de leverancier heeft de VAPID-sleutels gegenereerd en bewaart ze. Zonder de privésleutel zijn geëxporteerde records cryptografisch nutteloos. Bereik op dag één is nul, en de waarschuwing van uw oude leverancier klinkt nog ongeveer één alinea waar.
Dit is wat er werkelijk gebeurt. De volgende keer dat een abonnee uw site bezoekt, neemt de service worker van de nieuwe provider het over: deze deactiveert de oude registratie, deactiveert het oude abonnement en herabonneert de bezoeker onder de nieuwe sleutels. Geruisloos, tijdens één bezoek, zonder een tweede toestemmingsprompt.
Waarom de nieuwe service worker geen tweede prompt nodig heeft
Meldingsmachtigingen worden verleend aan uw oorsprong, niet aan een leverancier. De browser vertrouwt uw domein al. Het onder de reeds verleende machtiging wisselen van service worker en sleutels is onzichtbaar voor de bezoeker, omdat de browser dit behandelt als uw site die zijn eigen infrastructuur reorganiseert. Dat is precies wat het is.
Twee valkuilen waar uw ontwikkelaar van op de hoogte moet zijn
Eén oorsprong, één abonnement. Een browser kan niet twee push-abonnementen voor dezelfde oorsprong aanhouden. Abonneren met een andere sleutel mislukt totdat het oude abonnement is vrijgegeven. Dus "draai beide leveranciers parallel" werkt op lijstniveau, nooit binnen één browser: elke abonnee zit bij de oude of de nieuwe leverancier, en elk herbezoek verplaatst er weer één.
Opt-ins van leveranciers-subdomeinen verhuizen nooit. Abonnementen verzameld op yoursite.vendor.com behoren tot de oorsprong van de leverancier, en geen enkele provider kan ze migreren. Dat deel wordt vanaf nul opgebouwd. Het is de grootste valkuil bij elke migratie van pushmeldingen, en het sterkste argument om abonnementen deze keer te koppelen aan een domein dat u beheert. Als u meerdere merken of regionale domeinen beheert, vormt dezelfde oorspronglogica uw hele architectuur; we behandelen dit in webpush via meerdere domeinen.
Hier zijn de twee scenario's naast elkaar:
| Scenario A: sleutels reizen mee | Scenario B: sleutels blijven achter | |
|---|---|---|
| Wanneer het van toepassing is | Eigen VAPID-sleutels / eigen Firebase-project, of de leverancier geeft het paar vrij | Leverancier heeft de sleutels gegenereerd en behoudt ze (de gebruikelijke standaard) |
| Bereik op dag 1 | Uw volledige lijst, inclusief slapende abonnees | Nul, totdat bezoekers terugkeren |
| Bij elk herbezoek | Abonnees verhuizen geruisloos naar de nieuwe sleutels | Stille herabonnering onder de nieuwe sleutels, geen tweede prompt |
| Wie u herovert | Iedereen | Iedereen die opnieuw bezoekt |
| Wie u verliest | Niemand | Abonnees die nooit terugkeren (die sowieso geen bereikbare inkomsten meer waren) |
Waarom doelgroepen die dagelijks bezoeken pushmeldingmigraties het snelst voltooien
In Scenario B is de overnamedrempel de retourfrequentie van uw doelgroep. Niets anders. Een e-commerce abonnee bezoekt mogelijk maandelijks, dus de overname strekt zich uit over maanden. Een gokker controleert dagelijks de odds, lijnen en resultaten. Een nieuwslezer komt terug voor elke nieuwsupdate.
Dat retourritme is waarom gok- en nieuwssites de best gepositioneerde verticals op internet zijn om pushmeldingsproviders te wisselen: dezelfde bezoekfrequentie die pushmeldingen voor goksites een retentie-engine maakt, comprimeert ook een migratie die andere sites een kwartaal kost, tot een week of twee. Gok- en game-sites op PushEngage hebben meer dan 3,5 miljard meldingen verzonden, dus deze overnamemechanismen zijn voor ons dagelijkse productiewerkelijkheid, geen theorie.
| Patroon van terugkerende doelgroep | Typische overname van actieve basis |
|---|---|
| Dagelijkse bezoekers (live odds, breaking news, dagelijkse promo's) | Dagen tot ongeveer een week |
| Meerdere bezoeken per week (weekendgokkers, vaste klanten) | 1–2 weken |
| Wekelijks of minder (seizoensgebonden bezoekers, inactieve gebruikers) | Weken, versneld door verzendingen van oude leveranciers en grote evenementen |
| Inactief (geen bezoek in maanden) | Alleen herstelbaar onder Scenario A |
Dit zijn typische patronen voor dagelijks bezoekende doelgroepen, geen garanties; uw curve hangt af van uw verkeersritme en u ziet deze live in het dashboard. U kunt de curve ook buigen: plan de overgang de week vóór een belangrijk sportevenement en het verkeer van het evenement doet de overname voor u. Sportsbooks die een wedstrijddag pushreeks plannen, weten al welke weekenden dat zijn.
App-push is eenvoudiger: uw tokens waren altijd van u
Als u ook app-push verzendt, haal diep adem. Dit deel is structureel eenvoudig, omdat geen enkele leverancier het als gijzelaar kan vasthouden.
APNs-certificaten en -sleutels worden uitgegeven aan uw Apple Developer-account. Uw FCM-project leeft in uw Google-console. Een pushleverancier is een laag bovenop de inloggegevens die u bezit, dus wisselen betekent een nieuwe laag koppelen aan dezelfde inloggegevens. Apparaattokens worden schoon geëxporteerd en geïmporteerd, zonder herinstallaties en zonder een tweede toestemmingsprompt.
Twee praktische opmerkingen. Ten eerste, filter export van tokens op apparaten die ongeveer 270 dagen actief zijn voordat u importeert, omdat FCM tokens die langer dan ~270 dagen inactief zijn als verouderd behandelt. Een dump van tokens van vijf jaar oud blaast uw abonneeaantal op, en bij prijzen die alleen actieve abonnees tellen, profiteert niemand daarvan. Ten tweede, volledige SDK-dekking komt met de snelheid waarmee gebruikers uw app updaten, meestal een week of twee voor een dagelijks gebruikte app met automatische updates.
Als uw iOS-app momenteel via Firebase verzendt, is de stapsgewijze workflow een apart onderwerp; zie onze gids voor migratie van Firebase Cloud Messaging op iOS in plaats van deze uit deze post te improviseren.
Voordat u van pushmeldingsprovider wisselt, stel deze zes vragen schriftelijk
Leveranciers-export en sleutelbeleid variëren en veranderen. In plaats van te vertrouwen op een tabel met leveranciersbeoordelingen (inclusief een die wij zouden kunnen publiceren), kunt u de antwoorden van uw eigen leverancier vastleggen. E-mail werkt; een supportticket werkt beter. Als u tegelijkertijd bestemmingen evalueert, zijn dezelfde vragen een nuttige screening tijdens het vergelijken van OneSignal-alternatieven.
- Kunt u mijn volledige web push-abonnementsgegevens exporteren — eindpunt-URL plus de
p256dh- enauth-sleutels voor elke abonnee — of alleen interne ID's? Interne ID's zijn betekenisloos buiten het systeem van de leverancier. - Zult u het VAPID-sleutelpaar vrijgeven waaronder mijn abonnementen zijn aangemaakt? Dit ene antwoord bepaalt Scenario A versus Scenario B.
- Op welk FCM- of Firebase-project draait mijn web push, het mijne of het uwe? Als het het uwe is, zijn de sleutels mogelijk al in uw eigen console aanwezig.
- Kan ik segmenten, tags, abonneekenmerken en onderdrukkingslijsten afzonderlijk exporteren? Ze worden niet automatisch meegevoerd met de abonnementsgegevens.
- Kan ik mijn app push-apparaattokens exporteren, en in welk formaat?
- Wat gebeurt er met mijn gegevens als ik downgrade of annuleer — is er een automatische verwijdering of een retentieperiode? Sommige leveranciers verwijderen inactieve abonnegegevens op lagere niveaus. Exporteer altijd eerst.
De checklist voor de migratieweek
Print deze sectie. Acht stappen, op volgorde.
- Exporteer alles voordat u iets annuleert of downgradet. Abonnementsgegevens, app-tokens, segmenten, tags, kenmerken, onderdrukkingslijsten. Toegang tot export vervalt met uw contract.
- Verkrijg het antwoord over de VAPID-sleutels schriftelijk. Het bepaalt uw scenario en of u push-abonnees op dag één kunt importeren.
- Verplaats onderdrukkingslijsten eerst, niet als laatste. Voor gok- en gamingoperators is dit niet-onderhandelbaar: zelf-uitgesloten spelers moeten op het nieuwe platform worden onderdrukt voordat een enkele campagne wordt hervat, niet achteraf worden verrekend.
- Filter app-tokens op ~270 dagen actief vóór import.
- Installeer de nieuwe SDK en service worker, en voeg deze samen met een bestaande service worker (een PWA-shell, de worker van de oude leverancier) in plaats van deze te overschrijven.
- Verwijder de service worker-bestand van de oude leverancier niet op dag één. Terugkerende bezoekers hebben nog steeds registraties die ernaar verwijzen; de overname de-registreert ze gracieus. Verwijder het bestand te vroeg en u genereert consolefouten in plaats van migraties. Verwijder het bij de definitieve afbouw.
- Laat de oude leverancier doorsturen gedurende het parallelle venster. Tegen-intuïtief maar cruciaal: elke melding die de oude leverancier verzendt, leidt tot een hernieuwd bezoek, en elk hernieuwd bezoek voltooit de migratie van nog een abonnee. Uw uitgaande leverancier wordt uw beste migratietool.
- Meet de overname dagelijks en schakel over bij het plateau. Volg de nieuwe actieve basis ten opzichte van de oude actieve basis. Wanneer de curve afvlakt, voltooi de afbouw, annuleer het oude contract en archiveer de exports.
Wat de overstap kost als PushEngage het voor u doet
Bij PushEngage is migratie een white-glove service die gratis is inbegrepen bij betaalde abonnementen. Je krijgt een migratie-engineer, geen helpdeskartikel: zij regelen de exportmapping, sleutelbeheer, de samenvoeging van de service-worker en het overnameplan. Dat is belangrijk omdat de faalmodi stil zijn - een ruwe import met verkeerde payload-indelingen kan technisch succesvolle maar lege meldingen opleveren, wat precies de klasse van stille storingen is die een specialist opvangt voordat je abonnees dat doen.
Het scopinggesprek duurt ongeveer vijftien minuten: aantal abonnees per kanaal, huidige leverancier en de sleutelvraag hierboven. Tegen het einde weet je of je Scenario A of B bent, en heb je een gedateerd plan.
Als je klaar bent om van pushmeldingprovider te wisselen, begin dan met de zes geschreven vragen in dit bericht en kijk hoe je huidige leverancier antwoordt. Kijk vervolgens wat een web push notification platform gebouwd rond segmentatie en omzetattributie zou doen met de lijst die je al bezit, en controleer PushEngage-prijzen tegen je huidige factuur. Elk betaald abonnement heeft een 14-daagse niet-goed-geld-terug-garantie, dus de pushmeldingmigratie zelf is het minst risicovolle deel van de beslissing.
