Construiste tu lista de suscriptores de notificaciones push una por una, con cada registro conseguido con esfuerzo, y cada registro te costó dinero real de adquisición. Así que, cuando llega el momento de cambiar de proveedor de notificaciones push, el miedo es específico: cancelas el contrato antiguo y la lista desaparece con él. Tu proveedor actual puede incluso decirte exactamente eso.
No es cierto, y esta guía te muestra por qué a nivel del navegador. Una suscripción de notificaciones push web está vinculada a tu dominio, no a tu proveedor. Una vez que veas la mecánica, cada cambio se resuelve en uno de dos escenarios claros, una lista corta de preguntas escritas para tu proveedor actual y una lista de verificación de una semana que tu equipo puede ejecutar sin problemas.
Una nota honesta por adelantado. El equipo de ventas de cada proveedor, incluido el nuestro, te dirá que la migración es fácil. La mayoría se detiene ahí. Esta publicación te muestra el mecanismo en su lugar, para que tu desarrollador pueda verificar cada afirmación, incluidas las que hacemos al final.
Qué es realmente una suscripción de notificaciones push web
Cuando un visitante hace clic en "Permitir" en tu sitio, el navegador crea una suscripción de notificaciones push web basada en tres partes:
- Tu origen. El dominio exacto en el que se concedió el permiso (
https://tudominio.com). El permiso reside en el navegador, adjunto al origen. No menciona ningún proveedor. - Un service worker. Un pequeño archivo JavaScript alojado en tu dominio que recibe y muestra notificaciones. El service worker que esté registrado controla la entrega.
- Una clave de servidor de aplicación. La mitad pública de un par de claves VAPID. El servicio de notificaciones push del navegador solo acepta envíos firmados con la clave privada correspondiente. Quien posea esa clave privada puede enviar mensajes a la suscripción. (La visión general de las notificaciones push de web.dev cubre el protocolo completo).
El registro de suscripción en sí son tres cadenas: una URL de endpoint más dos claves cortas, p256dh y auth. Ese es el activo completo. Tu lista completa es una tabla de esos registros.
Una regla decide todo lo que sigue: los navegadores aceptan envíos solo del titular de la clave privada VAPID correspondiente. Lo que significa que cada cambio de proveedor se resuelve en exactamente dos escenarios, dependiendo de dónde residan esas claves.
Escenario A: tus claves VAPID viajan, así que importas suscriptores push desde el primer día
El escenario A se aplica cuando las claves son tuyas para llevarlas: configuraste tus propias claves VAPID o tu propio proyecto de Firebase al configurar, o tu proveedor saliente acepta entregar el par de claves. Algunos equipos configuran esto deliberadamente desde el primer día; el enfoque se cubre en nuestra guía para implementar notificaciones push web sin dependencia del proveedor.
Con la clave privada en mano, su nuevo proveedor puede importar suscriptores push directamente: cada endpoint, registro p256dh y auth se traslada, y puede enviar mensajes a toda su lista existente desde el primer día. Esto incluye a los suscriptores inactivos que no han visitado en meses. Nadie vuelve a suscribirse. Nadie se da cuenta.
Un matiz que vale la pena aclarar. Incluso en el Escenario A, la migración duradera aún se completa a través de las visitas, ya que cada suscriptor eventualmente necesita aterrizar en el nuevo service worker. Las claves importadas le otorgan alcance el primer día mientras esa transición ocurre silenciosamente en segundo plano.
Escenario B: las claves se quedan atrás y la nueva suscripción silenciosa se encarga
El escenario B es la opción predeterminada común: el proveedor generó las claves VAPID y las conserva. Sin la clave privada, los registros exportados son criptográficamente inútiles. El alcance el primer día es cero, y la advertencia de su antiguo proveedor suena cierta durante aproximadamente un párrafo más.
Esto es lo que realmente sucede. La próxima vez que cada suscriptor visite su sitio, el service worker del nuevo proveedor se encarga: anula el registro del antiguo, cancela la suscripción antigua y vuelve a suscribir al visitante con las nuevas claves. Silenciosamente, en una sola visita, sin una segunda solicitud de permiso.
Por qué el nuevo service worker no necesita una segunda solicitud
El permiso de notificación se otorga a su origen, no a un proveedor. El navegador ya confía en su dominio. Cambiar el service worker y las claves debajo de un permiso ya otorgado es invisible para el visitante, porque el navegador lo trata como si su sitio estuviera reorganizando su propia infraestructura. Eso es exactamente lo que es.
Dos trampas que su desarrollador debe conocer
Un origen, una suscripción. Un navegador no puede mantener dos suscripciones push para el mismo origen. Suscribirse con una clave diferente falla hasta que se libera la suscripción antigua. Por lo tanto, "ejecutar ambos proveedores en paralelo" funciona a nivel de lista, nunca dentro de un solo navegador: cada suscriptor está en el proveedor antiguo o en el nuevo, y cada visita traslada a uno más.
Las suscripciones de subdominios de proveedores nunca se mueven. Las suscripciones recopiladas en yoursite.vendor.com pertenecen al origen del proveedor, y ningún proveedor puede migrarlas. Esa base se reconstruye desde cero. Es la mayor trampa en cualquier migración de notificaciones push y el argumento más sólido para anclar las suscripciones a un dominio que controle esta vez. Si opera varias marcas o dominios regionales, la misma lógica de origen da forma a toda su arquitectura; lo cubrimos en web push en múltiples dominios.
Aquí están los dos escenarios uno al lado del otro:
| Escenario A: las claves viajan | Escenario B: las claves se quedan atrás | |
|---|---|---|
| Cuándo aplica | Claves VAPID propias / proyecto Firebase propio, o el proveedor libera el par | El proveedor generó y retiene las claves (la opción predeterminada común) |
| Alcance el Día 1 | Toda su lista, incluidos los suscriptores inactivos | Cero, hasta que los visitantes regresen |
| En cada visita | El suscriptor se traslada silenciosamente a las nuevas claves | Nueva suscripción silenciosa con las nuevas claves, sin segunda solicitud |
| A quién recupera | Todos | Todos los que visitan de nuevo |
| A quién pierde | Nadie | Suscriptores que nunca regresan (que de todos modos ya no eran ingresos alcanzables) |
Por qué las audiencias de visita diaria completan una migración de notificaciones push más rápido
En el Escenario B, el reloj de traspaso es la frecuencia de retorno de su audiencia. Nada más. Un suscriptor de comercio electrónico puede visitar mensualmente, por lo que el traspaso se extiende a lo largo de los meses. Un apostador consulta probabilidades, líneas y resultados diariamente. Un lector de noticias regresa para cada ciclo de titulares.
Ese ritmo de retorno es la razón por la que los sitios de apuestas y noticias son los verticales mejor posicionados en Internet para cambiar de proveedor de notificaciones push: la misma frecuencia de visita que hace de las notificaciones push para sitios de apuestas un motor de retención también comprime una migración que lleva un trimestre a otros sitios en una o dos semanas. Los sitios de apuestas y juegos en PushEngage han enviado más de 3.5 mil millones de notificaciones, por lo que estas mecánicas de traspaso son una realidad de producción diaria para nosotros, no una teoría.
| Patrón de retorno de la audiencia | Traspaso típico de la base activa |
|---|---|
| Visitantes diarios (cuotas en vivo, noticias de última hora, promociones diarias) | Días a aproximadamente una semana |
| Varias visitas por semana (apostadores de fin de semana, habituales) | 1-2 semanas |
| Semanal o menos (visitantes estacionales, usuarios inactivos) | Semanas, acelerado por envíos del antiguo proveedor y grandes eventos |
| Inactivo (sin visitas en meses) | Recuperable solo bajo el Escenario A |
Estos son patrones típicos para audiencias de visita diaria, no garantías; su curva depende del ritmo de su tráfico y la observará en vivo en el panel. También puede doblar la curva: programe la transición la semana anterior a un gran evento y el tráfico del evento hará el traspaso por usted. Las casas de apuestas que planean una secuencia de push para el día del partido ya saben qué fines de semana son esos.
El push de la aplicación es más simple: sus tokens siempre fueron suyos
Si también envía push de aplicaciones, respire hondo. Esta parte es estructuralmente fácil, porque ningún proveedor puede retenerla como rehén.
Los certificados y claves de APNs se emiten a su cuenta de desarrollador de Apple. Su proyecto de FCM vive en su consola de Google. Un proveedor de push es una capa sobre las credenciales que usted posee, por lo que cambiar significa apuntar una nueva capa a las mismas credenciales. Los tokens de dispositivo se exportan e importan limpiamente, sin reinstalaciones y sin una segunda solicitud de permiso.
Dos notas prácticas. Primero, filtre las exportaciones de tokens a dispositivos activos aproximadamente durante 270 días antes de importar, porque FCM trata los tokens inactivos más allá de ~270 días como obsoletos. Un volcado de tokens de cinco años infla su recuento de suscriptores y, en precios que solo cuentan suscriptores activos, nadie se beneficia de eso. Segundo, la cobertura completa del SDK llega a la velocidad con la que los usuarios actualizan su aplicación, típicamente una o dos semanas para una aplicación de uso diario con actualizaciones automáticas.
Si su aplicación iOS actualmente envía a través de Firebase, el flujo paso a paso es un tema en sí mismo; consulte nuestra guía para migrar de Firebase Cloud Messaging en iOS en lugar de improvisarlo a partir de esta publicación.
Antes de cambiar de proveedor de notificaciones push, haga estas seis preguntas por escrito
Las exportaciones de proveedores y las políticas clave varían y cambian. En lugar de confiar en cualquier tabla de veredictos de proveedores (incluida una que podríamos publicar), obtenga las respuestas de su propio proveedor por escrito. El correo electrónico funciona; un ticket de soporte funciona mejor. Si está evaluando destinos al mismo tiempo, las mismas preguntas sirven como un filtro útil mientras compara alternativas a OneSignal.
- ¿Puede exportar mis registros completos de suscripción de notificaciones push web — URL del endpoint más las claves
p256dhyauthpara cada suscriptor — o solo IDs internos? Los IDs internos no tienen sentido fuera del sistema del proveedor. - ¿Publicará el par de claves VAPID bajo el cual se crearon mis suscripciones? Esta única respuesta decide entre el Escenario A y el Escenario B.
- ¿En el proyecto FCM o Firebase de quién se ejecutan mis notificaciones push web, ¿en el mío o en el suyo? Si es el suyo, las claves ya pueden estar en su propia consola.
- ¿Puedo exportar segmentos, etiquetas, atributos de suscriptor y listas de supresión por separado? No se incluyen automáticamente con los registros de suscripción.
- ¿Puedo exportar los tokens de dispositivo de mi aplicación push y en qué formato?
- ¿Qué sucede con mis datos si reduzco el nivel o cancelo? ¿Hay una eliminación automática o una ventana de retención? Algunos proveedores eliminan los datos de suscriptores inactivos en niveles inferiores. Exporte primero, siempre.
La lista de verificación de la semana de migración
Imprima esta sección. Ocho pasos, en orden.
- Exporte todo antes de cancelar o reducir el nivel de cualquier cosa. Registros de suscripción, tokens de aplicación, segmentos, etiquetas, atributos, listas de supresión. El acceso a la exportación muere con su contrato.
- Obtenga la respuesta de las claves VAPID por escrito. Decide su escenario y si puede importar suscriptores push desde el primer día.
- Mueva las listas de supresión primero, no al final. Para los operadores de apuestas y juegos, esto es innegociable: los jugadores autoexcluidos deben ser suprimidos en la nueva plataforma antes de que se reanude cualquier campaña, no reconciliados después.
- Filtre los tokens de la aplicación a ~270 días de actividad antes de la importación.
- Instale el nuevo SDK y service worker, y mézclelo con cualquier service worker existente (una shell PWA, el worker del proveedor anterior) en lugar de sobrescribirlo.
- No elimine el archivo del service worker del proveedor anterior el primer día. Los visitantes que regresan todavía tienen registros que apuntan a él; la transferencia los desregistra elegantemente. Si elimina el archivo prematuramente, generará errores en la consola en lugar de migraciones. Elimínelo en la limpieza final.
- Mantenga al proveedor anterior enviando durante la ventana paralela. Contraintuitivo pero crítico: cada notificación que envía el proveedor anterior impulsa una visita de regreso, y cada visita de regreso completa la migración de un suscriptor más. Su proveedor saliente se convierte en su mejor herramienta de migración.
- Mida la transferencia diariamente y cambie en la meseta. Rastree la nueva base activa frente a la base activa anterior. Cuando la curva se aplane, finalice la limpieza, cancele el contrato anterior y archive las exportaciones.
El costo de cambio cuando PushEngage lo hace por usted
En PushEngage, la migración es un servicio de guantes blancos incluido gratis en los planes de pago. Obtienes un ingeniero de migración, no un artículo del centro de ayuda: ellos se encargan del mapeo de exportación, la gestión de claves, la fusión del service worker y el plan de traspaso. Eso es importante porque los modos de fallo son silenciosos: una importación bruta con formatos de carga útil no coincidentes puede entregar notificaciones técnicamente exitosas pero en blanco, que es exactamente la clase de fallo silencioso que un especialista detecta antes que tus suscriptores.
La llamada de alcance dura unos quince minutos: recuentos de suscriptores por canal, proveedor actual y la pregunta sobre claves anterior. Al final de la misma, sabrás si te encuentras en el Escenario A o B, y tendrás un plan con fecha.
Si estás listo para cambiar de proveedor de notificaciones push, comienza con las seis preguntas escritas en esta publicación y ve cómo responde tu proveedor actual. Luego, mira lo que una plataforma de notificaciones push web construida en torno a la segmentación y la atribución de ingresos haría con la lista que ya posees, y compara los precios de PushEngage con tu factura actual. Cada plan de pago incluye una garantía de devolución de dinero de 14 días, por lo que la migración de notificaciones push en sí es la parte de menor riesgo de la decisión.
