Web push propio: suscripción voluntaria y avisos útiles

Una suscripción propia a web push permite que el lector vuelva a una actualización útil que ha solicitado. La tarea del publisher consiste en mantener una promesa clara: qué contenido recibirá, desde qué sitio, con qué frecuencia y cómo dejar de recibirlo. Esta guía explica el proceso desde la preparación editorial hasta los resultados aceptados, con dos pilotos ficticios y plantillas reutilizables.

Verificado el 21 de octubre de 2026. Los hechos sobre navegadores proceden de MDN y documentación oficial de Chrome; el proceso editorial y los umbrales de decisión son nuestra propuesta metodológica. Los ejemplos tratan sobre software convencional y formación para adultos. No son casos de clientes ni confirman que existan ofertas equivalentes en AffiliateCore. Hay que comprobar por separado producto, país, tratamiento de datos y admisión de la fuente.

1. Suscripción propia, browser-push comprado e in-page

Suscripción propia: el lector elige las notificaciones de su sitio y usted responde de la promesa, el contenido y el cese de los envíos. «Propia» describe la relación con la audiencia, no la propiedad del navegador ni un acceso permanente a la persona. Push API recibe mensajes del servidor mediante un service worker incluso sin una página abierta. MDN: Push API.

Browser-push comprado: se adquiere una inserción publicitaria de otro propietario de inventario. Su audiencia no pasa a formar parte de su lista. Antes de contratarla habría que verificar por separado el origen de las suscripciones, la identificación publicitaria y las condiciones de la fuente y de la oferta. Esta guía no explica la compra de inventario ni propone transferir suscripciones ajenas.

In-page: aquí se refiere a una unidad publicitaria dentro de una página abierta que se parece a una notificación. Su aspecto no demuestra permiso del navegador ni una suscripción push. Identifique en el briefing la superficie real de exposición. No haga pasar el anuncio por una alerta del sistema operativo, un antivirus o un mensaje personal.

Recorrido didáctico: artículo útil y abierto → suscripción deliberada a actualizaciones → nueva notificación → recurso actualizado → enlace de afiliación opcional → acción acordada → revisión del resultado. Cada paso tiene una función distinta. La notificación no debe sustituir la lección prometida por una oferta comercial ajena.

2. Qué preparar antes del botón de suscripción

Necesita un sitio HTTPS, una persona responsable de la parte técnica, un editor, acceso a los registros de envío y un procedimiento para detener la serie. Compruebe las API necesarias y el comportamiento real en dispositivos propios. Chrome de escritorio no demuestra compatibilidad con todos los teléfonos. Si un dispositivo no admite el recorrido elegido, mantenga el recurso accesible y sugiera guardarlo en marcadores; otro canal de comunicación debe elegirse por separado.

Prepare una ficha de la serie: audiencia, utilidad concreta, tema, idioma, frecuencia, duración, responsable, página de preferencias y papel de las recomendaciones de afiliación. Por ejemplo: «Actualizaciones de plantillas de inventario, como máximo dos por semana». Prepare la primera página y el siguiente tema antes de captar suscriptores. Un calendario vacío no justifica volver a enviar el mismo anuncio.

Acuerde quién almacena las suscripciones, quién puede enviar y cómo se desactiva la serie. No copie endpoints en hojas editoriales: MDN indica expresamente que deben mantenerse secretos. Conceptos de suscripción en MDN. Al editor le basta un identificador interno y el estado. Defina conservación y acceso a los registros operativos; teléfono, fecha de nacimiento y ubicación precisa no son necesarios para entregar un artículo.

Para el paso de afiliación, compruebe primero una oferta adecuada en nuestra plataforma AffiliateCore y las condiciones de fuente, país y evento. Si no existe una oferta apropiada, la serie debe seguir siendo útil. También puede utilizar un programa directo acordado por separado, con sus propias condiciones y registros. Prepare su perfil de publisher en AffiliateCore para estudiar las ofertas disponibles para usted, sin dar por garantizada la aprobación.

3. Ofrecer una decisión voluntaria y comprensible

Sitúe la invitación después de un apartado útil, cuando ya se entienda por qué volver. Texto de ejemplo: «¿Quiere recibir actualizaciones de la plantilla? Hasta dos notificaciones semanales de nuestra redacción. Puede consultar todo sin suscribirse. Gestione o desactive las notificaciones en la página de preferencias». Incluya dos botones claros: «Elegir notificaciones» y «Ahora no». Es texto de su interfaz, no una imitación del aviso del navegador.

Solicite el permiso después de una acción explícita del usuario. Los requisitos de contexto seguro e interacción se explican en MDN: requestPermission(). No vincule la aceptación con demostrar que alguien es humano, descargar un archivo o abrir un artículo ya prometido. Rechazar no debe empeorar el acceso al contenido.

Distinga granted, denied y default; el último no es consentimiento. MDN: permission. Tras una negativa, no vuelva a preguntar en cada página. La persona debe iniciar cualquier regreso a las preferencias. Guarde la versión de la invitación, el momento de la elección, el tema y el estado de baja separados de los resultados comerciales.

El permiso del navegador no demuestra por sí solo que la entrega esté preparada. El responsable técnico comprueba la creación de la suscripción con PushManager.subscribe(). MDN: subscribe(). La aceptación técnica requiere observaciones separadas: permiso concedido, suscripción guardada y notificación editorial de prueba que abre la página correcta en un dispositivo propio. No muestre una confirmación falsa tras un error ni genere una conversión remunerada para esta prueba.

4. La baja forma parte del producto

Deje una vía visible hacia las preferencias en cada página de destino. Para el piloto basta elegir tema o darse de baja por completo; no prometa pausa ni horarios si esas funciones no existen. Explique si el cambio afecta a este navegador o a todos los dispositivos vinculados. No exija crear una cuenta únicamente para dejar de recibir avisos.

La suscripción actual puede terminarse mediante PushSubscription.unsubscribe(). MDN: unsubscribe(). En su proceso, excluya primero el registro de futuros envíos y compruebe después la sincronización. Un error no debe reincorporar automáticamente al lector. Volver a visitar el sitio tampoco debe reactivar silenciosamente una serie deshabilitada.

Como alternativa en Chrome de escritorio, indique Privacidad y seguridad → Configuración de sitios → Notificaciones. Ayuda de Chrome. Pruebe la baja antes del lanzamiento: desactive la serie en su dispositivo, prepare un envío de control y compruebe que el registro está excluido. Un mensaje ya entregado al servicio puede seguir en tránsito; no prometa retirarlos todos inmediatamente.

5. El ciclo editorial de cada notificación

1. Motivo. Anote qué cambia para el lector: un ejemplo nuevo, un error corregido o una lección disponible. Sin novedad sustancial, no envíe.
2. Ficha de edición. Registre tema, versión del recurso, título, explicación breve, destino, fecha límite de utilidad y revisor. El título debe seguir siendo comprensible si se recorta.
3. Revisión de la página. Ábrala en el móvil: recurso prometido visible, fecha de actualización clara, recomendación de afiliación identificada, clic opcional y preferencias accesibles.
4. Audiencia. Seleccione solo suscripciones activas del tema. Excluya bajas y registros duplicados de su sistema. No vincule dispositivos mediante huellas ocultas.
5. Envío y conciliación. Registre identificador, hora, audiencia real, errores y costes. Cuando termine el plazo de revisión, analice por separado resultados y causas de rechazo.

Plantilla editorial: «Edición / tarea del lector / utilidad nueva / promesa de suscripción / texto / URL / vigencia / tema / exclusiones / revisor / decisión». La mantiene el publisher; no es una función del panel de AffiliateCore. Revise la frecuencia total entre temas: dos series supuestamente poco frecuentes pueden saturar a una misma persona.

Chrome documenta una interfaz más discreta para pedir permisos. Anuncio de Chromium. La ausencia de un cuadro grande no justifica repetir la solicitud. Google también explica la retirada automática del permiso cuando coinciden poca interacción y muchos avisos. Explicación oficial. Nuestra consecuencia editorial es revisar utilidad y frecuencia, no eludir protecciones.

6. Separar las métricas y el papel de AffiliateCore

Registre por separado suscripciones activas, intentos de envío, errores técnicos, visitas al recurso, clics de afiliación y resultados del anunciante. No llame visualizaciones a los envíos. Si no hay prueba de exposición, indique «desconocido». Una notificación, una visita y una solicitud aceptada son eventos distintos.

Para una campaña activa acordada, AffiliateCore proporciona un enlace de seguimiento y un ejemplo con sub1, sub2 y sub3. Valores didácticos: fuente owned_push, serie inventory_lessons, edición update_01. Añada los identificadores al enlace real del panel conservando los parámetros existentes. No incluya endpoint, correo o nombre del suscriptor en la URL.

Con una oferta apropiada, el recorrido es notificación → artículo propio → enlace de campaña de AffiliateCore → página del anunciante → acción acordada. Los estados distinguen pending, confirmed y rejected. Las cancelaciones didácticas se concilian con decisiones definitivas y no implican un botón adicional. El publisher organiza suscripciones, preferencias, envíos y conciliación editorial; no se afirma que exista una integración push preparada.

Entre en el panel de publisher de AffiliateCore para revisar el enlace de su campaña y los resultados disponibles. Compruebe la admisión de la fuente antes de enviar tráfico. La contribución incremental requiere un experimento específico válido: los resultados atribuidos de los ejemplos no demuestran que las notificaciones hayan creado toda la demanda.

7. Piloto ficticio: actualizaciones de una plantilla de inventario

Hipótesis. Los lectores de una guía abierta de existencias agradecerían dos actualizaciones en dos semanas. El objetivo son solicitudes aceptadas de demostración de un software convencional de inventario, según criterios acordados. Se comprueban país atendido, necesidad real y duplicados; una compra no sustituye a una solicitud. No se presupone la existencia de esta oferta en AffiliateCore.

Materiales. Prepare plantilla inicial, página de cambios, dos avisos y ficha de aceptación. Primer texto: «La plantilla ya contempla devoluciones. Consulte un ejemplo rellenado». Segundo: «Revise una diferencia de existencias: tres pasos y una muestra corregida». Por separado: «Si lo necesita, compare requisitos del programa; este es un enlace de afiliación». El recurso sigue siendo útil sin pulsarlo.

Secuencia. El primer día pruebe suscripción y baja en sus dispositivos. Durante los días 2–5 invite a los lectores; la cohorte ficticia alcanza 200 suscripciones activas. Envíe las ediciones los días seis y diez solo a quienes sigan activos. No añada envíos hasta cerrar el plazo acordado de revisión. El tiempo del autor cuenta aunque realice todo el trabajo personalmente.

Presupuesto supuesto en EUR: contenido 120 €, configuración técnica y pruebas 80 €, infraestructura asignada 30 €, conciliación editorial y soporte 20 €. Total 250 €; compra de tráfico 0 €. Son supuestos internos del piloto, no precios de Chrome, proveedores push ni AffiliateCore. No proceden de una conversión de divisas.

Resultados. Se dan de baja ocho suscripciones: 8 / 200 = 4 %. La medición disponible distingue 90 visitas al recurso y 50 clics de afiliación. De 40 solicitudes, 34 se aceptan inicialmente y cuatro se cancelan después; otras dos se rechazan de inmediato y cuatro esperan revisión. Resultado: 30 aceptadas, seis rechazadas o canceladas y cuatro pendientes. Tres duplicados y un país no atendido explican las cuatro cancelaciones; son datos ficticios.

Economía. Suponga una remuneración didáctica de 10 € por solicitud definitivamente aceptada: 30 × 10 € = 300 €. La diferencia tras los costes enumerados es 50 €, antes de impuestos y otros gastos individuales. Coste por solicitud aceptada: 250 / 30 = 8,33 €. El equilibrio exige 25 solicitudes aceptadas. Las pendientes y canceladas no cuentan como ingresos obtenidos.

Decisión. Antes del ensayo se fijaron 250 € de gasto máximo, coste objetivo no superior a 9 € y un umbral de revisión de bajas del 5 % de la cohorte inicial. Son valores del ejercicio, no referencias sectoriales. El piloto los cumple, pero es provisional hasta resolver las cuatro solicitudes pendientes. Repita la misma serie con otra cohorte voluntaria sin aumentar frecuencia. Amplíe alcance gradualmente después de resultados repetibles; no extrapole 30 solicitudes a cualquier audiencia.

8. Piloto ficticio: una serie formativa que debe detenerse

Hipótesis. Un sitio de formación para adultos ofrece avisos de nuevos ejercicios de hojas de cálculo. El suscriptor elige el tema educativo; una solicitud opcional de consulta con un profesor solo cuenta según los criterios pactados. Se planean tres ediciones en dos semanas para 300 suscripciones activas de otra cohorte.

Plantilla. «Nuevo ejercicio: revise su fórmula de búsqueda. Enunciado y solución abiertos». La página incluye datos de ejemplo, solución y explicación del error. La consulta opcional muestra condiciones y relación de afiliación. Ficha de revisión: «Nivel adecuado / idioma disponible / petición autónoma / no duplicado / resultado y motivo». No prometa certificado, empleo o consulta gratuita sin confirmación.

Ejecución. Envíe la primera edición tras la aceptación técnica. Antes de la segunda, contraste la promesa con el tema elegido. En el ejemplo, un editor sustituyó el título útil por «Inscríbase ahora» y aumentaron las bajas después del segundo aviso. La tercera edición se cancela, en lugar de enviarse para cumplir el calendario. Conserve ambas versiones y analice la discrepancia; no reincorpore a quienes se dieron de baja.

Costes supuestos: ejercicios y edición 90 €, configuración y prueba 60 €, infraestructura asignada 30 €, revisión de solicitudes 20 €. Gasto real 200 €, sin compra de tráfico. No añada el envío cancelado ni elimine trabajo ya realizado. Es una estimación de recursos, no una tarifa de entrega.

Conciliación. Se dan de baja 36 de 300 suscripciones: 12 %. Hay 70 visitas, 25 clics de afiliación y 20 solicitudes. Se aceptan inicialmente doce y luego se cancelan cuatro: dos duplicadas y dos fuera del nivel acordado. Otras seis se rechazan inmediatamente y dos siguen pendientes. Quedan ocho aceptadas, diez rechazadas o canceladas y dos pendientes. Esta distribución no demuestra por sí sola fraude.

Economía y parada. Con una remuneración hipotética de 15 € por solicitud aceptada, se obtienen 120 € y una diferencia de menos 80 € tras los costes. El coste por aceptada es 25 €; el equilibrio requiere al menos 14. Incluso aceptando las dos pendientes se alcanzarían solo 150 €. Los límites previos eran 200 € de presupuesto, coste máximo de 13,50 € y bajas no superiores al 5 %. No se cumplen; aumentar frecuencia no lo arregla.

Reinicio. Revise promesa, ejercicio, formulario y criterios con el anunciante. La nueva versión debe volver a ofrecer el ejercicio, dejando voluntario el paso comercial. Pruebe correcciones y baja en sus dispositivos; después utilice una pequeña cohorte voluntaria distinta con nuevo límite. Escale solo tras un plazo completo de revisión, economía sostenible y bajas aceptables. Si faltan datos, prolongue observación, no envíos.

9. Diagnosticar sin presionar al suscriptor

Sin cuadro de permiso: revise compatibilidad, contexto y elección guardada, sin disfrazar la petición con otro botón. Permiso sin suscripción: el técnico comprueba creación y almacenamiento. Clics sin visitas: abra la página concreta y la cadena de redirecciones en un dispositivo de prueba. Solicitudes con pocas aceptaciones: revise motivos pactados y madurez de la cohorte.

TTL limita el plazo de entrega; se eliminan suscripciones inválidas y la aceptación técnica del envío no es una visualización. Web Push Protocol. Defina la vigencia antes de enviar: un aviso tardío no debe invitar a una clase ya terminada. Guarde errores sin endpoints secretos.

El aumento de bajas justifica pausar la siguiente edición y revisar tema y frecuencia. Investigue una queja sobre un remitente inesperado mediante la versión de la invitación y el historial de elección. No compre sustitutos de quienes se marcharon ni cambie de dominio para eludir bloqueos. Depure errores con dispositivos propios; la audiencia no debe recibir repeticiones como herramienta de prueba.

10. Ejercicio antes de la primera edición

• Redacte la promesa de un tema y dos notificaciones útiles.
• Prepare recursos abiertos, identificación de afiliación y baja funcional.
• Pruebe permiso, suscripción, destino, baja y nueva visita en dispositivos propios.
• Acuerde fuente, evento, plazo de revisión y motivos de rechazo.
• Fije presupuesto, coste máximo por resultado y umbral de bajas antes de ver cifras.
• Separe envíos, visitas, aceptadas, canceladas y pendientes en el informe.
• Documente la decisión: parar, corregir, observar o repetir un piloto limitado.

Para procesos relacionados: serie voluntaria de email y canal propio de Telegram. Sus mecanismos de suscripción son distintos; no transfiera automáticamente el consentimiento entre canales.