A taxa sem falhas é a principal métrica de estabilidade do app: a porcentagem de sessões (ou usuários) que NÃO experimentaram uma falha no app. Falhas são eventos catastróficos de UX — o app fecha forçadamente, o usuário perde o estado e a confiança no app se corrói. Apps com altas taxas de falhas perdem usuários por desinstalação mais rápido do que a aquisição consegue repor, independente de quão bom seja o restante do produto.
Dois formatos
- Sessões sem falhas: porcentagem de todas as sessões que foram concluídas sem uma falha. Usada para relatórios de estabilidade agregada. Métrica de limite inferior — se qualquer sessão única falha para um usuário, eles "viram uma falha", mas suas outras sessões podem estar bem.
- Usuários sem falhas: porcentagem de usuários que não experimentaram NENHUMA falha em uma janela definida (tipicamente últimos 7 ou 30 dias). Barra mais alta — uma vez que um usuário trava, eles ficam "afetados por falha" até a janela ser reiniciada.
Reporte ambos; eles contam histórias diferentes. Sessões sem falhas é a métrica operacional diária; usuários sem falhas é a métrica de experiência do usuário.
Benchmarks modernos
- Apps de consumo: taxa sem falhas de 99,5%+ é o baseline operacional. Apps de primeira linha atingem 99,9%+.
- Bancos / saúde / apps de alto risco: mínimo de 99,9%; os usuários têm tolerância zero para instabilidade em fluxos de trabalho críticos.
- Jogos hyper-casual: 98-99% é mais comum (iteração rápida, menos QA). Troca aceitável dado o formato do produto com sessões curtas.
- Abaixo de 99%: problema sério. Investigue imediatamente, envie hotfixes diariamente até resolver.
- Abaixo de 97%: existencial. Pause novas features, foque a engenharia em estabilidade até se recuperar.
Uma taxa de falhas de 1% não é "apenas 1%" — é catastrófica. Se 1 em cada 100 sessões falha e o usuário médio tem 5 sessões por semana, aproximadamente 5% dos usuários vão travar em qualquer semana, mais de 20% ao longo de um mês. Cada evento de falha eleva significativamente a probabilidade de desinstalação — impacto típico: uma taxa de falhas de 1% (99% sem falhas) reduz a retenção D7 em 10-20% e eleva a taxa de desinstalação D30 em 15-30% em relação a um baseline de 99,5%+. Número absoluto pequeno, enorme impacto no negócio.
Ferramentas de rastreamento de falhas
- Firebase Crashlytics — rastreamento de falhas gratuito do Google. O líder de mercado por adoção (estimativa de ~70% dos apps Android; participação substancial no iOS). Forte simbolicação de stack trace, alertas em tempo real, integração com BigQuery para análise mais profunda.
- Sentry — forte monitoramento de falhas e erros cross-platform com escopo mais amplo (não apenas falhas, também erros não fatais). Popular entre equipes orientadas por engenharia.
- Bugsnag (agora SmartBear) — funcionalidades comparáveis ao Sentry, comum em enterprise.
- Apple App Store Connect / Google Play Console — dashboards nativos de falhas das próprias lojas. Use como verificação cruzada; não dependa apenas deles (detalhes limitados de stack trace, agregação mais lenta).
Disciplina de processo: todo release deve ter um critério documentado de taxa sem falhas antes do rollout amplo. Rollouts faseados (rollout gradual do Google Play, lançamento faseado da App Store) permitem detectar uma regressão de estabilidade em 1-5% dos usuários antes de afetar 100%. Defina um limiar claro (ex.: "pausar rollout se a taxa sem falhas cair abaixo de 99,3% no primeiro 1% de usuários") e cumpra.