Queremos evaluar cómo enviar notificaciones a dispositivos móviles.
- ¿Qué es una notificación?
- Consideraciones al diseñar una notificación
- Cuando enviarla
- Evita interrupciones
- Usa badges
- Pide pre-permiso
- Copy
- Personalización
- A|B Testing
- Throttle
- Opciones de implementación
- Mecánica de envío de una notificación
- Referencias
¿Qué es una notificación?
Una notificación push es un mensaje enviado desde un servidor a un cliente, que puede ser un navegador o dispositivo móvil.
- ¿Quién la envía?
- El envío lo inicia el servidor, sin necesidad de que el cliente esté siquiera conectado (lo recibirá la próxima vez que esté online). Para ello cada cliente se registra con el servidor de push de su fabricante (Google, Apple, Mozilla, etc.) cuando es instalado en el sistema operativo.
- ¿Como se gestiona?
- Si el sistema operativo recibe la notificación cuando el cliente está abierto, la notificación es gestionada por un método delegado del código de la aplicación. Si la aplicación está en segundo plano, el sistema operativo muestra una alerta, o un número superpuesto al icono de la aplicación.
- ¿Qué contiene?
- Las notificaciones pueden contener texto, imágenes, e incluso interfaces interactivos a medida. Si pulsamos en una notificación abrimos la aplicación asociada, aunque el uso más común es leerlas y descartarlas.
La notificación es un canal asíncrono con el usuario, pero más directo que otros medios porque aparece como alerta en un dispositivo que el usuario lleva consigo y usa con frecuencia. Para diseñar una notificación conviene conocer que valoran los usuarios de nuestro servicio, y adaptarla a sus intereses y rutina diaria.
Consideraciones al diseñar una notificación
Cuando enviarla
Evita interrupciones
El sistema de notificaciones está diseñado para que el usuario tenga el control. Si la notificación interrumpe al usuario sin ofrecer valor, el usuario se sentirá molesto y silenciará o desinstalará la aplicación.
Las notificaciones se perciben como más disruptivas* cuando
- El usuario está ocupado.
- La respuesta requiere una acción compleja.
- El remitente no es una persona, o es un desconocido.
- La información no es útil en ese contexto.
Usa badges
Las notificaciones inoportunas son la primera causa de desinstalación de aplicaciones. Si tus notificaciones no están justificadas, no las envíes o rebájalas a “badges” (el numerito en el icono de la app).
Pide pre-permiso
La petición de permisos para notificaciones debe vincular el permiso con un beneficio para el usuario. Para ello conviene solicitar permisos como parte de una tarea que el usuario realiza, o escribir mensajes personalizados que reflejen el beneficio.
Si el usuario deniega permisos a la aplicación móvil, la aplicación no puede preguntar de nuevo, y es necesario que el usuario otorgue permisos en los ajustes del dispositivo. Para evitarlo, es práctica común preguntar si el usuario desea recibir notificaciones con un dialogo de aplicación, y solo en caso afirmativo lanzamos el dialogo del sistema. Esto requiere dos clicks en vez de uno, pero si la primera pregunta es negativa podremos solicitar permisos en otro momento.
Copy
La comunicación debería ser concisa, clara, original, y subordinada a un objetivo. La longitud del texto disponible es 4k en Android y 2k en iOS, aunque rara vez deberías usar más de un par de frases.
Si tu objetivo es influenciar la conducta hay dos estilos:
- Racional (“hard sell”): enuncia un beneficio tangible del producto e insta a la acción.
- Creativo (“soft sell*”): asocia el producto a cualidades ajenas como emociones, o un estilo de vida. Por ejemplo haciendo reír “te echo de menos, vuelve, ¡puedo cambiar!”, asustando “haz esto o sufre las consecuencias” etc. Es el usado por productos sin rasgos diferenciadores, o difíciles de describir, como perfumes.
Personalización
La personalización aporta credibilidad, el mensaje está dirigido a nuestras necesidades, y demuestra un esfuerzo extra. Podemos personalizar en base a una acción del usuario, cualquier hecho cercano, o simplemente el nombre.
A|B Testing
El A|B Testing consiste en comparar dos versiones de algo para ver cuál cumple mejor su objetivo. Hay varios modos de hacerlo, por ejemplo podemos enviar dos notificaciones distintas a parte de nuestra audiencia, medir que versión recibe más interacciones, y enviar la versión ganadora al resto del público.
Tener un objetivo claro para una funcionalidad es un pre-requisito para establecer unos indicadores de éxito, y entender si la funcionalidad implementada contribuye al éxito global del producto. Este es un aspecto clave del desarrollo de cualquier producto.
Throttle
Si hay varias notificaciones del mismo tipo, combinalas para no acaparar la pantalla.
Opciones de implementación
Si envías mensajes a Android e iOS, tendrás que comunicarte con el servidor APNS de Apple, y el FCM connection server de Google. Para ello sería deseable
- usar una API común para ambos sistemas,
- con una implementación de terceros que nos abstraiga de cambios en estos servidores,
- y coste bajo o cero.
Hay dos opciones
- Un componente en nuestro servidor. Desventaja: habrá que actualizarlo periódicamente.
- Un API a una plataforma de terceros. Desventaja: lo pagaremos en dinero o cediendo los datos anonimizados de nuestros usuarios.
Componentes en servidor
URL | Multiplataforma | Lenguaje | Open Source | Licencia |
Pushy | iOS | Java | sí | MIT |
Java-APNS | iOS | Java | sí | MIT-like |
Aerogear | iOS + Android | Java y Node | sí | Apache |
Plataformas
URL | Multiplataforma | SDK | Precio |
Firebase Cloud Messaging | sí | REST | gratis o casi |
OneSignal | sí | REST | datos anonimizados |
Urbanairship | sí | REST | $99/0-10,000 |
Amazon SNS | sí | Varios | $1/millón o menos |
* Firebase Cloud Messaging es el nuevo nombre de Google Cloud Messaging for Android (GCM).
Hay muchas plataformas de notificaciones porque la funcionalidad básica puede montarse sobre componentes de código abierto. La competencia está en la diferenciación.
Diferenciación
Funcionalidades extra que ofrece Urbanairship:
- Editor web de mensajes
- A|B testing
- Personalización de mensajes (parametros para usuarios)
- Segmentación por localización geográfica o dispositivo
- Estadísticas
Una de las plataformas ofrecía un editor de interfaces nativos, que se muestran en respuesta a notificaciones. Esto requería adjuntar un framework de la plataforma.
Conclusión
Amazon SNS me parece la mejor opción porque
- Es una plataforma de terceros que nos da un interfaz común y nos aísla de los cambios en los servidores de push.
- Es de pago y muy barato. Esto implica que no tendrémos que pagar cediendo datos como otras opciones “gratis”, lo cual tendría implicaciones legales.
- Tiene soporte en varios lenguajes y plataformas.
- Es una solución escalable.
- No necesitamos funcionalidades extra.
Mecánica de envío de una notificación
En todos los casos hay tres actores:
- Una aplicación cliente que recibe notificaciones.
- Una aplicación servidor que envía notificaciones a través de un servidor de push.
- Un servidor de push que remite al cliente las notificaciones enviadas por el servidor.
Y su relación sigue estos pasos:
- El usuario otorga un permiso explícito al cliente.
- El cliente envía a la aplicación servidor un identificador.
- La aplicación servidor envía una notificación al servidor de push, que utiliza el identificador de cliente para localizarlo y enviarle una notificación.
iOS
El servidor push de Apple se llama APNS (Apple Notification Service).
Para que la aplicación servidor se comunique con el servidor APNS necesita el certificado SSL del desarrollador de la aplicación móvil, y un token único de cada instancia de la aplicación móvil. Esto le permitirá tener permiso para enviar, y saber a quien enviarle.
El funcionamiento general sigue estos pasos:
- La aplicación móvil arranca y recibe automáticamente un token del servidor APNS de Apple que envía las notificaciones.
- La aplicación móvil envía este token a la aplicación servidor mediante una llamada HTTP.
- La aplicación servidor envía una notificación al servidor APNS de Apple.
- El servidor APNS envía la notificación al dispositivo móvil.
El servidor de notificaciones de Apple no garantiza el orden de envío, y puede descartar notificaciones si las recibe demasiado rápido. Apple notifica fallos en el envío, pero no fallos por descarte.
Android
El servidor de notificaciones de Google se llama Firebase Cloud Messaging (FCM).
- La aplicación Android envía un identificador de desarrollador y un identificador de aplicación al servidor FCM.
- El servidor FCM devuelve al dispositivo un identificador de registro.
- La aplicación cliente envía el identificador de registro a la aplicación servidor.
- La aplicación servidor envía la notificación y el identificador de registro al servidor FCM.
- El servidor FCM envía la notificación al dispositivo.
Web
Mozilla y Chrome usan la Push API, que funciona así:
- El sitio web pide permiso al usuario y registra un service worker (un script que será ejecutado cuando llegue la notificación).
- Si el usuario otorga permiso el sitio web obtiene un token de dispositivo y lo envía a la aplicación servidor.
- La aplicación servidor hace un POST del token de dispositivo al servidor de push, que es propiedad del fabricante del navegador.
- El servidor de push envía la notificación.
- El navegador la recibe y ejecuta el service worker.
Safari usa el servidor APNS de Apple. Su funcionamiento similar pero más complejo. Hay que registrarse como desarrollador con Apple. Las notificaciones se envían como zips que contienen json y recursos gráficos. Hay más detalles en Notification Programming Guide for Websites.
Safari también permite notificaciones locales. Se invocan mediante javascript, funcionan solo mientras la página está activa, y usan el estandar Web Notifications.
Hola!!!
Pregunta: Cuál es la forma más simple para implementar notificaciones push, para IOS y ANDROID?
He utilizado ANDROIDCREATOR, pero deseo realizar apps con notificaciones push y lograr algo más de control sobre las mismas!!!
Gracias
Edgardo