Conozco a dos equipos que manejan la misma app y reportaron tasas de reembolso de 3.1% y 5.8% para el mismo mes. Ninguno mentía. Habían definido la métrica de forma distinta, y nadie había dejado la definición por escrito.
Eso es lo que nadie menciona en una página de funciones sobre las analíticas de reembolsos de apps móviles. El número es tan bueno como la regla de atribución que hay detrás, y la mayoría de los dashboards no dicen cuál regla usaron.
Por eso, esta publicación cubre lo que hacen las herramientas y la única pregunta de metodología que debes hacer antes de confiar en cualquiera de ellas. Solo en cuanto a la mecánica de seguimiento, cómo rastrear los reembolsos de App Store profundiza más en el lado de Apple.
Puntos clave
La atribución por cohortes es mejor que la atribución por período. Cuenta el reembolso en el mes en que ocurrió la compra, no en el mes en que se procesó.
El retraso del reembolso puede durar semanas, a veces un período de facturación completo. Cualquier dashboard que muestre la tasa de este mes está mostrando una tasa incompleta.
Los contracargos no son reembolsos. RevenueCat deja claro que no los cuenta como reembolso, así que necesitas un feed separado.
Las consolas de las tiendas son gratuitas y poco útiles para ver tendencias. Apple te da informes; Google, una API con un límite diario.
Las mejores herramientas para rastrear las tasas de reembolso de apps móviles son las que publican su denominador.
Primero, el problema de la definición
Hay dos formas de hacer el seguimiento de la tasa de reembolso de una app, y no coinciden entre sí.
Método por período: los reembolsos que llegaron en marzo, divididos entre las transacciones facturadas en marzo. Fácil de implementar. Incorrecto, porque un reembolso de marzo muchas veces corresponde a una compra de enero.
Método por cohortes: de todo lo facturado en enero, qué porcentaje se ha reembolsado desde entonces. Más difícil, porque el número nunca deja de cambiar.
Apphud documenta esto con honestidad. Su denominador son las transacciones facturadas en el período, y el numerador es la cantidad que se reembolsó después, incluso una vez cerrado el período. Ese es el enfoque por cohortes, y coincide con cómo se comportan los reembolsos.
Por eso necesitas un punto de corte. Las suscripciones mensuales se estabilizan alrededor de 30 a 45 días, mientras que los planes anuales siguen fluctuando durante meses. Comparar un número de 10 días con uno de 90 días es comparar ruido.
El nivel gratuito: las consolas de las tiendas
Empieza por aquí. No cuesta nada, y es donde la mayoría de los equipos se detienen.
App Store Connect. Sales and Trends, junto con Financial Reports, te mostrará los reembolsos, y el informe financiero coincide con tu pago. Es manual, basado en períodos, y no tiene segmentación por producto ni canal. Sirve para una revisión mensual básica. Inútil para encontrar qué paywall está sangrando.
El mejor feed gratuito ni siquiera está en la consola. El endpoint Get Refund History de Apple devuelve una lista paginada de cada transacción reembolsada por cliente, que puedes extraer hacia tu propio warehouse. Tiene un límite de solicitudes, y Apple recomienda usar notificaciones en lugar de polling, así que trátalo como una reconciliación.
Google Play Console. De nuevo, informes financieros, más la Voided Purchases API, que lista las compras reembolsadas, con contracargo o revocadas en un rango de tiempo. Tiene un límite de 6,000 llamadas al día y 30 cada 30 segundos, así que está pensada para revisiones programadas, no para nada en tiempo real.
Ambas consolas comparten una falla para el análisis de tendencias. Reportan lo que ya se liquidó, no lo que se solicitó, así que nunca ves las solicitudes que lograste defender.
RevenueCat
Si tus suscripciones ya pasan por ahí, esta es la respuesta por defecto.
La tasa de reembolso es una de sus métricas de referencia: el porcentaje de suscripciones pagadas que se reembolsaron durante su primer período de facturación, comparado con apps de tu tienda y categoría. Esa comparación es la parte útil, ya que una tasa sin contexto frente a tus pares es difícil de accionar. Su informe State of Subscription Apps cubre más de 75,000 apps y ubica las medianas alrededor de 3% a 5%.
También hay un gráfico de App Store Refund Requests que separa las solicitudes aprobadas, rechazadas, revertidas y en espera de resolución. Eso es a nivel de solicitud, algo que la mayoría de las herramientas omite.
Dos advertencias. Los reembolsos de Play otorgados por Google, en lugar de por ti, pueden tardar hasta 24 horas en aparecer, y los reembolsos emitidos sin marcar la casilla de revocación no se detectan en absoluto. Además, RevenueCat no cuenta los contracargos como reembolsos. El estado de la compra se actualiza, pero la tasa de reembolso no cambia.
Adapty
Más sólido en segmentación que la mayoría. El seguimiento de reembolsos se desglosa por día, plan, producto y canal de adquisición, que es el corte que realmente detecta problemas. Una tasa que se ve bien en general pero terrible en un canal específico es un problema de mensaje, no de producto.
Sus puntos de referencia provienen de $1.9 mil millones en ingresos rastreados en más de 11,000 apps, y la dispersión entre categorías es lo bastante amplia como para importar: educación y salud rondan el 4.7% al 5.1%, mientras que viajes y servicios públicos están más cerca del 1.5% al 2.1%. Los planes anuales se reembolsan más que los semanales. Los paywalls estrictos rondan el 5.8% frente al 3.4% de los modelos freemium.
El inconveniente es el mismo que en el resto de su producto: las buenas analíticas suponen que usas el SDK de Adapty.
Apphud
Más pequeño, más económico, e inusualmente claro respecto a la metodología, lo cual es motivo suficiente para incluirlo en tu lista corta. Su documentación explica la lógica de cohortes en lugar de ocultarla. Dashboards en tiempo real, cerca de 18 eventos de suscripción, y menos marketing que las alternativas.
Si quieres un número que puedas defender en una reunión de directorio, la claridad gana sobre una lista más larga de funciones.
Seguimiento dedicado de reembolsos y contracargos
Aquí está el vacío. Las plataformas de suscripción cuentan los reembolsos que ya se liquidaron. Ninguna está dentro de la ventana de respuesta, así que ninguna puede decirte cuántas solicitudes defendiste, ni tu tasa de éxito según el motivo del reembolso.
Ese es un conjunto de datos distinto, y solo existe si algo está respondiendo a las solicitudes. Refund Sensor rastrea las solicitudes de reembolso de Apple y las revisiones de contracargos de Google Play como casos, con cronologías, resultados e ingresos defendidos, ambas tiendas en un solo dashboard. Muestra las solicitudes que nunca se convirtieron en reembolsos.
Vale la pena combinarlos, no reemplazarlos. Una plataforma de suscripción para analíticas por cohortes, y un software de protección de ingresos para apps móviles para las tendencias a nivel de solicitud. Son preguntas diferentes, y ninguna cubre a la otra.
Rastrear los contracargos por separado
Las tendencias de contracargos no son un subconjunto de las tendencias de reembolsos, y tratarlas como si lo fueran es el error más común que veo en el seguimiento de reembolsos de apps móviles.
En Google Play, las señales son distintas. Las Real-time developer notifications envían una voidedPurchaseNotification cuando algo se anula, y una pendingRefundReviewNotification cuando un contracargo necesita tu intervención. La Voided Purchases API incluye un campo voidedReason con nueve valores posibles, entre ellos fraud, friendly_fraud y chargeback. Es lo más cercano a una línea de tendencia de contracargos gratuita.
En Apple, es una notificación REFUND con un motivo de revocación, además de REFUND_DECLINED y REFUND_REVERSED para los casos que no se concretaron.
Para una tendencia de contracargos honesta, grafica voidedReason igual a chargeback a lo largo del tiempo, segmentado por producto. Luego grafica fraud y friendly_fraud por separado, porque esas cuentas reinciden y necesitan una respuesta diferente. Cubrimos qué feed hace qué en Voided Purchases API versus real-time developer notifications.
Cómo rastrear las tasas de reembolso y los contracargos en apps móviles
El stack que realmente construiría, en orden:
Elige una regla de atribución y déjala por escrito: por cohortes, con un punto de corte definido según la duración del plan.
Conecta los feeds de las tiendas. App Store Server Notifications V2, y RTDN en Play. Sin ellos, estás leyendo archivos CSV mensuales.
Guarda cada evento de reembolso vinculado a la transacción original, no a la fecha de hoy.
Agrega los eventos a nivel de solicitud, o nunca verás lo que lograste prevenir.
Separa los contracargos con sus propios códigos de motivo.
Compárate con tu categoría, no con un promedio global.
El paso 3 es donde las configuraciones caseras fallan silenciosamente, y el paso 6 es donde los dashboards engañan silenciosamente. Ninguno es difícil. Ambos se omiten.
Para el lado del costo, en lugar del lado de la tasa, cómo los reembolsos realmente le cuestan ingresos a tu app hace ese cálculo. Una tasa por sí sola no te dice qué hacer después.
Fuentes
Preguntas frecuentes
RevenueCat si quieres puntos de referencia por categoría y gráficos de Apple a nivel de solicitud. Adapty si necesitas segmentación por canal y plan. Apphud si buscas la metodología publicada más clara. Agrega una herramienta de defensa si también quieres ver las solicitudes que nunca se convirtieron en reembolsos.
Transacciones reembolsadas divididas entre transacciones pagadas, atribuidas al período en que ocurrió la compra. Luego decide cuánto tiempo dejas madurar una cohorte antes de considerarla definitiva. Planes mensuales, de 30 a 45 días. Anuales, más tiempo.
Entre el 2% y el 5% de las transacciones pagadas en apps de suscripción. Educación, salud y fitness suelen tener tasas más altas; viajes y servicios públicos, más bajas. Si superas el 10%, deja de mirar el marketing y revisa tu paywall.
No de forma adecuada. Los informes financieros de Apple muestran los reembolsos que ya se liquidaron. La Voided Purchases API de Google muestra las compras anuladas con un código de motivo, que es lo más parecido, pero tiene un límite de 6,000 llamadas al día y requiere una revisión programada.
Casi siempre es por el retraso en la atribución. Los informes de ingresos se basan en períodos, mientras que las tasas de reembolso deberían basarse en cohortes, y ambos solo coinciden una vez que todos los reembolsos se han procesado. Revisa también si se incluyen los contracargos, ya que algunas herramientas los excluyen.
Apple no publica un umbral, y yo desconfiaría de cualquiera que cite uno con seguridad. Lo que sí está documentado es que las tasas persistentemente altas de reembolsos y disputas pueden afectar el estado de la cuenta en Google Play. Esa es una razón más sólida para monitorear la tendencia que la tasa en sí.
