Feedback in-app que la gente sí responde

El feedback in-app es una pregunta hecha dentro de tu propio producto, en un momento que tú eliges, a un usuario al que ya puedes identificar. Ese control es toda la ventaja frente a cualquier otro canal, y también la razón de que un aviso mal cronometrado haga más daño que no preguntar nada.

Una app móvil sabe algo que ninguna encuesta por correo sabrá jamás: exactamente qué estaba haciendo la persona un segundo antes de que apareciera la pregunta. Aprovecharlo bien marca la diferencia entre un aviso que devuelve señal de producto y otro que devuelve una reseña de una estrella. El diseño de preguntas en general está en cómo crear una encuesta online; esta guía va sobre la pantalla pequeña y sobre la nota pública que puedes estropear.

El feedback no es el aviso de valoración de la tienda

Si te llevas una sola cosa de este artículo, que sea esta. La encuesta in-app y el aviso de reseña de la tienda son dos mecanismos distintos con dos trabajos distintos, y confundirlos es el error más común de los equipos móviles.

El aviso de reseña es el diálogo del sistema operativo, solicitado por StoreKit en iOS o por la In-App Review API en Android. La plataforma, no tu app, decide si aparece siquiera, y ambos fabricantes limitan cuántas veces lo ve un usuario. El resultado es una valoración pública que no puedes leer por adelantado, ni responder en privado, ni seguir. La encuesta in-app es tuya: aparece cuando tú lo dices, pregunta lo que has escrito y la respuesta llega en privado con el contexto que le adjuntaste, así que puedes ramificar, derivar y contestar.

El fallo típico es cablear el aviso de la tienda en un sitio donde en realidad querías recoger información. Un ingeniero añade el diálogo porque son cuatro líneas de código, y el producto pasa a tener un generador de valoraciones apuntando a una muestra aleatoria de usuarios, incluidos los que acaban de fallar un pago. La cuota lo empeora, porque cada aviso gastado en alguien molesto es un promotor al que ya no llegarás. Nunca dispares el aviso de la tienda desde una señal negativa o desconocida. Cualifica antes con tu propia pregunta y ofrece el camino a la tienda solo a quien acaba de decir que está contento.

Cuándo preguntar

El timing hace más por la tasa de respuesta in-app que la redacción, el diseño y los incentivos juntos. El principio detrás de todo buen momento es el mismo: pregunta cuando el usuario acaba de terminar algo y no tiene nada más entre manos.

El momento más fuerte es la pantalla de éxito: el pago pasó, el archivo se exportó, el viaje terminó, el nivel se completó. La atención sale gratis porque la tarea está hecha, y el recuerdo del recorrido sigue intacto. Pregunta uno o dos segundos después de que aparezca esa pantalla, no tres pantallas más tarde.

El segundo es un hito, no una acción: la séptima sesión, el final de la primera semana, la primera renovación. Los hitos van bien con preguntas sobre el producto en conjunto, son la casa natural de una encuesta de pulso periódica y garantizan que la persona tenga experiencia suficiente para opinar. El tercero es un ticket de soporte resuelto, el disparador más limpio que existe porque la experiencia valorada tiene un límite obvio, y donde una pregunta de esfuerzo de la familia del customer effort score gana a una de satisfacción.

Los malos momentos enseñan más. Nunca preguntes al abrir la app. Un aviso en el arranque en frío interrumpe a alguien que llegó con una intención y todavía no ha hecho nada, así que no hay nada sobre lo que dar feedback. Produce tasas bajas, mal sentimiento y a veces justo la desinstalación que intentabas evitar. Una sesión abierta desde una notificación push es el mismo caso: la notificación ya se gastó tu presupuesto de interrupción.

Nunca preguntes en mitad de una tarea. Ni durante el pago, ni sobre un formulario a medias, ni durante una partida o un vídeo. Interrumpir algo sin terminar te cuesta dos veces: un descarte en lugar de una respuesta, y más probabilidad de que la tarea se abandone.

Hay dos zonas rojas menos evidentes. La primera es justo después de un fallo de la app. Resulta tentador, porque tienes a alguien con una opinión intensa, pero una valoración ahí mide tu gestión de errores e invita a una queja pública; lo que corresponde tras un fallo es una pregunta diagnóstica estrecha sobre qué intentaba hacer. La segunda es el muro de pago, porque el feedback recogido junto a un precio queda contaminado por el precio. Los usuarios de una versión recién publicada son un tercer caso: reaccionan a la novedad en vez de juzgar el producto, así que deja que una versión se asiente antes de reanudar los avisos.

Los patrones de aviso y dónde encaja cada uno

Hay cinco formas habituales de sacar una pregunta en una app, cada una con su nivel de interrupción. Ajustar el patrón al momento es lo que evita que un programa de feedback se sienta como una insistencia.

La tarjeta emergente desde abajo es el caballo de batalla: una pregunta, sin bloquear el contenido de detrás, se descarta con un gesto. Es el valor por defecto correcto tras una acción completada, porque respeta que el usuario quizá no quiera hablar hoy, y aquí tiene la mejor relación entre respuestas y molestia. Por eso la microencuesta se convirtió en el estándar móvil.

El aviso a pantalla completa ocupa toda la pantalla. Consigue más finalización una vez abierto y cuesta mucho más cuando cae mal, así que resérvalo para momentos terminales: un hito, el cierre del onboarding, un flujo de cancelación. Conviértelo en tu opción por defecto y en dos semanas los usuarios lo cerrarán por reflejo. El bloque en línea es lo contrario, una tarjeta entre elementos de un feed. Nunca interrumpe, y aunque el volumen es menor las respuestas son voluntarias de una forma que las hace útiles.

El acceso permanente es un «Enviar comentarios» en los ajustes o en el menú de ayuda. Es pasivo, así que domina la minoría motivada y la muestra se escora hacia las quejas fuertes y los entusiasmos fuertes por igual. Aun así es obligatorio: toda app necesita un sitio al que un usuario frustrado pueda llegar sin salir hacia la tienda, y su ausencia es causa directa de reseñas de una estrella que deberían haber sido un ticket. El gesto de agitar abre un formulario de reporte al sacudir el dispositivo, excelente en versiones beta y pruebas internas, sobre todo con captura automática. En producción es de nicho: hay que anunciarlo para que se descubra y necesita un interruptor en ajustes, porque los disparos accidentales molestan.

Patrón	Interrupción	Ideal para	Preguntas que soporta
Tarjeta emergente	Baja	Satisfacción justo tras una acción completada	Una, más un seguimiento condicional
Aviso a pantalla completa	Alta	Hitos, cierre del onboarding, cancelación	Dos o tres, con un final visible
Bloque en línea en un feed	Ninguna	Preguntas de fuego lento en apps de contenido	Una, autocontenida
Acceso en ajustes	Ninguna, la inicia el usuario	Quejas, reportes de error, peticiones de función	Texto libre más una categoría
Agitar para reportar	Ninguna, la inicia el usuario	Betas, pruebas internas, usuarios avanzados	Texto libre más una captura
Aviso de la tienda	Alta, y con cuota	Usuarios que ya dijeron estar contentos	Ninguna, recoge una nota pública

Elijas el patrón que elijas, descartarlo tiene que ser trivial. Un aviso sin un control de cierre visible convierte una irritación leve en la reseña pública que intentabas evitar.

Redactar una pregunta que quepa en una pantalla de móvil

La restricción que nadie planifica es física. Una tarjeta emergente te da una pregunta corta y una fila de respuestas antes de que el pliegue o el teclado se coman el resto.

Mantén la pregunta por debajo de unos sesenta caracteres y nombra aquello por lo que preguntas. Un «¿Qué tal lo hacemos?» a secas devuelve una respuesta sobre algo que no puedes identificar, mientras que «¿Qué tan fácil fue enviar esa transferencia?» fija el alcance y produce algo comparable entre miles de respuestas. Si el aviso salta en una pantalla concreta, refiérete a esa pantalla; en un hito, refiérete a la app entera. Nunca mezcles las dos cosas.

Las opciones de respuesta deben caber en una fila con áreas táctiles de al menos 44 puntos, lo que te limita a cinco o seis. Una escala de cinco puntos, una fila de caras o un par de pulgares funcionan igual de bien. Una fila NPS de once puntos no cabe en una pantalla estrecha sin encoger las celdas por debajo del tamaño del pulgar, así que divídela en dos líneas o llévala a un aviso de hito más holgado; la elección entre métricas de relación y transaccionales está desglosada en CSAT frente a NPS. Etiqueta los dos extremos, porque una fila de números pelados deja a la gente adivinando.

Evita meter la respuesta dentro de la pregunta. «¿Te molesta la música de fondo?» planta la idea de que debería; «¿Qué te parece el sonido de la app?» no. Este problema de pregunta dirigida es peor in-app, porque con una sola pregunta nada más corrige el sesgo. La lista de comprobación está en preguntas para un formulario de feedback. Redacciones que sobreviven al espacio disponible:

• ¿Qué tan fácil fue terminar eso? Una pregunta de esfuerzo de un toque, el mejor valor por defecto tras un flujo completado.
• ¿Cómo valorarías esta pantalla? Con un alcance lo bastante estrecho como para que la respuesta señale una pieza concreta de interfaz.
• ¿Qué estabas intentando hacer? La pregunta correcta tras un error, y la única que merece la pena hacer ahí.
• ¿Qué te falta? Una pregunta abierta para un hito, donde la gente ya tiene experiencia para responderla.
• ¿Qué estuvo a punto de impedirte terminar? Gana a «¿algún comentario?» porque pide algo concreto.

Cuántas preguntas caben in-app y cuándo enlazar fuera

Dentro de la app el presupuesto realista es una pregunta más un seguimiento condicional. No es una preferencia, es lo que soportan la pantalla y el momento. Tres es el techo, reservado a avisos de hito a pantalla completa donde el usuario ya aceptó al tocar algo.

El patrón que compra volumen y profundidad a la vez es en dos pasos: la valoración dentro de la app, donde el toque es casi gratis, y el detalle fuera. El seguimiento se ramifica, de modo que una nota baja pregunta qué salió mal y una alta pregunta qué conservar. Eso es lógica de ramificación corriente, y duplica el valor de un aviso de una sola pregunta.

Cuando de verdad necesitas cinco preguntas o más, enlaza a una encuesta web en un navegador dentro de la app. Arrastra la primera respuesta para que nada se pregunte dos veces, pasa el contexto como parámetros de URL y sé honesto con la longitud, porque prometer dos preguntas y servir nueve enseña a la gente a ignorar todos los avisos siguientes; la mecánica está en cómo reducir el abandono de encuestas. Pon primero la pregunta cerrada porque cuesta un toque, y deja opcional la pregunta abierta, un equilibrio expuesto en preguntas abiertas y cerradas. El texto libre obligatorio en un móvil recoge respuestas que dicen «asdf».

Derivar las respuestas negativas a soporte, no a la tienda

En el momento en que un usuario toca una nota baja tienes una ventana corta en la que el problema todavía es tuyo y se puede arreglar. Lo que pase a continuación decide si acaba siendo un ticket resuelto o una reseña pública.

Ramifica según la nota. Una respuesta negativa abre un seguimiento que pregunta qué salió mal y luego ofrece una vía real hacia una persona: un hilo de soporte, un reporte de error, una llamada, con el diagnóstico adjuntado en automático para que nadie tenga que describir su dispositivo. Una respuesta positiva toma la otra rama, y solo ahí tiene sentido una invitación a valorar en la tienda.

Dos cautelas mantienen esto honesto. La oferta de soporte tiene que ser real, porque derivar a los detractores a un formulario que no lleva a ninguna parte les confirma la sospecha de que nadie escucha. Y no escondas el camino del descontento: suprimir el feedback negativo quitando la salida es un diseño que no gusta ni a los reguladores ni a las tiendas de aplicaciones. La versión legítima es una bifurcación en la que ambas ramas llevan a algo útil y solo una menciona la tienda. Bien hecho, sube tu nota sin trampas, porque quien se queja en privado y recibe respuesta rara vez se queja en público, y los usuarios contentos a los que se pregunta en el momento adecuado dejan la reseña que de otro modo nunca existiría.

Límite de frecuencia, para que nadie reciba dos avisos al mes

Cada aviso gasta un poco de buena voluntad. El tope de frecuencia mantiene el saldo positivo, y su sitio es el código, no un documento de buenas intenciones, porque el usuario que más dispara tus eventos es justo el usuario avanzado al que menos te puedes permitir molestar.

Un juego de reglas que funciona: un aviso por usuario cada treinta o sesenta días, contando todas las encuestas juntas y no por campaña. Después de que alguien responda, amplíalo a noventa días como mínimo. Trata los descartes como señal, de modo que uno empuje la siguiente fecha elegible y dos seguidos silencien a ese usuario durante seis meses. Fija una antigüedad de cuenta y un número de sesiones mínimos para no preguntar nunca a los usuarios del primer día, y pausa todo durante una incidencia, cuando las respuestas medirían tu caída y no tu producto.

El muestreo es la parte infravalorada: sobre una base grande, mostrar el aviso a una fracción de los elegibles te da volumen suficiente dejando intacta a la mayoría de la audiencia, y nuestra nota sobre tamaño de muestra cubre cuánto necesitas. Guarda el estado de elegibilidad en el servidor y no solo en el dispositivo, porque los contadores locales se reinician al reinstalar y no viajan entre un móvil y una tableta, que es como alguien acaba viendo el mismo aviso tres veces en una semana. Esta es la cara operativa de la fatiga de encuestas, y se manifiesta como tasas de respuesta a la baja mucho antes de que nadie se queje.

Envía el contexto que ya tienes

La mejor pregunta es la que no tuviste que hacer. Cada dato adjuntado en automático es una pregunta menos en el aviso, lo que sube la finalización y mejora la exactitud a la vez, ya que tu telemetría gana al recuerdo del usuario. Pásalos como campos ocultos, por tu SDK o como parámetros de la URL de la encuesta:

• Versión y build de la app. El corte más útil en feedback móvil, convierte una caída difusa de notas en «la versión 4.2».
• Sistema operativo, versión y modelo de dispositivo. La mitad de los reportes de error se resuelven solo con esta línea.
• La pantalla donde saltó el aviso. Sin ella, «esto es confuso» no es accionable.
• Antigüedad de la cuenta, número de sesiones y plan. La misma queja significa cosas distintas viniendo de alguien de la primera semana o de un suscriptor de dos años.
• Idioma y tipo de conexión. Los reportes de lentitud suelen ser una historia de red antes que de código.
• Si la sesión contuvo un error. Separa «la app va bien» de «la app va bien cuando funciona».

Dos límites. Mantén los datos personales fuera de los parámetros de URL, porque los enlaces se reenvían y se registran, y pasa un identificador interno que no signifique nada fuera de tus sistemas. Y sé veraz sobre lo que adjuntas, porque un aviso que promete anonimato mientras lleva un ID de cuenta no es anónimo; nuestra nota sobre encuestas anónimas detalla lo que esa palabra exige.

Qué hacer con las respuestas

El feedback que aterriza en un panel que nadie abre es un coste sin retorno. La ruta que va de una respuesta a un cambio en el producto tiene que existir antes de encender el primer aviso.

Empieza por el triaje, idealmente diario. Las respuestas caen en unos pocos cubos: un error, una petición de función, un problema de usabilidad, una queja de precio o ruido. Los errores van directos al tracker con la versión y el dispositivo ya adjuntos, que es la recompensa de los campos ocultos. Las peticiones de función van a un backlog por temas con recuentos, porque el sentido de recoger cientos de respuestas es saber qué petición es frecuente y no cuál estaba formulada con más viveza. Los problemas de usabilidad son los más valiosos y los más fáciles de perder, porque llegan como frases y no como tickets.

Luego lee los números por versión y por pantalla. Una nota para toda la app es una métrica de vanidad; partida por versión te dice si la última entrega ayudó, y partida por pantalla te dice a dónde mandar a un diseñador. Agrupa el texto abierto en temas con recuentos para que el comentario más ruidoso no gane al más común, un proceso cubierto en análisis temático. Vigila también el propio aviso: los descartes al alza son el aviso más temprano de que preguntas demasiado. Mide la tasa de respuesta y la tasa de finalización por separado, porque un aviso abierto y nunca terminado es un problema distinto de uno que se ignora.

Por último, cierra el círculo, que en una app móvil es más fácil que en ningún otro sitio. Notas de versión que nombran lo que pidieron los usuarios, un aviso dentro de la app diciendo a quien reportó que el problema está resuelto, una respuesta al hilo que empezó siendo una nota baja: todo eso sube la tasa de respuesta del siguiente aviso, porque la gente contesta encuestas de productos que visiblemente escucharon la vez anterior. También hace menos probable que expresen la misma queja en público, que es el mecanismo silencioso detrás de la mayoría de las mejoras de nota que los equipos atribuyen al feedback.

Errores frecuentes

• Usar el aviso de la tienda como herramienta de feedback. Recoge una nota pública, no información, y cada aviso desperdiciado es un promotor al que ya no llegarás.
• Preguntar al abrir la app. El usuario todavía no ha hecho nada, así que no hay nada sobre lo que opinar.
• Interrumpir una tarea sin terminar. Un aviso sobre un pago te cuesta la respuesta y a veces la compra.
• Pedir una valoración justo tras un fallo. Eso mide tu gestión de errores e invita a una reseña de una estrella.
• Ocho preguntas en una tarjeta. La pantalla soporta una más un seguimiento; lo más largo va en una página enlazada.
• Sin salida. Un aviso que no se descarta de un toque convierte una molestia leve en una queja pública.
• Preguntar lo que ya sabes. Versión, dispositivo, plan y antigüedad van en campos ocultos, nunca en preguntas.
• Un tope guardado solo en el dispositivo. Las reinstalaciones y los segundos dispositivos reinician los contadores locales, y a los usuarios intensivos se les pregunta más.
• Recoger y luego callar. Nada mata la tasa de respuesta del próximo trimestre más rápido que la inacción visible sobre esta.

Montarlo sin un equipo de research

La parte de ingeniería es menor de lo que parece. Necesitas un disparador atado a un evento real, una superficie ligera donde dibujar la pregunta, una capa de reglas que decida la elegibilidad y un sitio donde caigan las respuestas con su contexto adjunto. La mayoría de los equipos tiene lo primero, construye lo segundo una vez, se equivoca en lo tercero y se salta lo cuarto.

La mitad de la encuesta no necesita código propio. Una encuesta alojada, abierta en un navegador dentro de la app, se ocupa de las preguntas, la ramificación, los campos ocultos y los informes, mientras tu app conserva solo el disparador y el límite de frecuencia. Así un programa se pone en marcha en días y no en sprints. Partir de una plantilla lista elimina la mayoría de los errores de redacción antes de que llegues a los de timing, y el argumento más amplio está en por qué los product managers necesitan encuestas.

SurveyNinja cubre esa mitad: lógica que manda las notas bajas y altas por caminos distintos, variables ocultas para versión de app, dispositivo y plan, diseños pensados primero para móvil que no hay que arreglar, e informes filtrados para comparar una entrega con la siguiente. El plan gratuito no tiene tope de respuestas, algo que importa más en móvil que en ningún otro sitio, porque un aviso lanzado a una base grande devuelve volumen en horas y una cuota es lo último que quieres tocar a mitad de ciclo de entrega; mira la página de precios. Monta la encuesta, conéctala a una sola pantalla de éxito y empieza con una pregunta.

Preguntas frecuentes

¿Qué es el feedback in-app?

Una pregunta hecha dentro de una app móvil o web en un momento que elige el producto, con la respuesta enviada en privado en lugar de publicada. Como la app sabe qué estaba haciendo el usuario, puede elegir el momento, adjuntar contexto como la versión y el dispositivo en automático y ramificar según la respuesta.

¿En qué se diferencia del aviso de valoración de la tienda?

El aviso de reseña es un diálogo del sistema operativo que escribe una nota pública dentro de una cuota de la plataforma, y no se puede leer ni responder en privado. Una encuesta in-app es tuya: controlas cuándo aparece, qué pregunta y a dónde va la respuesta, y nunca toca tu valoración.

¿Cuál es el mejor momento para pedir feedback en una app?

Justo después de una acción completada, en la pantalla de éxito, mientras la atención sale gratis y la tarea está fresca. Los hitos van bien con preguntas sobre el producto en conjunto, y un ticket de soporte resuelto va bien con una pregunta de esfuerzo. Nunca preguntes al abrir la app, nunca en mitad de una tarea y nunca pidas una valoración justo tras un fallo.

¿Cuántas preguntas se pueden hacer dentro de una app?

Una, más un seguimiento condicional. Tres es el techo, y solo para un aviso a pantalla completa en un hito. Si necesitas cinco o más, haz la valoración en la app y enlaza a una encuesta web, arrastrando la primera respuesta y el contexto para que nada se pregunte dos veces.

¿Con qué frecuencia debería ver un mismo usuario un aviso de feedback?

No más de una vez cada treinta o sesenta días contando todas las encuestas, ampliado a noventa días después de que alguien responda de verdad. Cuenta los descartes como señal y silencia a quien ignoró dos avisos seguidos. Guarda el estado de elegibilidad en el servidor, porque los contadores locales se reinician al reinstalar.

¿Qué debería pasar cuando alguien da una respuesta negativa?

Ramifica a un seguimiento corto que pregunte qué salió mal y luego ofrece una vía real hacia una persona, como un hilo de soporte o un reporte de error, con el diagnóstico adjuntado en automático. Nunca mandes a ese usuario a la tienda de aplicaciones. La rama positiva es el único sitio donde encaja una invitación a valorar.

¿Qué datos conviene adjuntar en automático a una respuesta in-app?

Versión y build de la app, sistema operativo y modelo de dispositivo, la pantalla donde saltó el aviso, antigüedad de la cuenta, número de sesiones, plan, idioma y si la sesión contuvo un error. Todo lo de esa lista es una pregunta que ya no tienes que hacer. Mantén los datos personales fuera de los parámetros de URL, y nunca llames anónima a una respuesta que lleva un ID de cuenta.

¿Qué patrón de aviso in-app funciona mejor?

Una tarjeta emergente con una sola pregunta es el mejor valor por defecto: poca interrupción, fácil de descartar y la mejor relación entre respuestas y molestia. Los avisos a pantalla completa encajan solo en hitos y cancelaciones, los bloques en línea encajan en feeds de contenido, y un acceso permanente en los ajustes debería existir en toda app.