Monitoramento de Usuário Real (RUM)

O monitoramento de usuário real (RUM, de Real User Monitoring) é uma forma de medir como um site ou aplicativo se comporta para as pessoas que de fato o usam. Um pequeno trecho de código na página, ou um SDK no aplicativo móvel, registra tempos e erros em cada visita real e os envia a um serviço de coleta para análise.

A palavra «real» é o ponto central. Um teste de laboratório mostra como uma página carrega em uma máquina rápida, em um único data center. O RUM mostra como ela carrega em um celular de três anos, dentro de um trem, com rede fraca e uma extensão do navegador injetando os próprios scripts. Essas condições são variadas demais para serem reproduzidas, então a única forma de conhecê-las é medi-las onde acontecem.

O RUM é passivo: não gera tráfego de teste, apenas observa. É uma das duas metades da medição da experiência digital, sendo a outra o monitoramento sintético, e é uma das leituras do termo mais amplo monitoramento de usuário final, que também abrange o acompanhamento de atividades. Faz parte da prática geral de monitoramento. Apesar do nome, o «usuário» aqui é a sessão de um visitante, não um funcionário sob avaliação.

Seja qual for o fornecedor, uma implantação de RUM segue o mesmo caminho, do dispositivo do visitante até o painel.

1. 1

   Instrumentar

   Adicione um script à página ou um SDK ao aplicativo. Ele registra observadores dos dados de desempenho que o navegador já expõe.

2. 2

   Coletar

   Ao longo da visita, o script lê os tempos de navegação, recursos, renderização e interações, e anota erros de JavaScript e requisições que falharam.

3. 3

   Enriquecer

   Cada registro recebe contexto: página ou tela, navegador, classe do dispositivo, tipo de conexão, localização aproximada e um identificador de sessão.

4. 4

   Enviar

   O script envia os dados em pequenos lotes, como um beacon, de preferência quando a página é ocultada ou fechada, para não atrasar a própria visita.

5. 5

   Agregar

   O back-end agrupa os registros por página, versão, país ou dispositivo e mostra distribuições, tendências e alertas.

O RUM registra muitos sinais, mas três são padrão no trabalho com sites. Chamam-se Core Web Vitals, e o Google publica valores de referência considerados bons quando são atingidos em pelo menos 75% das visitas. Além deles, o RUM costuma acompanhar o tempo de resposta do servidor (TTFB), erros de JavaScript, a duração das chamadas de API feitas pela página e, em aplicativos móveis, travamentos e tempo de inicialização.

Os dados de RUM são uma distribuição, não um número único. A média esconde os visitantes que mais sofrem, por isso as equipes leem percentis: a mediana mostra a visita típica, enquanto o percentil 75 ou 95 mostra a cauda lenta. Compare o mesmo percentil entre versões, ou uma mudança no perfil dos visitantes vai parecer uma mudança no site.

O valor real vem do fatiamento. Separe os dados por classe de dispositivo, navegador, tipo de conexão, modelo de página e geolocalização, e o problema costuma se mostrar sozinho: um script pesado que prejudica só celulares simples, uma região distante do servidor mais próximo, uma versão que elevou a taxa de erros em uma versão do navegador. O método também tem pontos cegos. Ele só enxerga as visitas em que o script carregou, e bloqueadores e escolhas de consentimento retiram parte delas.

O RUM raramente é usado sozinho. O monitoramento sintético executa verificações roteirizadas a partir de locais fixos, em horários programados, e o monitoramento de desempenho de aplicações (APM) rastreia o que acontece dentro dos servidores. Cada um responde a uma pergunta diferente:

A maioria dos projetos de RUM que decepcionam falha de maneiras conhecidas:

• Ler médias em vez de percentis, deixando os visitantes mais lentos invisíveis
• Comparar períodos com perfis diferentes de dispositivos, países ou origens de tráfego e atribuir o resultado à última versão
• Coletar URLs completas com parâmetros, valores de formulários ou identificadores de usuário de que a pergunta nunca precisou, um problema que a anonimização na origem eliminaria
• Fazer amostragem tão agressiva que páginas e erros raros desaparecem
• Olhar apenas a velocidade, sem ligá-la a resultados como taxa de rejeição, conversão ou chamados de suporte

Os dados de RUM atendem a várias equipes, e cada uma quer um recorte diferente. Vale dizer também para que o RUM não serve: ele não é uma ferramenta para observar funcionários individualmente, e essa tarefa cabe ao monitoramento da atividade dos usuários.

O RUM trata de dados de desempenho, mas eles ainda podem ser dados pessoais. Endereços IP, características do dispositivo, identificadores de sessão e URLs podem apontar para uma pessoa, então a lei de proteção de dados pode se aplicar (no Brasil, a LGPD), e, na UE, as regras de ePrivacy sobre armazenar ou ler informações no dispositivo podem exigir consentimento. Uma configuração que respeita a privacidade evita identificadores persistentes, encurta endereços IP, remove parâmetros das URLs e respeita a escolha feita no banner de consentimento. Confirme os detalhes dos seus mercados com a assessoria jurídica.

Um bom começo é pequeno. Escolha as três ou quatro páginas que mais geram resultado, meça os Core Web Vitals nelas, configure um alerta no percentil 75 e revise-o a cada versão publicada. Se a sua pergunta é sobre o que os funcionários fazem, e não sobre o desempenho de um site, a categoria certa é o monitoramento de atividade de funcionários, que usa outros dados e outras salvaguardas.