El paso natural después de obtener un PushSubscription y guardarlo en nuestro servidor es activar un mensaje push, pero hay un aspecto que ignoré atentamente. La experiencia del usuario cuando se le solicita permiso para enviarle mensajes push.
Lamentablemente, muy pocos sitios tienen en cuenta la manera en que solicitan permiso a sus usuarios, así que hagamos un breve apartado para analizar la UX buena y mala.
Patrones comunes
Ha surgido algunos patrones comunes que deberían guiarte y ayudarte a decidir qué es mejor para tus usuarios y tu caso de uso.
Propuesta de valor
Pídeles a los usuarios que se suscriban para enviar mensajes en un momento en el que el beneficio sea evidente.
Por ejemplo, un usuario acaba de comprar un artículo en una tienda en línea y finalizó el flujo de confirmación de la compra. Luego, el sitio podrá ofrecer actualizaciones sobre el estado del envío.
Este enfoque funciona en varias situaciones:
- Un artículo específico está agotado. ¿Te gustaría recibir una notificación cuando esté disponible?
- Esta noticia de último momento se actualizará con regularidad. ¿Te gustaría recibir una notificación a medida que se desarrolle?
- Eres el anunciante con la oferta más alta. ¿Te gustaría recibir una notificación si se superó la oferta?
Todos estos son puntos en los que el usuario invirtió en tu servicio y hay una propuesta de valor clara para que habilite las notificaciones push.
creó una simulación del sitio web hipotético de una aerolínea para demostrar este enfoque.
Después de que el usuario reservó un vuelo, se le preguntará si desea recibir notificaciones de retrasos de vuelos.
Ten en cuenta que esta es una IU personalizada del sitio web.
Otro detalle atractivo de la demostración de Owen es que, si el usuario hace clic para habilitar las notificaciones, el sitio agrega una superposición semitransparente en toda la página cuando se muestra la solicitud de permiso. Esto atrae la atención de los usuarios hacia el mensaje del permiso.
La alternativa a este ejemplo, la UX deficiente para solicitar permiso, es solicitar el permiso en cuanto un usuario llega al sitio de la aerolínea.
Este enfoque no proporciona contexto sobre por qué las notificaciones son necesarias o útiles para el usuario. Este mensaje de permiso también impide al usuario realizar la tarea original (es decir, reservar un vuelo).
Permiso doble
Tal vez creas que tu sitio presenta un caso de uso claro para los mensajes push y, como resultado, quieres pedirle permiso al usuario lo antes posible.
Por ejemplo, mensajería instantánea y clientes de correo electrónico. Mostrar un mensaje en un mensaje o correo electrónico nuevo es una experiencia del usuario establecida en una variedad de plataformas.
Para estas categorías de apps, vale la pena considerar el patrón de doble permiso.
Primero, muestra un mensaje de permiso falso que controle tu sitio web, que consta de botones para permitir o ignorar la solicitud de permiso. Si el usuario hace clic en Permitir, solicita el permiso, lo que activa el mensaje de permiso real del navegador.
Con este enfoque, muestras un mensaje de permiso personalizado en tu app web, en el que se le pide al usuario que habilite las notificaciones. De esta manera, el usuario puede elegir habilitar o inhabilitar sin que tu sitio web corra el riesgo de quedar bloqueado de forma permanente. Si el usuario selecciona Habilitar en la IU personalizada, muestra la solicitud de permiso real. De lo contrario, oculta la ventana emergente personalizada y haz otra pregunta.
Un buen ejemplo de esto es . Muestran un mensaje en la parte superior de la página una vez que accedes para preguntarte si deseas habilitar las notificaciones.
Panel de Configuración
Puedes mover notificaciones a un panel de configuración, lo que brinda a los usuarios una manera fácil de habilitar o inhabilitar los mensajes push, sin necesidad de saturar la IU de tu app web.
Un buen ejemplo de esto es . Cuando cargas el sitio de Google I/O por primera vez, no se te solicita que hagas nada; el usuario solo puede explorar el sitio.
Después de algunas visitas, si haces clic en el elemento de menú de la derecha, se mostrará un panel de configuración que permite al usuario configurar y administrar las notificaciones.
Cuando haces clic en la casilla de verificación, se muestra la solicitud de permiso. Sin sorpresas ocultas.
Una vez que se haya otorgado el permiso, se marcará la casilla de verificación y el usuario estará listo para comenzar. Lo mejor de esta IU es que los usuarios pueden habilitar o inhabilitar las notificaciones desde una ubicación en el sitio web.
Enfoque pasivo
Una de las formas más fáciles de enviar un mensaje a un usuario es tener un botón o un interruptor que habilite o inhabilite los mensajes push en una ubicación de la página que sea coherente en todo el sitio.
Esto no impulsa a los usuarios a habilitar las notificaciones push, pero ofrece una manera fácil y confiable de habilitar o inhabilitar la interacción con tu sitio web. En el caso de sitios como blogs que pueden tener algunos espectadores regulares, así como altos porcentajes de rebote, esta es una opción sólida, ya que se orienta a los usuarios habituales sin molestar a los visitantes que conducen directamente.
En mi sitio personal, tengo un interruptor para activar los mensajes push en el pie de página.
Es bastante irrelevante, pero para los visitantes habituales debería captar suficiente atención de los lectores que desean recibir actualizaciones. Los visitantes esporádicos no se ven afectados por completo.
Si el usuario se suscribe a los mensajes push, el estado del interruptor de activación cambia y mantiene el estado en todo el sitio.
La mala UX
Esas son algunas de las prácticas comunes que he observado en la Web. Lamentablemente, hay una mala práctica muy común.
Lo peor que puedes hacer es mostrarles el diálogo del permiso a los usuarios en cuanto llegan a tu sitio.
No sabe por qué se les solicita un permiso, y es posible que ni siquiera sepan para qué sirve tu sitio web, para qué sirve o qué ofrece. No es inusual bloquear permisos en este momento por frustración, ya que esta ventana emergente interfiere con lo que intenta hacer.
Recuerda que, si el usuario bloquea la solicitud de permiso, tu app web no puede volver a solicitarlo. Para obtener permiso después de ser bloqueado, el usuario debe cambiarlo en la IU del navegador, y hacerlo no es fácil, obvio ni divertido para el usuario.
Sin importar lo que suceda, no solicites permiso apenas el usuario abra el sitio. Considera otra IU o enfoque que incite al usuario a otorgar permiso.
Ofrecer una salida
Además de considerar la UX para suscribir a un usuario al envío, considera cómo un usuario debe anular la suscripción o inhabilitar los mensajes push.
Es asombrosa la cantidad de sitios que solicitan permiso en cuanto se carga la página y, luego, no ofrecen ninguna IU para inhabilitar las notificaciones push.
Tu sitio debe explicar a los usuarios cómo pueden inhabilitar las notificaciones push. De lo contrario, es probable que los usuarios acepten la opción nuclear y bloqueen el permiso de forma permanente.
Próximos pasos
- Descripción general de las notificaciones push web
- Cómo funciona Push
- Cómo suscribirte a un usuario
- UX de permisos
- Envía mensajes con bibliotecas push web
- Protocolo de envío web
- Manejo de eventos push
- Muestra una notificación
- Comportamiento de las notificaciones
- Patrones de notificaciones comunes
- Preguntas frecuentes sobre las notificaciones push
- Cómo informar errores y problemas habituales