¿Los usuarios de tu app no te dejan reviews en el App Store?
O peor aún: sí que lo hacen, pero 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 es fundamental tener buenas valoraciones para aumentar el número de descargas y mejorar la confianza percibida por el potencial usuario.
En este post voy a darte unos consejos sobre cómo y cuándo solicitar una review a tus usuarios, y así plagar tu aplicación de valoraciones de 5 estrellas. También te dejo el video tutorial más abajo ⬇️
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 SKStoreReviewController y es la que vamos a utilizar en este video.
Pero antes de entrar en materia 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 quieras usar 100 veces, a partir de la tercera dejará de aparecer hasta que se cumpla un año.
- 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, tienes que asegurarte 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 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:
- Ni pidas a tu user 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), debemos escoger el momento perfecto para hacerlo, y el tiempo necesario que debe transcurrir antes de solicitarla por primera vez o entre una solicitud y la siguiente.
a) Escoger el momento perfecto tras el cual solicitar una valoración:
Párate a pensar un par de minutos en el problema o problemas 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 aquello 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) puede ser cuando el usuario pasa de nivel con éxito
- Si es una aplicación bancaria, cuando el usuario realiza una transferencia con éxito
- Vayamos a 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.
b) Escoge 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. Ahora deberías escoger cuánto tiempo vas a esperar para solicitar la review por primera vez, o cuánto tiempo debes dejar pasar hasta volver a solicitarla en caso de que tu usuario haya decidido no evaluarla en tu anterior intento.
Como experiencia personal, 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 querer 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 ViewController que muestra el detalle de un alojamiento y tiene un botón para reservarlo.
ViewController
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), y 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. En el método bookHouse(sender:) añado:
@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 > 3 && bookedCount > 1 {
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 nuestro caso, resetearemos el .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.
La fórmula os la podéis descargar TOTALMENTE GRATIS.
⬇️ Video tutorial completo
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 ?
Por: Alexandre Freire
Alexandre es Software developer e instructor iOS en el Mobile Bootcamp Engineering de KeepCoding.
Aunque puedas haberlo visto impartiendo cursos de Android o de Ruby On Rails en el pasado, ahora está completamente enfocado en el desarrollo iOS, publicando artículos en su página web, o subiendo videos a su canal de YouTube. Alexandre vendió su propia startup (Apparcar) cuando tenía tan sólo 25 años, y según palabras textuales, su intención es “que no sea la última”.
También puedes seguir a Alexandre en Twitter en @xandrefreire
Post original escrito en alexandrefreire.com
Si tienes algo que deseas compartir o quieres formar parte de KeepCoding, escríbenos a [email protected].
