¿Los usuarios de tu app no te dejan reviews en el App Store?
O peor aún: sí lo hacen, pero sólo para dejarte una estrellita cuando algo ha dejado de funcionar.
Lo tienes claro: te cuesta muchísimo que tus usuarios valoren tu aplicación, y sabes que hoy en día tener buenas valoraciones es fundamental para aumentar el número de descargas y mejorar la confianza percibida por el potencial usuario.
En este video voy a darte unos consejos sobre cómo y cuándo solicitar una reseña (review) a tus usuarios, y así plagar tu aplicación de valoraciones de 5 estrellas.
SKStoreReviewController (gracias Apple)
Antes de iOS 10 para solicitar una review teníamos que crear nuestros propios UIAlertViews o acudir a servicios de customer love, como por ejemplo, Apptentive.
Hoy en día ya no es necesario ya que Apple nos proporciona una clase de forma nativa. La clase se llama <strong>SKStoreReviewController</strong> y es la que vamos a utilizar en este video. De hecho, a partir de abril 2020, toda app que pida reviews sin utilizar este API serán rechazadas en el AppStore.
Tenemos que conocer 2 peculiaridades sobre esta clase si queremos utilizarla correctamente y sacarle el mayor provecho:
- Esta clase sólo mostrará la solicitud al usuario 3 veces en un período de 365 días. Es decir, que aunque la quisieras utilizar 100 veces, a partir de la tercera vez dejará de aparecer hasta que pase un año natural.
- El sistema NO mostrará la alerta si «cree» que no ha pasado tiempo suficiente entre tu anterior solicitud y la nueva.
Teniendo en cuenta estas dos características, te tienes que asegurar de escoger perfectamente el timing a la hora de mostrar la alerta. Es decir, cuándo puedes estar (más o menos) seguro/a de que si solicitas una review, tus usuarios dejarán una valoración y ésta, además, será muy buena.
Vamos a poner un ejemplo estúpido pero creo que efectivo: imagina que vives en el mundo de The Walking Dead, con los zombies o caminantes, y uno de ellos viene a por ti. Tienes una pistola con únicamente 3 balas. O aciertas en la cabeza con alguna, o estás muerto. ¿No intentarías asegurarte de que vas a acertar antes de malgastar tus balas?
¿Qué NO debes hacer?
Primero te voy a contar qué 3 cosas NO DEBERÍAS HACER JAMAS si no quieres malgastar tus balas:
- No pidas a tu usuario que valore tu app nada más abrir la aplicación. ¿No te ha pasado alguna vez que al descargar una app y abrirla por primera vez ya te solicitan una review? ¡Si ni siquiera me ha dado tiempo a probarla!
- No interrumpas al usuario. Imagina que estás escribiendo un mensaje de WhatsApp importante y, de repente, te aparece una alerta que te bloquea la aplicación hasta que dejes una valoración o le des a Cancelar. ¿No te molestaría que te interrumpiesen?
- No seas pesado. Si pides a tu usuario que te valore cada 2×3 tu app lo único que vas a conseguir es influir negativamente en la percepción que tiene sobre ésta. Y además, deberás esperar un año para tener una nueva oportunidad.
¿Qué SÍ debes hacer?
Si quieres estar más o menos seguro de que al solicitar una valoración a tu usuario, éste te la deje y además sea una buena valoración (4 o más estrellas), debes escoger el momento perfecto para hacerlo. Y, también, el tiempo necesario que debe transcurrir antes de solicitarla por primera vez, o entre una solicitud y la siguiente.
Paso 1: Escoger el momento perfecto tras el cual solicitar una valoración:
Párate a pensar un par de minutos en el problema o problemas principales que soluciona tu app.
Quédate con aquél en el que tu usuario siente la mayor satisfacción. Yo lo llamo, Momento de Mayor Satisfacción (MMS). Ese momento en el que tu usuario consigue aquéllo que fue a hacer a tu app.
Como todo se entiende mejor con ejemplos, voy a darte 3 diferentes dependiendo del tipo de aplicación.
- En el caso de que tu app sea un juego, el Mayor Momento de Satisfacción (MMS) es cuando el usuario pasa un nivel con éxito
- Si es una aplicación bancaria, cuando el usuario realiza una transferencia con éxito
- Una aplicación bien conocida por todos: Airbnb. En este caso, el MMS será cuando el usuario reserva su alojamiento con éxito
¿Has visto qué palabra se repite en todos los ejemplos?
Éxito.
Localiza en tu app esos momentos de éxito y solicita la review SÓLO cuando tu usuario haya alcanzado el objetivo principal que fue a hacer a tu app.
Paso 2: Escoger el intervalo de tiempo adecuado
Ahora ya sabes que sólo debes solicitar la review tras ese momento éxtasis o Momento de Mayor Satisfacción (MMS) en tu app.
Tu trabajo ahora es escoger cuánto tiempo vas a esperar para solicitar la review por primera vez, o cuánto tiempo debes dejar pasar entre solicitud y solicitud.
Mi experiencia personal me dice que tendrás más valoraciones de 5 estrellas si esperas hasta que tu usuario tenga cierto engagement con la aplicación.
¿Qué es el engagement?
Engagement, en inglés, significa compromiso o noviazgo.
En el mundo de las apps se suele utilizar cuando el usuario ha experimentado ese noviazgo, ese enganche hacia tu app. Ese momento de «oh dios mío qué genial es esta app».
En resumen, lo que tienes que hacer es combinar estos dos puntos y solicitar una review solamente cuando tenga ya cierto engagement y tras haber tenido una experiencia de éxito en la app.
> Con ejemplos se entiende mejor. Si se trata de un juego y el usuario pasa el primer nivel, probablemente todavía no tenga engagement suficiente como para valorar con 5 estrellas la aplicación. Sin embargo, si ya se ha pasado varios niveles, puedes suponer que sí lo tiene. En ese momento, cuando se pase el siguiente nivel, le solicitas la valoración.
Manos al teclado: Xcode
Vamos a construir una aplicación de Reserva de alojamientos, tipo Airbnb.
Lo primero que hay que hacer es definir los eventos que vamos a utilizar para calcular cuándo mostrar la alerta:
- En este caso, el MMS o Momento de Mayor Satisfacción que he elegido es cuando el usuario reserve correctamente una casa.
- Para medir el engagement, voy a utilizar el número de veces que el usuario abre la aplicación.
enum ReviewEvent: String {
case bookHouse
case launchApp
}Lo siguiente que necesito es un objeto que me permita guardar y leer el número de veces que ocurre cada evento. Para ello creo un protocolo llamado ReviewManagerProtocol:
protocol ReviewManagerProtocol {
func log(_ event: ReviewEvent) // Write
func count(of event: ReviewEvent) -> Int // Read
}Para la implementación del ReviewManager elegí UserDefaults como mecanismo de persistencia, aunque tú puedes escoger el que quieras.
Gracias a haberlo creado como un protocolo, los detalles de implementación quedarán ocultos y si en el futuro decidimos cambiar UserDefaults por MySQL, Realm, CoreData u otro, no tendremos que cambiar ni una sóla linea de código allá donde usemos nuestro ReviewManager 😜.
final class ReviewManager: ReviewManagerProtocol {
// UserDefaults as persistence engine
private let engine = UserDefaults.standard
// MARK: - ReviewManagerProtocol
// Write
func log(_ event: ReviewEvent) {
let current = count(of: event)
engine.set(current + 1, forKey: event.rawValue)
}
// Read
func count(of event: ReviewEvent) -> Int {
return engine.integer(forKey: event.rawValue)
}
}La app de prueba tendrá únicamente un UIViewController que muestra el detalle de un alojamiento y tiene un botón para reservarlo.
Ahora vamos a utilizar la clase ReviewManager en nuestro ViewController, y medir o trackear los eventos que hemos definido.
Lo ideal, sería inyectar el ReviewManager mediante el método init de nuestro controlador, aunque para no despistar del objetivo principal del post, vamos a instanciarlo directamente:
final class ViewController: UIViewController {
private let reviewManager: ReviewManagerProtocol = ReviewManager()
override func viewDidLoad() {
super.viewDidLoad()
// Log the number of times the app is launched
reviewManager.log(.launchApp)
}
@IBAction func bookHouse(_ sender: Any) {
// Log the number of times a house is booked
reviewManager.log(.bookHouse)
}
}Ahora que ya mido los eventos que utilizaré para lanzar la solicitud de review, es hora de definir el momento ideal. Para ello, voy a combinar las dos recomendaciones que os expliqué más arriba: esperaré a que el usuario tenga cierto engagement y lanzaré la solicitud después del momento de éxito (después de que reserve la casa satisfactoriamente).
- Voy a suponer que el usuario ya tiene engagement cuando utiliza 3 veces la app (
.launchApp) - Tras la primera reserva con éxito (
.bookHouse), le voy a mostrar la alerta.
Ten en cuenta que para tu app estos números pueden ser mucho mayores. Añade import StoreKit al principio del fichero, y en el método bookHouse(sender:) añade lo siguiente:
@IBAction func bookHouse(_ sender: Any) {
// Log the number of times a house is booked
reviewManager.log(.bookHouse)
// Check if the prompt should be displayed
let launchedCount = reviewManager.count(of: .launchApp)
let bookedCount = reviewManager.count(of: .bookHouse)
if launchedCount > 2 && bookedCount > 0 {
SKStoreReviewController.requestReview()
}
}Si el usuario decide no dejar una review esta vez, debemos esperar un cierto tiempo antes de volver a enviar el mensaje SKStoreReviewController.requestReview(). Para ello, vamos a añadir un método a nuestro ReviewManagerProtocol para resetear la cuenta de un determinado evento. En este caso, resetearemos el evento .launchApp.
protocol ReviewManagerProtocol {
func log(_ event: ReviewEvent)
func count(of event: ReviewEvent) -> Int
func reset(_ event: ReviewEvent)
}final class ReviewManager: ReviewManagerProtocol {
...
func reset(_ event: ReviewEvent) {
engine.set(0, forKey: event.rawValue)
}
}Y utilizamos este nuevo método en el método bookHouse(sender:) tras haber mostrado la alerta:
@IBAction func bookHouse(_ sender: Any) {
// Log the number of times a house is booked
reviewManager.log(.bookHouse)
// Check if the prompt should be displayed
let launchedCount = reviewManager.count(of: .launchApp)
let bookedCount = reviewManager.count(of: .bookHouse)
if launchedCount > 2 && bookedCount > 0 {
SKStoreReviewController.requestReview()
// Reset the number of times the app is launched
reviewManager.reset(.launchApp)
}
}Si el usuario ha utilizado la app por lo menos 3 veces y logra reservar con éxito un alojamiento, el sistema le preguntará si quiere dejarnos una review en el AppStore.
«Fórmula 5 estrellas» GRATUITA
Hay ocasiones en las que calcular correctamente los valores de umbral es difícil, especialmente el de de launchApp.
Y lo que ocurre es que solemos gastar nuestras balas muy rápido, cuando el usuario no siente todavía ese enganche suficiente hacia nuestra app como para querer dejarnos una valoración. Por ello, he creado una fórmula para calcular estos valores y que os sirvan de referencia.
Descarga GRATIS mi Fórmula 5 Estrellas
He creado una fórmula para calcular cada cuántos días deberíamos preguntar a nuestros usuarios que nos dejen una review en el AppStore, basado en el tipo de uso de la app. Te la regalo TOTALMENTE gratis. Déjame tus datos y te la envío a tu email : )
Conclusión
Con la clase SKStoreReviewController es realmente sencillo solicitar una review. No tenemos que crear nuestra propia alerta ni obligar al usuario a abandonar la app para valorar la aplicación. Con una única linea de código, Apple hace todo por nosotros.
No obstante, hemos visto las limitaciones de esta clase. Por lo que es muy conveniente elegir cuándo utilizar el método requestReview() si queremos «asegurarnos» que el usuario quiera dejarnos una review, y que ésta sea positiva.
¿Y tú? ¿Qué otra estrategia utilizas para mejorar las valoraciones de tus apps? Cuéntamelo en los comentarios 😃
También puedes escribirme en Twitter en @xandrefreire o en mi canal de YouTube.