Na primeira vez em que auditei um aplicativo em busca de receita perdida, quase informei que tudo estava bem. A taxa de reembolso estava em 2.4%, um bom número por qualquer parâmetro de referência. A equipe respondia às solicitações de consumo dentro da janela da Apple. No papel, não havia nada a recuperar.
Então executei mais uma consulta, mais por teimosia do que qualquer outra coisa. Quantas pessoas ainda tinham um entitlement pago em uma transação que a Apple já havia reembolsado? Quarenta e uma. Em um aplicativo com aproximadamente 900 assinantes pagantes. Executei a consulta duas vezes porque não acreditei no resultado.
Isso representa quase 5% da base usando o produto de graça, mês após mês, enquanto o dashboard permanecia verde. E a taxa de reembolso nunca mudou. Escrevi sobre essa correção de entitlement separadamente em como recuperar o acesso após um reembolso.
Se você está tentando descobrir como recuperar receita de assinaturas perdida com reembolsos da App Store, comece por aí, porque o reembolso é apenas o menor dos quatro lugares para onde seu dinheiro realmente vai. Aqui está o panorama completo.
As Quatro Categorias, Classificadas pelo Valor que Representam
Eu penso nisso como quatro categorias, e a classificação de esforço versus retorno não é o que a maioria das pessoas imagina.
O vazamento: usuários reembolsados que nunca perderam o acesso. A correção mais barata, e a mais frequentemente esquecida.
A defesa: responder às solicitações de consumo da Apple com evidências. A categoria que todo fornecedor menciona, já que é a única que o software consegue automatizar.
A reconquista (win-back): readquirir pessoas que foram reembolsadas ou que cancelaram. É a que demora mais para dar retorno. A Apple discretamente facilitou isso este ano.
A nova tentativa (retry): falhas de cobrança que se recuperam por conta própria, se você não interferir.
A maioria das equipes só trabalha na categoria dois. As surpresas estão nas categorias um e três.
Categoria Um: Encontre o Vazamento, Leva Uma Hora
Aqui está a consulta, de forma geral. Pegue todas as transações com uma data de revogação nos últimos 12 meses, cruze com sua tabela de entitlements e conte quantos ainda mostram acesso ativo.
Se a resposta for zero, sinceramente, pule esta seção. Mas se não for, você encontrou receita de assinaturas saindo todos os meses até que algo a desligue. A Apple reverte o pagamento. A Apple não toca no seu banco de dados. Os dois permanecem desconectados até que você os conecte. Os consumíveis são piores, porque, uma vez que um item é gasto, não há nada para a StoreKit recuperar.
(Eu mesmo errei isso por meses. O handler de notificações registrava eventos REFUND em uma tabela que ninguém lia. Registrar não é o mesmo que tratar.)
A correção: fique atento ao REFUND, revogue na data de revogação e trate o REFUND_REVERSED reconcedendo o acesso. A Apple às vezes reverte seus próprios reembolsos, depois de uma contestação do cliente, e você não deve punir o cliente por isso.
Mais uma consulta enquanto você está nisso. Conte os reembolsos para os quais você nunca recebeu nenhuma notificação do servidor. Se esse número não for zero, seu endpoint está com problema, e a categoria dois também está.
Categoria Dois: Defenda as Solicitações que Você Ainda Pode Influenciar
A Apple dá a você cerca de 12 horas a partir de um CONSUMPTION_REQUEST para enviar os dados de consumo. Três campos obrigatórios, dois opcionais, uma preferência, e agora isso cobre todos os tipos de produto, não apenas consumíveis.
Meu conselho aqui é curto, porque essa categoria já foi exaustivamente abordada em outros lugares. Responda a todas as solicitações. Recuse aquelas em que o produto foi claramente entregue e bastante utilizado. Conceda os acidentes genuínos. Uma concessão de boa-fé é barata. Contestar todo reembolso não é, porque a Apple leva em conta seu histórico.
A dependência que ninguém menciona é a evidência. Você só pode defender o que consegue comprovar. Se ninguém conseguir responder "quanto essa pessoa realmente usou" sobre uma compra feita sete semanas atrás, nenhuma automação vai te salvar. Essa é uma lacuna de modelagem de dados que vale a pena resolver, independentemente do fornecedor.
Para o lado dos custos, como os reembolsos realmente custam receita ao seu aplicativo faz essa conta, incluindo o gasto de aquisição por trás de cada usuário reembolsado.
Categoria Três: Reconquiste o Assinante
É aqui que a proteção de receita de assinaturas deixa de ser defensiva. E é a área que a Apple reconstruiu a seu favor no último ano.
Ofertas de reconquista (win-back offers). Novidade desde a WWDC24, no iOS 18 e versões posteriores. Você as configura por produto de assinatura no App Store Connect e define a elegibilidade: duração mínima paga, tempo desde a última assinatura, uma espera de 2 a 24 meses entre ofertas. Depois, a Apple faz a distribuição. Elas aparecem na página de Gerenciar Assinatura do cliente, na página do seu produto, em recomendações personalizadas e, ocasionalmente, em espaços editoriais na aba Today.
Leia isso de novo. A Apple mostra seu desconto a um assinante que cancelou em um lugar que você nunca conseguiria alcançar por e-mail. Limites: 350 ofertas por assinatura, 5 ativas por storefront. No aplicativo, a StoreKit dispara uma mensagem winBackOffer quando alguém se torna elegível, e eligibleWinBackOfferIDs, nas informações de renovação, mostra o que essa pessoa pode resgatar. O guia de configuração de win-back da Apple detalha os campos de elegibilidade.
Ofertas promocionais. Até 10 por assinatura, disponíveis desde o iOS 12.2, e exigem uma assinatura JWS do seu servidor. Mais trabalho do que o win-back. Mas você controla totalmente a segmentação, o que importa quando os motivos do reembolso revelam algo específico, por exemplo, um problema de preço em determinado país.
Códigos de oferta. Podem ser resgatados dentro ou fora do aplicativo. Isso os torna a única forma realista de alcançar alguém que foi reembolsado e depois desinstalou o aplicativo. Todos os outros você consegue alcançar dentro do aplicativo. Essas pessoas, não.
Estender a Data de Renovação da Assinatura. A mais subestimada, na minha opinião. A API de servidor da Apple permite que você adie a data de renovação de um assinante, em uma única transação ou em massa. Nós usamos isso como um gesto de boa vontade depois de lançamentos problemáticos: alguém envia um e-mail ao suporte sobre um bug de cobrança, você estende um mês, isso custa quase nada e supera qualquer cupom. Um reembolso evitado vale mais do que um reembolso reconquistado.
Uma exceção. Se alguém pediu reembolso por causa de uma surpresa na cobrança, e não por causa do produto em si, não vá atrás dessa pessoa com um desconto. Corrija primeiro o texto do paywall e depois deixe que ela redescubra o produto por conta própria. Gerenciamento de reembolsos da App Store aborda esse lado operacional.
Categoria Quatro: O Churn que se Resolve Sozinho
A Apple tenta novamente a cobrança que falhou por até 60 dias, ou até que o cliente corrija o cartão ou cancele. Se a assinatura for renovada dentro dessa janela, o serviço pago continua a partir da data de recuperação.
Então, uma parte do que parece ser receita de assinaturas perdida nunca foi, de fato, perdida. Estava apenas pendente. Duas coisas estragam isso: um período de carência que você nunca ativou, e um e-mail de cobrança (dunning) que basicamente diz às pessoas para cancelarem. Verifique os dois antes de gastar dinheiro com ferramentas de retenção.
Medindo Isso Sem se Enganar
Gerenciamento de reembolsos sem atribuição por coorte produz um disparate cheio de confiança.
Atribua cada reembolso ao período em que a compra original ocorreu, não a quando o reembolso aconteceu. Depois, deixe a coorte maturar. De 30 a 45 dias para planos mensais, mais tempo para os anuais, já que as solicitações de reembolso podem chegar meses depois.
É também aqui que o rastreamento de reembolsos de assinaturas se torna difícil, e onde a maioria dos dashboards trapaceia discretamente. Um win-back aceito em novembro pertence à coorte que cancelou em agosto. Se o seu relatório não conecta essas informações, o seu número de recuperação é fictício.
Acompanhe quatro números, não apenas um.
Taxa de reembolso por coorte.
Solicitações respondidas dentro da janela.
Receita defendida, dividida por motivo de reembolso.
Vazamentos de entitlement pendentes, que devem tender a zero e permanecer lá.
Se eu só pudesse colocar um número em um dashboard, seria a contagem de vazamentos. É o único número que está inequivocamente errado sempre que não é zero.
Onde o Software se Encaixa, Honestamente
As categorias dois e quatro se automatizam de forma limpa. A categoria um se automatiza uma vez e depois só precisa de monitoramento. A categoria três é configuração e julgamento, e nenhuma ferramenta faz esse julgamento por você.
Refund Sensor cuida do lado da defesa em ambas as lojas, respondendo a todas as solicitações elegíveis dentro da janela com evidências de transação e rastreando o que você conseguiu manter. Ele não vai reconquistar ninguém e não vai corrigir um paywall confuso. Nada faz isso além de você.
Fontes
Perguntas frequentes
Quatro caminhos, na ordem em que eu tentaria. Encontre usuários que ainda têm acesso em uma transação reembolsada e desative esse acesso. Responda a todas as solicitações de consumo dentro de 12 horas. Reconquiste quem cancelou com ofertas de win-back ou ofertas promocionais. Depois, verifique as novas tentativas de cobrança e os períodos de carência, porque parte desse churn nunca foi permanente.
Não diretamente. A Apple, ocasionalmente, reverte reembolsos por conta própria após uma contestação do cliente e envia uma notificação REFUND_REVERSED. Quando ela chegar, restabeleça o acesso. Essa é uma recuperação pela qual você não precisou lutar.
Elas têm como alvo assinantes que cancelaram e desativaram a renovação automática, e a elegibilidade é baseada na duração paga mais o tempo desde a última assinatura. Uma assinatura reembolsada conta como cancelada, então, geralmente, sim. Ainda assim, configure as regras e verifique.
A consulta de entitlement. Uma hora de trabalho, sem fornecedor, sem lançamento de app. Em todos os aplicativos em que executei essa consulta, o resultado nunca foi zero.
Mais do que o valor do próprio reembolso. As taxas típicas variam de 2% a 5% das transações pagas. O custo real soma o gasto de aquisição por trás daquele usuário, o vazamento de entitlement se você perdeu a notificação, e o LTV inflado que faz você pagar mais do que deveria pelo próximo usuário.
Não. Corrigir o vazamento é gratuito, e trata-se de um bug. O software responde às solicitações que você não está respondendo, o que é um problema real, só não é o primeiro.
