Quando uma sessão termina em um crash, você perde mais do que a confiança do usuário. Perde todas as impressões que seriam exibidas no restante da sessão, todos os postbacks que seriam disparados no encerramento e uma parcela significativa da retenção no dia seguinte. A conta incomoda.
A cadeia de perdas
A duração média de uma sessão em um app mobile estável é de 6 a 9 minutos. A média de impressões por sessão, após aplicar os limites de frequência, é de 2,4. Uma sessão que sofre um crash no segundo minuto perde, em média, cerca de 1,6 impressão — sem chance de recuperação.
Multiplique isso por uma taxa de crashes de 1% e 5 milhões de DAU, e o resultado é de 80.000 impressões perdidas por dia. Com um eCPM de US$ 7, são US$ 560 de receita perdidos todos os dias, atribuíveis a um único ponto percentual de estabilidade.
O modelo completo de perda de receita
A fórmula é simples: receita perdida por dia = DAU × taxa de crashes × (impressões por sessão – impressões antes do crash) × eCPM / 1.000. O impacto fica difícil de ignorar quando você insere números realistas.
- 1 milhão de DAU × 1,5% de crashes × 1,6 impressão perdida × US$ 6 de eCPM ≈ US$ 144/dia, US$ 52 mil/ano
- 5 milhões de DAU × 1,0% de crashes × 1,6 impressão perdida × US$ 7 de eCPM ≈ US$ 560/dia, US$ 204 mil/ano
- 25 milhões de DAU × 0,6% de crashes × 1,6 impressão perdida × US$ 8 de eCPM ≈ US$ 1.920/dia, US$ 700 mil/ano
- E esses números consideram apenas as impressões perdidas — deixam de fora o impacto negativo na retenção, que costuma ser maior
ANRs são crashes com impacto ainda pior na monetização
No Android, um ANR (aplicativo não responde) é um vilão silencioso. O usuário vê a interface congelada, força o encerramento e desinstala o app — mas nenhum relatório de crash é gerado, então a equipe que acompanha o Crashlytics não fica sabendo. Taxas de ANR acima de 0,5% são comuns em apps que inicializam o SDK de anúncios na thread principal.
No iOS, o equivalente é o encerramento pelo watchdog — com o código de saída 0x8badf00d, geralmente provocado pela mesma causa raiz: processamento síncrono na thread principal durante a inicialização. Trate os dois como você trata os crashes: configure alertas, calcule a perda de receita da mesma forma e use esses indicadores como critérios para liberar ou bloquear cada versão.
Padrões de programação defensiva por plataforma
Estes são os padrões que adotamos por padrão em todas as integrações do Apps Kit SDK. Nenhum é sofisticado. Todos costumam estar ausentes nas bases de código que auditamos.
- Android: inicialize o SDK em uma tarefa do WorkManager, não em Application.onCreate
- Android: mantenha as views de anúncios em WeakReference e defina essas referências como null em onDestroyView
- iOS: encaminhe a inicialização do SDK para uma fila com QoS utility a partir de didFinishLaunching, sem nunca bloquear a thread principal
- iOS: invalide os delegates de anúncios e quebre os ciclos de retenção em viewWillDisappear, não em deinit
- Ambas: condicione cada solicitação de anúncio a uma máquina de estados que acompanhe o consentimento, a conexão de rede e se o SDK está pronto
De onde vêm os crashes
- Inicialização do SDK na thread principal — de longe, a causa mais comum que encontramos
- Carregamento síncrono de anúncios em onCreate / didFinishLaunching
- Pressão de memória causada pela retenção de views de anúncios além da vida útil delas
- Condições de corrida entre o estado de consentimento e a solicitação de anúncio
Alertas de crashes com impacto na receita
Os alertas de taxa de crashes geralmente são configurados com um limite percentual fixo e ignorados quando disparam. Em vez disso, vincule-os ao impacto na receita: dispare um alerta quando a perda diária de receita estimada para uma assinatura de crash ultrapassar US$ X. Assim, o alerta passa a ser daqueles pelos quais vale a pena acordar o engenheiro de plantão. Disponibilizamos um modelo de Cloud Function que faz exatamente isso com os dados exportados para o BigQuery.
O padrão de programação defensiva
Inicialize o SDK em um dispatcher em segundo plano, condicione cada solicitação de anúncio a uma máquina de estados de consentimento e libere as referências às views de anúncios assim que o posicionamento for fechado. Nada disso é novidade. Tudo isso costuma faltar nas integrações que auditamos.
Trate a taxa de crashes como uma alavanca de receita, não como uma métrica de boas práticas de engenharia, e a conversa sobre priorizar melhorias de estabilidade fica muito mais curta.
O que fazer nesta semana
Abra seu painel de crashes, aplique o modelo acima às três assinaturas de crash mais frequentes e coloque um valor em dólares ao lado de cada uma. A versão que corrigir a de maior impacto vai se pagar antes do fim da próxima janela de revisão da App Store.
