Como este tema funciona na sua empresa
Geralmente nem têm SLA estruturado. Experiência do usuário é feedback informal ("tá rápido" vs "tá lento"). Desafio: não conseguem correlacionar problemas de TI com impacto real. Abordagem: começar com 2-3 métricas simples de experiência (tempo de carregamento <2s, taxa de erro <0,1%). Usar browser (observar usuários reais).
Têm SLA técnico, mas não experiência. Começam usar telemetria básica (ferramentas APM). Desafio: SLA técnico garante "up", mas experiência é pobre (lento). Abordagem: implementar RUM (Real User Monitoring), definir XLA para aplicações críticas. Correlacionar: quando SLA violado, experiência também violada?
SLA técnico robusto, XLA em evolução. Ferramentas avançadas de observabilidade (APM, RUM, log agregado). Desafio: correlacionar SLA técnico, OLA interno, XLA. Abordagem: framework de XLA integrado com SLA, dashboard que mostra impacto de falhas técnicas na experiência. CX team envolvido.
XLA (Experience Level Agreement) é acordo focado não em uptime técnico (disponibilidade de sistema), mas em experiência do usuário final (tempo de resposta, taxa de erro, funcionalidade efetiva). Diferença fundamental: SLA técnico mede sistema; XLA mede impacto para usuário. Exemplo: uptime 99,99%, mas aplicação lenta = SLA cumprido, XLA violado[1].
Paradoxo: SLA técnico vs. experiência real do usuário
Sistema com uptime 99,99% mas usuários reclamam. Causa: SLA técnico não captura experiência real. Sistema pode estar "up" mas lento (latência alta). Funcionalidade crítica pode estar quebrada sem afetar uptime geral. API pode responder (técnico OK) mas muito lentamente (experiência ruim). Pesquisa Dynatrace: 40% das violações de SLA técnico não impactam experiência; inversamente, 40% dos problemas de experiência não geram violação de SLA técnico. Insight: investir APENAS em uptime técnico é game incompleto. Precisa medir experiência.
RUM (Real User Monitoring) vs. APM (Application Performance Monitoring)
RUM (Real User Monitoring): instrumentação que captura experiência real de usuários EM PRODUÇÃO. Métricas: tempo de carregamento (page load, <2s é bom), taxa de erro (0,1%), funcionalidade disponível (% de funcionalidades que funcionam). Browser-side, mede do ponto de vista do usuário. APM (Application Performance Monitoring): ferramentas que capturam performance de aplicação DO LADO DO SERVIDOR. Métricas: tempo de resposta (API, <200ms), CPU, memória, banco de dados. Server-side, mede infraestrutura. Ambos necessários: APM identifica ONDE está problema (servidor), RUM valida SE afeta usuário. Exemplo: APM mostra CPU alta, RUM mostra tempo de resposta OK (problema é transitório, não afeta usuário).
Métrica simples de experiência: tempo de carregamento (medir com browser simples ou Google Lighthouse). Feedback de usuário (survey rápida: "tá rápido?"). Monitoramento: semanal (executar teste, registrar tempo). Objetivo: se tempo =3s, investigar. Ferramentas: Google Lighthouse (grátis), Pingdom (pago, básico). Sem dashboard, apenas spreadsheet. Custo: zero (Lighthouse) ou R$ 100-300/mês (Pingdom).
RUM implementado (ferramenta básica: Datadog, New Relic). Métricas: Core Web Vitals (LCP - Largest Contentful Paint <2.5s, FID - First Input Delay <100ms, CLS - Cumulative Layout Shift <0.1), taxa de erro (<0,1%), disponibilidade percebida (99,9%). Dashboard simples (visualizar tendências). Correlação básica: quando SLA técnico violado, RUM também violado? XLA = SLA técnico + RUM. Custo: R$ 5-15k/mês.
RUM + APM integrados (Dynatrace, New Relic Advanced). Observabilidade completa: RUM (experiência), APM (performance), logs (detalhes). Correlação automática: falha técnica (APM) ? impacto em experiência (RUM) = rastreado automaticamente. Dashboard executivo: SLA técnico vs. XLA vs. impacto em negócio. Feedback de usuário integrado (NPS, CSAT). CX team envolvido em RUM. Custo: R$ 50-200k/mês.
Como desenhar XLA viável
Não impor XLA tão rígido que seja impossível cumprir. Calibrar com dados de usuários reais. Exemplo: se usuários (via RUM) têm tempo de carregamento mediano 1,8s, XLA de <1s é impossível (80% violado). XLA viável seria <2,5s (10% de margem). Começar com 3-5 métricas críticas, não 20. Priorizar: (1) Tempo de carregamento (impacto alto em UX). (2) Taxa de erro (impacto crítico). (3) Disponibilidade percebida (diferente de uptime técnico). Evitar: métricas que técnico não consegue influenciar (ex: latência de rede geográfica).
Correlação SLA-XLA: quando não é perfeita
SLA: "uptime 99,9%" (sistema respondeu). XLA: "tempo de resposta <2s" (usuário conseguiu usar). Violação de SLA mas XLA OK: sistema teve 20 min downtime, mas foi em madrugada (ninguém usando). XLA OK. Violação de XLA mas SLA OK: sistema up 24h, mas lento demais (latência 5s). SLA OK, XLA violado. Insight: XLA é mais importante que SLA técnico para experiência real. Mas SLA técnico ainda é importante (fundação). Ideal: ambos juntos, correlacionados.
Sinais de que você precisa implementar XLA
Se você reconhece dois ou mais, comece RUM agora.
- SLA técnico diz uptime 99,9%, mas usuários reclamam de performance
- Você investiu em infraestrutura para uptime, mas usuários ainda reclamam
- Violações de SLA técnico não correlacionam com reclamações de usuários
- Você não sabe tempo típico de carregamento de suas aplicações
- Feedback de usuário é qualitativo (bate-papo), não quantitativo (métrica)
- Decisões de investimento em TI baseadas só em uptime, não em experiência
- Você tem múltiplas regiões geográficas e experiência varia por região
Caminhos para implementar XLA em sua operação
Você implementa RUM com ferramentas de código aberto ou gratuitas.
- Perfil necessário: engenheiro de performance + analista de dados
- Tempo estimado: 2-4 semanas de implementação
- Faz sentido quando: você tem tempo, equipe técnica capaz
- Risco principal: dados brutos, sem contexto, difícil extrair insights
Ferramentas como Dynatrace ou New Relic, com suporte de consultores.
- Tipo de fornecedor: ferramentas de observabilidade (Dynatrace, New Relic, DataDog), consultores de CX/performance
- Vantagem: dashboard profissional, insights automáticos, correlação SLA-XLA, relatórios executivos
- Faz sentido quando: operação é crítica, você quer qualidade máxima de insights
- Resultado típico: visibilidade 100% de experiência, decisões de investimento melhores, redução de reclamações
Quer implementar XLA e RUM para medir experiência do usuário?
O oHub conecta você gratuitamente a consultores de performance e provedores de ferramentas de observabilidade (RUM/APM). Descreva sua necessidade (tamanho da operação, crítica das aplicações) em menos de 3 minutos, receba propostas sem compromisso.
Encontrar fornecedores de TI no oHub
Sem custo, sem compromisso. RUM bem implementado melhora experiência e reduz custos de TI focando em prioridades reais.
Perguntas frequentes
XLA é sinônimo de CSAT/NPS (pesquisa de satisfação)?
NÃO. XLA é métrica TÉCNICA/OBJETIVA (tempo <2s, taxa erro <0,1%). CSAT/NPS é SUBJETIVO (pergunta para usuário). Ambos importantes. XLA é para gestão técnica, CSAT é para feedback. XLA deve concordar com CSAT (se XLA OK mas CSAT baixo, você tem problema).
Como medir experiência em mundo mobile + desktop + web?
RUM mede CADA plataforma em separado. Métricas variam: desktop (LCP <2s), mobile (LCP <2.5s, porque rede é mais lenta). XLA pode ser diferente por plataforma. Dashboard mostra por plataforma. Correlação: mobile é 70% de usuários? XLA mobile importa mais.
Qual é impacto financeiro de melhorar experiência em 100ms?
Google Research: cada 100ms de latência custa 1% de conversão em e-commerce. Akamai: melhoria de 1% em experiência (redução de latência) gera aumento de 2-3% em receita. Para site de e-commerce de R$ 10M/ano, 1% = R$ 100k. ROI de investimento em performance é alto.
Contexto brasileiro: banda larga varia por região. Como XLA?
RUM mostra experiência por região geográfica. São Paulo (banda larga boa) pode ter LCP 1,5s. Interior (banda larga ruim) pode ter LCP 3s. XLA pode ser regional ou aguardar o pior cenário (interior = padrão). Recomendação: XLA por região, metas diferentes conforme banda disponível.
SLA técnico pode ser 100% (zero downtime)?
Não na prática (redundância custa muito, nunca é perfeita). SLA típico: 99,9% (8.76h downtime/ano), 99,95% (4.38h), 99,99% (52 min). Acima disso é raro. XLA não pode ser 100% também (rede, cache, etc). Viável: SLA 99,9%, XLA 99,5% (usuário tolera pequenas lentidões).
Preciso de RUM + APM ou só um dos dois?
Idealmente ambos: RUM = "usuário vê isso", APM = "problema está aqui". Só RUM: você sabe que experiência é ruim, mas não sabe por quê. Só APM: você otimiza servidor, mas pode não melhorar experiência real. Comece com RUM (mais importante), depois APM.