Valoración baja en la tienda de apps: plan de reparación

Una valoración baja en la tienda de apps es un motivo para examinar las quejas recientes y decidir qué necesita una reparación, una explicación o una comprobación de las políticas. Empieza por la tarea que la persona que escribió la reseña no pudo completar y, si se conoce, por la versión que utilizó. El resultado útil es un plan de reparación con una persona responsable y una comprobación de la solución disponible.

Quizá tengas que responder a una consulta de soporte mientras la investigación sigue abierta. Limita la respuesta a lo que realmente sabes. Pedir más valoraciones, responder a una queja y reparar el producto son acciones independientes, con pruebas distintas para confirmar que se han completado.

¿Qué indica una valoración baja en la tienda de apps?

Una puntuación ofrece un punto de partida para investigar. Una queja escrita puede identificar la tarea afectada, pero todavía debes comprobar la causa. Anota qué tienda y qué mercado estás examinando antes de comparar valoraciones. Apple describe la valoración resumida de App Store como específica de cada territorio. La ayuda de Google Play Console distingue entre la valoración de Google Play, que da más peso a las valoraciones recientes, y la media histórica.

Si una valoración no incluye comentarios escritos, se desconoce el motivo. En una reseña publicada después de un lanzamiento también debes comprobar la versión antes de atribuirla a ese lanzamiento. Mantén visibles los datos que falten en vez de considerar la fecha como prueba de la compilación que utilizó la persona.

Crea un registro de quejas antes de elegir una solución

Utiliza la consola de tu propia aplicación con una cuenta autorizada. Si no puedes consultar los comentarios pertinentes, pide a la persona que gestiona ese acceso que realice la comprobación. Empieza por las quejas actuales y conserva su contexto. También conviene comprobar los informes antiguos cuando la misma tarea parece seguir fallando.

1. Abre la vista de reseñas correspondiente. La ayuda de Apple te dirige a Ratings and Reviews para la aplicación seleccionada en App Store Connect, con filtros por plataforma, país o región y versión de la aplicación. En Play Console, la ayuda de Google utiliza Ratings and reviews > Reviews, donde hay filtros que incluyen la fecha, el idioma, la versión de la aplicación y el dispositivo. Los controles varían entre plataformas.
2. Anota la tarea que se intentó realizar. Resume qué trató de hacer la persona y qué ocurrió según su relato. Separa ese relato de la explicación que propones. Marca como desconocidos la versión, el dispositivo o el estado de la cuenta cuando los comentarios disponibles no aporten esos datos.
3. Mantén un registro de trabajo mínimo. Anota la tienda, el mercado, la fecha de la reseña, la versión conocida, la tarea, el fallo observado, la información que falta, la persona responsable y la próxima comprobación. Usa una descripción anónima en una lista de trabajo compartida y guarda cualquier referencia necesaria a la fuente en un registro con acceso controlado. No copies nombres, datos de pedidos ni diagnósticos privados en una respuesta pública.
4. Agrupa las quejas comparables. Reúne los informes sobre la misma tarea, pero conserva las diferencias entre versiones y dispositivos. Un grupo es una pista para la investigación. No demuestra cuántos usuarios sufrieron el problema ni qué cambio lo causó.

Elige la siguiente acción a partir de la queja

Elige una comprobación que pueda resolver la incertidumbre del informe. Si una tarea que debería estar admitida falla, hay que reproducir el problema y decidir si se repara. Si una pantalla no está clara o la ficha de la tienda no coincide con el producto real, comprueba qué se prometió y cómo funciona la característica. Una solicitud de una función no admitida requiere una decisión sobre el producto y una explicación clara.

Ante un posible defecto, pide a la persona responsable que repita la tarea descrita en condiciones registradas. Utiliza las cuentas y los datos de prueba acordados, controlando los correos electrónicos, los cargos y otros efectos secundarios. Si no se reproduce, conserva las condiciones que probaste y la información que sigue faltando. Mantén el caso abierto hasta la siguiente comprobación pertinente.

Cuando la duda sea qué significa una pantalla o un botón, nuestra guía sobre una interfaz de aplicación confusa aborda esa observación más concreta. Vincula el registro de la queja con esa investigación en lugar de encargar un rediseño completo basándote únicamente en la media de estrellas.

Denunciar una reseña es otra vía con sus propias condiciones. Las directrices de Apple y la ayuda de Google sobre denuncias se refieren a infracciones de sus políticas. Indica la norma que se sospecha que se ha infringido y las pruebas antes de denunciar. Una opinión negativa no constituye por sí sola una infracción demostrada. La decisión de la tienda seguirá sin resolverse hasta que esta la tome realmente.

Repara la tarea y escribe una respuesta fiel a los hechos

Asigna la queja a una persona responsable y define una próxima acción que pueda comprobarse. Un traspaso útil explica qué falló, en qué condiciones conocidas, qué sigue sin saberse y cómo se comprobará la tarea modificada. Mantén en marcha la respuesta de soporte sin afirmar que el problema está resuelto si el cambio no se ha verificado o no está disponible.

1. Asigna la reparación o aclaración. Nuestras auditorías y mantenimiento de aplicaciones móviles empiezan por la tarea descrita y las pruebas disponibles. Incluye el resultado esperado, la compilación afectada si se conoce y la comprobación necesaria antes de cerrar el caso.
2. Comprueba el cambio implementado. Repite la tarea afectada en la versión aprobada y en condiciones comparables. Registra lo que observaste después de realizarla, incluido si el cambio se guardó cuando sea pertinente. Comprueba las rutas compatibles cercanas a las que el cambio podría afectar. Un resultado satisfactorio en otro dispositivo no resuelve un informe que sigue abierto.
3. Confirma la disponibilidad antes de anunciar una solución. Registra la versión publicada y quién puede obtenerla. Distingue entre una compilación interna de prueba, una versión aprobada y un cambio disponible para el usuario afectado. Si aún no se conoce la disponibilidad, indícalo en el registro de trabajo y en la respuesta.
4. Responde con hechos confirmados. Reconoce el problema descrito, indica la investigación real o el cambio disponible y ofrece una vía de soporte adecuada. La ayuda de Apple exige el rol Account Holder, Admin o Customer Support. Google exige el permiso Reply to reviews. Aunque una respuesta esté guardada, debes comprobar su estado de publicación.

La política de Google aconseja centrar las respuestas en el problema sin pedir una valoración más alta. Las directrices de Apple solicitan respuestas respetuosas, específicas y sin información personal. Mantén los datos de la cuenta y el seguimiento del diagnóstico en tu canal de soporte protegido habitual. Si esa vía utiliza una página de ayuda, comprueba que funciona desde la aplicación. El soporte y desarrollo web puede cubrir la parte web de esa vía.

Separa las solicitudes de reseñas del soporte

Las invitaciones para dejar una reseña requieren una comprobación independiente de la plataforma. No ofrezcas recompensas, compres opiniones ni condiciones la ayuda a que se modifique una reseña. La política de Google sobre valoraciones prohíbe las valoraciones fraudulentas o incentivadas. Las directrices de Android sobre reseñas dentro de la aplicación impiden preguntar por la opinión o por la valoración prevista antes de mostrar la tarjeta de reseña. Evita una ruta que envíe solo a las personas satisfechas a la tienda y desvíe a las insatisfechas hacia comentarios privados.

Las mismas directrices de Android describen un cuadro de diálogo de reseña sujeto a una cuota cuyo límite puede cambiar. Por tanto, llamar al flujo de reseñas no demuestra que alguien haya visto la tarjeta o enviado una reseña. Deja el trabajo detallado de implementación en manos del desarrollador. Una nueva invitación no resuelve la queja que estás investigando.

¿Qué debes comprobar después del lanzamiento?

Vuelve a la tarea y a los comentarios disponibles con las condiciones del lanzamiento a la vista. Registra si el fallo descrito se reprodujo antes del cambio, qué ocurrió después y qué queda sin probar. Examina las nuevas quejas utilizando, cuando sea posible, el mismo ámbito registrado de tienda, mercado y versión. Mantén la puntuación junto a estas observaciones sin utilizarla como prueba de la reparación.

Controla el resultado de la tarea afectada, las quejas sin resolver agrupadas por tema y el estado real de publicación de las respuestas pertinentes. Si cuentas las reseñas, conserva el intervalo de fechas y los filtros utilizados. El recuento solo describe esas reseñas. Compara el mismo ámbito en la siguiente revisión e investiga cualquier repetición en vez de suponer que el lanzamiento cerró todos los casos.

Un cambio de valoración después de un lanzamiento no demuestra qué lo causó. Según las directrices de Apple sobre valoraciones, al restablecer la valoración resumida con una nueva versión de la aplicación también se mantienen las reseñas escritas en App Store. Trátalo como una decisión independiente sobre la tienda después de entender los comentarios, no como el plan de reparación.

Cómo intervenimos

Empezamos por la queja, la tarea que la aplicación debe admitir y las pruebas necesarias para elegir la siguiente acción. Podemos convertir ese registro en un informe de reparación, comprobar la ruta modificada dentro de la aplicación e incluir su página de soporte cuando sea necesario. Lleva una descripción anónima de la tarea y del punto sin resolver a una conversación sobre el proyecto.

← Todos los artículos