Una mala actualización de la app puede desencadenar una ola de reembolsos, y así puedes contenerla antes de que llegue a tu pago

Cuando una versión se publica defectuosa, los reembolsos empiezan antes que tu panel de fallos. Una mala actualización de la app no solo molesta a la gente. Les da un motivo concreto para pedir la devolución de su dinero, y en una compra de bajo precio el dinero es la parte más pequeña de lo que pierdes. El cómputo que ya gastaste, las llamadas a API de terceros que te facturaron y el almacenamiento que aprovisionaste no vuelven con la venta.

Lo útil es que una versión defectuosa es uno de los pocos motivos de reembolso que puedes frenar en minutos, no en semanas. Ambas tiendas publican una actualización por etapas y te dejan detenerla a medio camino, y ese único control es la diferencia entre un puñado de usuarios afectados y una ola de reembolsos contra tu pago. Aquí tienes cuánto cuesta de verdad una ola de reembolsos, cómo detener una versión defectuosa en cada tienda y las dos breves ventanas que son tu única voz una vez que ya se ha presentado una disputa.

Por qué una mala actualización de la app se convierte en reembolsos

Un fallo al arrancar, un muro de pago que no carga, una función que ayer funcionaba y hoy no. Cada uno da a un cliente que paga un motivo claro para pedir la devolución de su dinero, y un reembolso es la versión educada de esa respuesta. La versión poco educada es un contracargo bancario. Ambos te cuestan, y una versión que falla aunque sea para una parte de tus usuarios puede generar suficientes como para aparecer en tu pago.

El dinero que pierdes es más que la venta

Cuando se reembolsa una compra, el importe de la venta vuelve al cliente. Lo que no vuelve es todo lo que ya gastaste para atender esa compra. El cómputo que ejecutó el trabajo, las llamadas a API de terceros que te facturaron en el momento de uso, el almacenamiento que aprovisionaste y cualquier pago que ya enviaste a un creador se pierden. En un consumible de bajo precio, esos costes hundidos más una posible comisión bancaria pueden sumar más de lo que el cliente pagó.

Una ola de reembolsos también mueve tu tasa de reembolsos

Los reembolsos no son solo una pérdida por venta. Las redes de tarjetas y ambas tiendas vigilan la tasa a la que se revierten tus ventas. Una sola versión defectuosa que dispara esa tasa puede atraer un escrutinio que preferirías evitar, así que el coste de una mala actualización incluye la reputación que gastas, no solo el dinero.

Cómo detener una versión defectuosa en la App Store

La herramienta de contención de Apple es la publicación por fases, y todo su valor está en que puedes echar el freno antes de que la mayoría de tus usuarios llegue a ver la compilación defectuosa.

La publicación por fases se despliega en siete días

Cuando activas la publicación por fases para una actualización de versión, Apple la entrega a una muestra aleatoria de usuarios que tienen activadas las actualizaciones automáticas. El despliegue sube según un calendario fijo: 1 por ciento el primer día, luego 2, 5, 10, 20, 50 y 100 por ciento a lo largo de siete días. Como los primeros días alcanzan a una fracción pequeña de tu base, un defecto detectado el segundo día ha llegado a mucha menos gente que la que alcanzaría una publicación completa el mismo día.

Pausa en cuanto algo parezca mal

Si una mala actualización de la app se cuela, puedes pausar la publicación por fases en cualquier momento. Apple te permite pausar hasta 30 días, sin límite en el número de pausas, y el presupuesto es acumulativo: pausa 10 días, reanuda y aún te quedan 20 días de pausa. Cuando reanudas, el despliegue continúa en el día en que se detuvo. Pausar no retira la compilación de los usuarios que ya la tienen, así que combina la pausa con una corrección y una revisión acelerada.

Cómo detener una versión defectuosa en Google Play

Google Play te da dos frenos, uno para una versión que aún se está desplegando y otro para una versión que ya llegó a todos.

Detén un lanzamiento por etapas en curso

Un lanzamiento por etapas en Google Play te deja publicar a un porcentaje de usuarios y subirlo según tu propio calendario. Si encuentras un problema, abre la versión y elige Gestionar lanzamiento y luego Detener lanzamiento. Ningún usuario adicional recibe la versión, y los usuarios que ya la tienen se quedan con ella. Si al final resulta que la compilación está limpia, reanudas el mismo lanzamiento desde donde se detuvo.

Detén una versión que ya llegó al 100 por ciento

Google Play también te permite detener una versión totalmente desplegada, algo que el freno del lanzamiento por etapas no puede hacer. Cuando la detienes, una versión anterior de tu app que estaba activa y totalmente desplegada ocupa su lugar automáticamente para los usuarios nuevos y existentes que aún no están en la compilación detenida. Importan dos límites: no puedes detener la primera versión de un canal, y si la versión defectuosa lleva activa el tiempo suficiente como para que la mayoría de los usuarios ya se hayan actualizado, detenerla sirve de poco, porque el daño ya está repartido.

Cuando los reembolsos y las disputas ya están en marcha

Escalonar un lanzamiento limita cuánta gente choca con una mala actualización de la app. No hace nada por los reembolsos y las disputas de los usuarios que ya la sufrieron. Una vez que un cliente pide la devolución de su dinero, la tienda ejecuta el proceso, y tu voz es limitada.

La mayoría de los reembolsos se deciden sin ti

El reembolso de autoservicio de 48 horas de Google Play, los reembolsos por soporte y las compras anuladas los decide todos la tienda según su propia política. No hay canal de pruebas ni apelación. Para esos, tu registro es el propio reembolso y el coste que ya asumiste. El único lugar donde puedes actuar es la prevención, que es justo por lo que importa el freno del lanzamiento.

Dos ventanas son tu única aportación

Solo dos procesos te piden algo. Cuando un cliente solicita un reembolso de un consumible o de una suscripción de renovación automática, Apple envía a tu servidor un CONSUMPTION_REQUEST y espera hasta 12 horas los datos de consumo. En Google Play, una compra en disputa que necesita revisión inicia un reloj de 24 horas, y respondes mediante la API orders.reviewrefund. Si dejas pasar cualquiera de las dos ventanas, la decisión se toma sin ti. Ninguna ventana te deja deshacer una mala versión. Solo te dejan responder a sus consecuencias.

La lista de contención

Nada de esto es exótico. Es una rutina breve que ejecutas en cada versión, no solo en las que esperas que fallen.

• Publica cada actualización mediante la publicación por fases en la App Store y un lanzamiento por etapas en Google Play, nunca un despliegue completo el mismo día.
• Vigila las señales de fallos y reembolsos durante los primeros días de bajo porcentaje, cuando la audiencia es lo bastante pequeña como para protegerla.
• Pausa la publicación por fases de la App Store o detén el lanzamiento de Google Play en cuanto aparezca un defecto real, y luego corrige y vuelve a enviar.
• Para un defecto que ya llegó a todos en Google Play, detén la versión totalmente desplegada para que la versión anterior ocupe su lugar.
• Configura los feeds de notificaciones de Apple y Google para poder responder a cada solicitud de consumo y a cada revisión de reembolso dentro de su ventana.
• Haz seguimiento de tu tasa de reembolsos a lo largo de la versión, porque un pico es la señal de que ya toca una reversión.