La primera vez que audité una app por ingresos perdidos, estuve a punto de informar que todo estaba bien. La tasa de reembolso estaba en 2.4%, un buen número según cualquier referencia. El equipo respondía las solicitudes de consumo dentro del plazo de Apple. Sobre el papel, no había nada que recuperar.
Luego ejecuté una consulta más, sobre todo por terquedad. ¿Cuántas personas tenían actualmente un derecho de acceso pagado sobre una transacción que Apple ya había reembolsado? Cuarenta y uno. En una app con aproximadamente 900 suscriptores de pago. La ejecuté dos veces porque no creía el resultado.
Eso es casi el 5% de la base usando el producto gratis, mes tras mes, mientras el dashboard se mantenía en verde. Y la tasa de reembolso nunca se movió. Documenté esa corrección de derechos de acceso por separado en cómo recuperar el acceso después de un reembolso.
Si estás tratando de descubrir cómo recuperar ingresos de suscripción perdidos por reembolsos de App Store, empieza por ahí, porque el reembolso es solo el más pequeño de los cuatro lugares a donde realmente va tu dinero. Aquí está el panorama completo.
Las cuatro categorías, ordenadas según su valor
Yo lo pienso como cuatro categorías, y el orden de esfuerzo contra beneficio no es lo que la mayoría imagina.
La fuga: usuarios reembolsados que nunca perdieron el acceso. La corrección más barata, la que más se pasa por alto.
La defensa: responder las solicitudes de consumo de Apple con evidencia. La categoría de la que habla todo proveedor, porque es la que el software puede automatizar.
El win-back: volver a captar a las personas que pidieron el reembolso o que cancelaron la suscripción. El que más tarda en dar resultados. Apple lo ha facilitado discretamente este año.
El reintento: fallas de facturación que se recuperan solas si no te interpones.
La mayoría de los equipos solo trabaja la categoría dos. Las sorpresas están en la uno y en la tres.
Categoría uno: encuentra la fuga, toma una hora
Esta es la consulta, a grandes rasgos. Toma cada transacción con una fecha de revocación en los últimos 12 meses, crúzala con tu tabla de derechos de acceso y cuenta a quiénes todavía les aparece el acceso activo.
Si la respuesta es cero, de verdad, sáltate esta sección. Pero si no lo es, has encontrado ingresos de suscripción que se escapan cada mes hasta que algo los detenga. Apple revierte su pago. Apple no toca tu base de datos. Ambas cosas permanecen desconectadas hasta que tú las conectes. Los consumibles son peores, porque una vez que se gasta un artículo no queda nada que StoreKit pueda reclamar.
(Yo mismo me equivoqué en esto durante meses. El manejador de notificaciones registraba los eventos REFUND en una tabla que nadie leía. Registrar no es lo mismo que gestionar.)
La solución: escucha el evento REFUND, revoca el acceso en la fecha de revocación y gestiona REFUND_REVERSED volviendo a otorgar el acceso. Apple a veces revierte sus propios reembolsos, después de una disputa del cliente, y no deberías castigar al cliente por eso.
Una consulta más ya que estás en eso. Cuenta los reembolsos en los que nunca recibiste ninguna notificación del servidor. Si eso no es cero, tu endpoint está roto, y la categoría dos también.
Categoría dos: defiende las solicitudes que todavía puedes influir
Apple te da unas 12 horas desde un CONSUMPTION_REQUEST para enviar los datos de consumo. Tres campos obligatorios, dos opcionales, una preferencia, y ahora cubre todo tipo de producto, no solo consumibles.
Mi consejo aquí es breve porque esta categoría ya se ha explicado hasta el cansancio en otros lugares. Responde todas las solicitudes. Rechaza aquellas en las que el producto claramente se entregó y se usó mucho. Concede las que fueron accidentes genuinos. Una concesión de buena fe sale barata. Pelear cada reembolso no, porque Apple pondera tu historial.
La dependencia que nadie menciona es la evidencia. Solo puedes defender lo que puedes demostrar. Si nadie puede responder "cuánto usaron realmente" sobre una compra de hace siete semanas, ninguna automatización te salva. Es un vacío en el modelado de datos que vale la pena cerrar sin importar el proveedor.
En cuanto al costo, cómo los reembolsos realmente le cuestan ingresos a tu app hace las cuentas, incluyendo el gasto de adquisición detrás de cada usuario reembolsado.
Categoría tres: recupera al suscriptor
Aquí es donde la protección de los ingresos de suscripción deja de ser defensiva. Y es el área que Apple ha reconstruido a tu favor durante el último año.
Las ofertas win-back. Nuevas desde WWDC24, iOS 18 en adelante. Las configuras por cada producto de suscripción en App Store Connect y defines la elegibilidad: duración mínima pagada, tiempo desde la última suscripción, una espera de 2 a 24 meses entre ofertas. Luego Apple se encarga de la distribución. Aparecen en la página de Administrar suscripción del cliente, en la página de tu producto, en recomendaciones personalizadas y, ocasionalmente, en espacios editoriales de la pestaña Today.
Lee eso dos veces. Apple le muestra tu descuento a un suscriptor que canceló en un lugar al que nunca podrías llegar por correo electrónico. Límites: 350 ofertas por suscripción, 5 activas por storefront. Dentro de la app, StoreKit emite un mensaje winBackOffer cuando alguien se vuelve elegible, y eligibleWinBackOfferIDs en la información de renovación muestra qué puede canjear. La guía de configuración de win-back de Apple cubre los campos de elegibilidad.
Las ofertas promocionales. Hasta 10 por suscripción, disponibles desde iOS 12.2, y requieren una firma JWS de tu servidor. Más trabajo que el win-back. Pero controlas por completo la segmentación, lo cual importa cuando los motivos de reembolso te indican algo específico, digamos un problema de precios en un país.
Los códigos de oferta. Canjeables dentro o fuera de la app. Eso los convierte en la única manera realista de llegar a alguien que pidió un reembolso y luego desinstaló la app. A todos los demás los puedes alcanzar dentro de la app. A estas personas, no.
Extender la fecha de renovación de una suscripción. La más subestimada, creo. La API de servidor de Apple te permite posponer la fecha de renovación de un suscriptor, en una transacción o en lote. La usamos como gesto de buena voluntad después de lanzamientos problemáticos: alguien le escribe a soporte sobre un error de facturación, le extiendes un mes, cuesta casi nada y supera a cualquier cupón. Un reembolso evitado vale más que un reembolso recuperado.
Una excepción. Si alguien pidió un reembolso por una sorpresa en la facturación y no por el producto en sí, no lo persigas con un descuento. Primero corrige el texto del paywall y luego deja que lo redescubra por su cuenta. La gestión de reembolsos de App Store cubre ese lado operativo.
Categoría cuatro: la cancelación que se corrige sola
Apple reintenta la facturación fallida durante hasta 60 días, o hasta que el cliente corrija su tarjeta o cancele. Si la suscripción se renueva dentro de ese plazo, el servicio pago continúa desde la fecha de recuperación.
Así que una parte de lo que parece ser ingresos de suscripción perdidos en realidad nunca se perdió. Estaba pendiente. Dos cosas lo arruinan: un período de gracia que nunca activaste y un correo de cobranza (dunning) que básicamente le dice a la gente que cancele. Revisa ambos antes de gastar dinero en herramientas de retención.
Cómo medirlo sin engañarte a ti mismo
La gestión de reembolsos sin atribución por cohortes produce conclusiones seguras pero sin sentido.
Atribuye cada reembolso al período en que ocurrió la compra original, no a cuando llegó el reembolso. Luego deja que la cohorte madure. De 30 a 45 días para planes mensuales, más tiempo para los anuales, ya que las solicitudes de reembolso pueden llegar meses después.
Aquí es también donde el seguimiento de reembolsos de suscripción se complica, y donde la mayoría de los dashboards hacen trampa en silencio. Un win-back aceptado en noviembre pertenece a la cohorte que canceló en agosto. Si tus reportes no conectan eso, tu cifra de recuperación es ficción.
Rastrea cuatro cifras, no una.
Tasa de reembolso por cohorte.
Solicitudes respondidas dentro del plazo.
Ingresos defendidos, divididos por motivo de reembolso.
Fugas de derechos de acceso pendientes, que deberían tender a cero y mantenerse ahí.
Si solo pudiera poner una en un dashboard, sería el conteo de fugas. Es la única cifra que es inequívocamente incorrecta siempre que no sea cero.
Dónde encaja el software, honestamente
Las categorías dos y cuatro se automatizan sin problemas. La categoría uno se automatiza una vez y luego solo necesita monitoreo. La categoría tres es configuración y criterio, y ninguna herramienta pone el criterio por ti.
Refund Sensor se encarga del lado de defensa en ambas tiendas, respondiendo toda solicitud elegible dentro del plazo con evidencia de transacción y registrando lo que conservaste. No va a recuperar a nadie ni va a arreglar un paywall confuso. Nada hace eso excepto tú.
Fuentes
Preguntas frecuentes
Cuatro rutas, en el orden en que yo las probaría. Encuentra a los usuarios que conservan el acceso sobre una transacción reembolsada y desactívalo. Responde todas las solicitudes de consumo dentro de las 12 horas. Recupera a los que cancelaron con ofertas win-back o promocionales. Luego revisa el reintento de facturación y los períodos de gracia, porque parte de esa cancelación nunca fue permanente.
No directamente. Apple a veces revierte los reembolsos por sí misma después de una disputa del cliente y envía una notificación REFUND_REVERSED. Cuando eso llega, restablece el acceso. Es una recuperación por la que no tuviste que pelear.
Están dirigidas a suscriptores que cancelaron la renovación automática, y la elegibilidad se basa en la duración pagada más el tiempo desde la última suscripción. Una suscripción reembolsada cuenta como cancelada, así que normalmente sí. Aun así, configura las reglas y verifica.
La consulta de derechos de acceso. Una hora de trabajo, sin proveedor, sin lanzar una nueva versión de la app. En cada app en la que la he ejecutado, la respuesta no fue cero.
Más que el monto del reembolso. Las tasas típicas van del 2% al 5% de las transacciones pagadas. El costo real suma el gasto de adquisición detrás de ese usuario, la fuga de derechos de acceso si te perdiste la notificación, y el LTV inflado que te hace pagar de más por el siguiente.
No. Corregir la fuga no cuesta nada y es un error. El software responde las solicitudes que tú no estás respondiendo, lo cual es un problema real, solo que no el primero.
