La API In-App Review de Android: pedir una valoración sin resultar molesto

La mayoría de los avisos de “valóranos” en Android son un diálogo personalizado con dos botones: uno abre la ficha de Play Store, el otro lo cierra. Aparecen al abrir la app, o tras un número arbitrario de sesiones, e interrumpen lo que el usuario estaba haciendo en ese momento. Quien pulsa “valorar” sale de tu app, llega a Play Store y ahora tiene que escribir una reseña desde cero — una fricción que mata la mayor parte de la intención que acabas de captar. Quien pulsa “ahora no” no te ha dicho nada, y probablemente volverás a preguntarle la semana que viene de todos modos.

La API In-App Review de Google resuelve la mitad mecánica de este problema: una hoja de valoración nativa que aparece sobre tu app, permite al usuario elegir estrellas (y opcionalmente escribir unas palabras) sin salir, y lo devuelve exactamente a donde estaba. No resuelve la mitad de UX — cuándo la activas sigue importando más que cómo — pero elimina la excusa de equivocarse en el “cómo”.

Cómo funciona en realidad

La API forma parte de Play Core (com.google.android.play:review-ktx). Solicitas un objeto ReviewInfo de antemano y luego lanzas el flujo cuando estás listo para mostrarlo:

val manager = ReviewManagerFactory.create(context)

manager.requestReviewFlow().addOnCompleteListener { request ->
    if (request.isSuccessful) {
        val reviewInfo = request.result
        manager.launchReviewFlow(activity, reviewInfo)
            .addOnCompleteListener {
                // The flow is finished — you don't get a signal on
                // whether the user actually rated. Treat this as "done,"
                // not "succeeded."
            }
    }
}

Dos detalles suelen sorprender. Primero, requestReviewFlow() puede fallar en silencio o devolver sin mostrar nunca un diálogo — Google limita la frecuencia con la que un mismo usuario ve esta hoja (aproximadamente una vez al año por app, sin documentación precisa y fuera de tu control), así que la mayoría de las llamadas en pruebas se completarán sin mostrar nada. Segundo, el callback de finalización se dispara tanto si el usuario valoró, como si la omitió, como si la cuota bloqueó el diálogo por completo. No existe un onRatingSubmitted — a propósito, para que las apps no puedan condicionar funciones ni insistir según el resultado.

La parte que realmente importa: el momento

Que la API sea fluida no ayuda si la activas en un mal momento. El fallo más común que veo es llamar a requestReviewFlow() justo después de onCreate(), bajo la teoría de que más impresiones significan más reseñas. Ocurre lo contrario: estás preguntando antes de que el usuario tenga ninguna opinión, y lo haces mientras está a mitad de la tarea que lo trajo a la app ese día.

El momento que funciona es justo después de que la app haya demostrado que cumple su función. Al construir Mintly, ese es el instante justo después de que termina una sesión de concentración y el usuario ve subir su racha — no la primera sesión, sino una en la que la app ya se ha ganado algo de confianza. Algunas reglas concretas que se cumplen en cualquier categoría de app:

• Actívala tras un resultado positivo completado, no en un número fijo de sesiones. Una app de presupuesto tras cerrar limpiamente un mes, una app de hábitos tras un hito de racha, una app de recordatorios tras un guardado genuinamente útil — no “sesión número 5”.
• Nunca la actives en una ruta de error. Si algo acaba de fallar o el usuario acaba de salir de un flujo, es el peor momento posible para preguntar.
• Límitate a ti mismo aunque la API ya te limite. La cuota de Google hace que la mayoría de las solicitudes no tengan efecto visible, pero tu propia lógica de activación debería igualmente evitar dispararse en cada evento que califique — una vez que el flujo se ha completado para un usuario, no vuelvas a llamarlo durante meses, aunque tu propio seguimiento no pueda confirmar si llegó a mostrarse.
• Nunca la combines con tu propio aviso previo. Un diálogo personalizado tipo “¿te está gustando la app?” que filtra el acceso al aviso real reintroduce exactamente la fricción de dos pasos que la API existe para eliminar, y te permite filtrar quién ve el aviso real — precisamente el tipo de manipulación que las normas de Play prohíben explícitamente.

Lo que no puede hacer, y lo que la gente intenta de todos modos

No puedes detectar si el usuario realmente dejó una valoración, leer el número de estrellas, ni redirigir a los usuarios descontentos lejos del flujo y a los satisfechos hacia él. Esto último es una petición habitual y va explícitamente contra la política de desarrolladores de Play — todo el sentido de la API es que cualquiera que la active vea la misma hoja sin filtrar. Si quieres un canal de soporte tipo “¿lo estás pasando mal?”, constrúyelo como un enlace de feedback separado y honesto, no como una bifurcación delante del aviso de valoración.

La otra limitación que conviene conocer: es exclusiva de Play. No existe una garantía equivalente en otras tiendas de apps para Android, y en ellas vuelves a depender de un enlace manual de “valóranos” o del mecanismo propio de la tienda.

Probarla sin agotar tu cuota

Como la cuota real es opaca, prueba con las herramientas de testing de Play Core en lugar de con tu build de producción — el artefacto de pruebas com.google.android.play:review-ktx y las pistas de uso compartido interno de apps te permiten activar el flujo repetidamente sin esperar la limitación real de Google. Conecta el disparador a un menú de depuración durante el desarrollo para poder lanzarlo a demanda, y luego elimina ese atajo antes del lanzamiento. En producción, trata cada llamada como fire-and-forget: solicita, lanza, continúa, y deja que la propia lógica de Google decida quién ve realmente la hoja.