Las notificaciones push web han atravesado tres ciclos desde 2015: entusiasmo inicial («el nuevo email»), saturación y fatiga del usuario (popups intrusivos, opt-in engañoso), maduración normativa (RGPD, ePrivacy). En 2026, el push web vuelve a ser una palanca interesante — a condición de comprender qué ha cambiado y qué no.
El push web no es un canal de masas a la manera del email. Es un canal de re-engagement de nicho, con una tasa de opt-in baja (5-10 % de la base de visitantes), restricciones técnicas específicas y una exigencia de calidad elevada — demasiados envíos, y el usuario se da de baja. Este artículo hace balance de lo que funciona en 2026, los protocolos, las herramientas y la prueba de pertinencia a realizar antes de invertir.
Qué es técnicamente el push web
El push web se basa en el protocolo Web Push API estandarizado por el W3C. Mecánica:
- El visitante llega al sitio. Tras cierto tiempo o después de una acción, se muestra una solicitud de permiso (la modal nativa del navegador).
- Si el usuario acepta, el navegador genera un endpoint único (URL de los servidores push de Mozilla, Google o Apple) y lo comparte con el sitio.
- El sitio almacena ese endpoint, asociado a un identificador de usuario si se conoce.
- Para enviar una notificación, el sitio (o su herramienta push) envía una petición firmada VAPID al endpoint, que empuja la notificación al navegador.
- El usuario ve la notificación incluso si el sitio no está abierto, mientras el navegador esté en ejecución (o en segundo plano en móvil).
Soporte de navegadores en 2026
- Chrome, Edge, Firefox, Opera en escritorio y Android: soporte completo desde hace tiempo.
- Safari macOS e iPadOS: soporte nativo desde macOS 13.
- Safari iOS (iPhone): soporte parcial desde iOS 16.4 (marzo 2023), a condición de que el sitio esté instalado como PWA en la pantalla de inicio. Esta es la gran limitación: en iPhone, el push web requiere la instalación previa de la PWA.
Consecuencia en 2026: el push web es potente en Android y escritorio, marginal en iPhone mientras la PWA no esté instalada. Para una audiencia mayoritariamente iOS sin PWA, el push web solo cubre el 20-30 % de la base.
El marco RGPD y ePrivacy
El push web entra en el ámbito de la directiva ePrivacy y del RGPD:
- Consentimiento explícito: la modal push nativa del navegador hace las veces de recogida de consentimiento, pero solo se dispara si se invoca correctamente (en respuesta a una acción clara del usuario, no al cargar la página).
- Información previa: el usuario debe saber qué va a recibir antes de aceptar. Buena práctica: mostrar un pre-prompt a medida («¿Recibir nuestras alertas promo?») antes de la modal nativa.
- Baja sencilla: un botón de baja debe estar accesible en todo momento, idealmente directamente en la notificación.
- Datos personales: el endpoint push no es en sí un dato personal, pero la asociación con un identificador de cliente lo convierte en dato personal. A documentar en el registro RGPD.
Los opt-in engañosos («Haz clic en OK para acceder al sitio») son sancionados por la AEPD y siguen siendo el error más frecuente. A partir de 2024-2025, la jurisprudencia es firme: un opt-in ambiguo equivale a ausencia de consentimiento.
Los casos de uso que justifican el canal
El push web solo es rentable en casos de uso de alta señal. Mal uso: newsletter diaria. Buenos usos:
1. Cart abandonment
Notificación push 1h-4h después del abandono de carrito: «Tu carrito te espera, finaliza antes del fin de la promo.» Tasa de clic típica 4-12 %, tasa de conversión clic-venta 8-15 %. ROI generalmente positivo a partir de 50 carritos abandonados / día.
2. Back in stock
El comprador se había inscrito en la lista de espera de un producto agotado. «El producto X ha vuelto.» Push lanzado en cuanto se repone. Tasa de clic 25-45 %, tasa de conversión 15-30 %. Es el caso de uso rey.
3. Price drop
El comprador había añadido a favoritos o consultado un producto. «El precio del producto X acaba de bajar un 20 %.» Push lanzado al detectar un cambio de precio significativo. Tasa de clic 10-20 %, tasa de conversión 5-12 %.
4. Confirmación de evento importante
«Tu pedido ha sido enviado», «Código de recogida disponible». Pero en competencia con SMS y emails transaccionales — a menudo menos pertinente para estos eventos.
5. Lanzamientos de ofertas limitadas
«Venta flash 2h» sobre productos vigilados. A usar con moderación para no agotar la base.
Herramientas en 2026
OneSignal
- Líder mundial, plan gratuito generoso (hasta 10 K suscriptores).
- Módulo PrestaShop oficial y SDK completo.
- Segmentación, tags dinámicos, A/B testing incluidos.
- Tarifa de pago desde 9 $/mes, escalado hasta varios cientos.
PushOwl
- Especialista e-commerce, enfocado en Shopify pero integrable en PrestaShop vía API.
- Templates e-commerce nativos (cart abandonment, back in stock, etc.).
- Tarifa desde 19 $/mes.
Wonderpush
- Solución europea, hosting UE, más estricta en conformidad RGPD.
- Módulo PrestaShop específico.
- Tarifa desde 1 €/1000 push, planes empresa negociables.
DIY mediante Web Push API
- Desarrollo custom usando la Web Push API nativa.
- Coste inicial 5-15 K€ de desarrollo.
- Pertinente únicamente si se tiene una necesidad específica no cubierta por las soluciones SaaS, o un argumento de soberanía de los datos.
La aritmética del ROI
En una tienda PrestaShop con 100 K visitantes únicos al mes:
- Tasa de opt-in realista en 2026: 5-10 % tras 30 días de optimización = 5 000 a 10 000 suscriptores.
- Baja / churn: 2-4 % al mes — hay que renovar la base.
- Push transaccionales (back in stock, cart abandon, price drop): 100-500 envíos / día según tamaño de catálogo.
- CTR típico: 6-15 %.
- Conversión clic-venta: 5-12 %.
Sobre esta base, el push web genera típicamente entre el 2 y el 5 % de la facturación total de la tienda. En una tienda de 500 K€/mes, son 10-25 K€/mes de facturación adicional por un coste de herramienta de 20-150 €/mes. ROI claramente positivo siempre que la base se mantenga con calidad.
Cuando el push web es una molestia que destruye la confianza
El mismo canal puede hacer perder un 2-5 % de la facturación si se usa mal. Señales de mal uso:
- Envíos diarios promocionales genéricos: el visitante se da de baja y asocia la marca al spam.
- Opt-in nada más llegar: la modal se muestra a la vez que se carga la página. Resultado: 95 % de «Rechazo» y opt-in definitivamente bloqueado por el navegador (en Chrome, tras 2-3 rechazos, el botón desaparece).
- Contenido engañoso: titular que promete una promo, clic que lleva a una ficha de producto estándar. Resultado: la tasa de queja en el navegador sube, la entrega futura se degrada por los servidores push.
- Confusión de canal: enviar notificaciones que deberían haber sido emails. El push es corto (< 200 caracteres), efímero y sin contenido enriquecido. Mal canal para una newsletter.
La mecánica de opt-in que funciona
- Sin opt-in en la página de aterrizaje. Disparo tras 30-60 segundos de sesión, o tras una señal de engagement (consulta de 3 páginas, añadido a favoritos, abandono de carrito).
- Pre-prompt a medida: un cuadro «¿Recibir tus alertas de promo, reposición y novedades?» con botón «Sí» / «Más tarde». Si «Sí», se dispara la modal nativa.
- Valor claro: indicar lo que el usuario va a recibir («máximo 2 push por semana», «solo las reposiciones de los productos que sigues»).
- No más de 1 solicitud por sesión y memorización: si rechaza, no volver a pedir antes de 30 días.
Las trampas a evitar
1. Saturar y quemar la base
Más de 2 push promocionales por semana y la baja se dispara. Regla empírica: 1 push transaccional por día máximo, 1 push promocional por semana máximo.
2. Confundir opt-in y suscripción a newsletter
El RGPD exige un consentimiento distinto para cada canal. La suscripción a newsletter no da derecho a hacer push. Y al revés.
3. No medir la entregabilidad
Los servidores push de Google y Mozilla degradan la entregabilidad de los envíos en caso de tasa de queja elevada o de contenido sospechoso. Monitorizar la tasa de entrega vía el dashboard de la herramienta push, y corregir en cuanto baje del 90 %.
4. Olvidar el re-engagement de la base inactiva
Un suscriptor que no ha hecho clic en 90 días es un candidato probable a darse de baja pronto. Mejor sacarlo proactivamente de la base que seguir contaminando sus notificaciones.
5. Descuidar el iOS PWA
En audiencia mayoritariamente iPhone, el push web sin PWA instalable cubre una fracción de la base. Si la PWA se implementa y se promueve activamente («Instalar nuestra app»), el push web se vuelve pertinente. Sin PWA, hay que priorizar otros canales.
Conclusión: una palanca de nicho, no un canal de masas
En 2026, el push web no es ni la solución milagrosa vendida en 2018 ni el canal muerto predicho en 2022. Es una palanca de re-engagement de nicho, que aporta entre el 2 y el 5 % de facturación adicional sobre casos de uso bien identificados (cart abandonment, back in stock, price drop). A condición de respetar tres reglas: opt-in honesto sin engaño, contenido transaccional de alto valor, parsimonia en lo promocional.
Para una tienda PrestaShop mid-market, OneSignal en plan gratuito o de pago básico cubre la mayoría de las necesidades, con un despliegue en 2-5 días. La prueba de pertinencia lleva 60-90 días: si tras ese plazo el opt-in se estanca por debajo del 3 % o los push generan menos del 1 % de la facturación, el canal no es prioritario para esta audiencia. Si supera el 4 %, es una palanca estructural a mantener a largo plazo.
