Real User Monitoring (RUM)

Il Real User Monitoring (RUM) è un modo di misurare come si comporta un sito web o un'applicazione per le persone che li usano davvero. Un piccolo frammento di codice nella pagina, o un SDK nell'app mobile, registra tempi ed errori durante ogni visita reale e li invia a un servizio di raccolta per l'analisi.

La parola «Real» è il punto. Un test di laboratorio mostra come si carica una pagina su un computer veloce, in un solo data center. Il RUM mostra come si carica su uno smartphone di tre anni, in treno, con una rete debole e un'estensione del browser che inietta i propri script. Condizioni troppo varie per essere riprodotte: l'unico modo per conoscerle è misurarle dove avvengono.

Il RUM è passivo: non genera traffico di prova, osserva soltanto. È una delle due metà della misurazione dell'esperienza digitale, l'altra è il monitoraggio sintetico, ed è una delle letture del termine più ampio di monitoraggio degli utenti finali, che comprende anche il tracciamento delle attività. Rientra nella pratica generale del monitoraggio. Nonostante il nome, l'«utente» qui è la sessione di un visitatore, non un dipendente sotto valutazione.

Qualunque sia il fornitore, un'implementazione RUM segue lo stesso percorso, dal dispositivo del visitatore fino alla dashboard.

1. 1

   Integrare

   Aggiungi uno script alla pagina o un SDK all'app. Registra osservatori sui dati sulle prestazioni che il browser già espone.

2. 2

   Raccogliere

   Durante la visita lo script legge i tempi di navigazione, risorse, rendering e interazioni, e annota errori JavaScript e richieste fallite.

3. 3

   Arricchire

   Ogni record riceve un contesto: pagina o schermata, browser, categoria di dispositivo, tipo di connessione, posizione approssimativa e identificatore di sessione.

4. 4

   Inviare

   Lo script invia i dati in piccoli lotti come beacon, preferibilmente quando la pagina viene nascosta o chiusa, per non rallentare la visita stessa.

5. 5

   Aggregare

   Il backend raggruppa i record per pagina, versione, paese o dispositivo e mostra distribuzioni, tendenze e avvisi.

Il RUM registra molti segnali, ma tre sono lo standard nel lavoro sul web. Si chiamano Core Web Vitals, e Google pubblica valori obiettivo considerati buoni quando sono raggiunti per almeno il 75 per cento delle visite. Oltre a questi, il RUM di solito segue il tempo di risposta del server (TTFB), gli errori JavaScript, la durata delle chiamate API fatte dalla pagina e, nelle app mobili, arresti anomali e tempo di avvio.

I dati RUM sono una distribuzione, non un numero singolo. La media nasconde i visitatori che soffrono di più, per questo i team leggono i percentili: la mediana mostra la visita tipica, mentre il 75° o il 95° percentile mostra la coda lenta. Confronta lo stesso percentile tra le versioni, altrimenti un cambiamento nella composizione dei visitatori sembrerà un cambiamento del sito.

Il vero valore nasce dalla segmentazione. Suddividi i dati per categoria di dispositivo, browser, tipo di connessione, modello di pagina e geolocalizzazione, e il problema di solito si rivela da solo: uno script pesante che penalizza solo gli smartphone economici, una regione lontana dal server più vicino, una versione che ha aumentato il tasso di errori su una sola versione del browser. Il metodo ha anche punti ciechi. Vede soltanto le visite in cui lo script si è caricato, e i blocker e le scelte di consenso ne eliminano una parte.

Il RUM raramente si usa da solo. Il monitoraggio sintetico esegue controlli scriptati da località fisse secondo una pianificazione, e il monitoraggio delle prestazioni applicative (APM) traccia ciò che accade dentro i server. Ciascuno risponde a una domanda diversa:

La maggior parte dei progetti RUM deludenti fallisce in modi noti:

• Leggere le medie invece dei percentili, lasciando invisibili i visitatori più lenti
• Confrontare periodi con una diversa composizione di dispositivi, paesi o fonti di traffico e attribuire il risultato all'ultima versione
• Raccogliere URL complete con parametri, valori dei moduli o identificatori degli utenti di cui la domanda non aveva mai bisogno, un problema che l'anonimizzazione alla fonte eliminerebbe
• Campionare in modo così aggressivo che le pagine rare e gli errori rari scompaiono
• Guardare solo la velocità senza mai collegarla a risultati come frequenza di rimbalzo, conversioni o richieste al supporto

I dati RUM servono a più team, e ciascuno vuole un taglio diverso. Vale anche la pena dire a che cosa il RUM non serve: non è uno strumento per osservare i singoli dipendenti, e quel compito spetta al monitoraggio dell'attività degli utenti.

Il RUM tratta dati sulle prestazioni, ma anche questi possono essere dati personali. Indirizzi IP, caratteristiche del dispositivo, identificatori di sessione e URL possono indicare una persona, per cui può applicarsi la normativa sulla protezione dei dati (nell'UE il GDPR), e le regole ePrivacy sull'archiviazione o la lettura di informazioni sul dispositivo possono richiedere il consenso. Una configurazione rispettosa della privacy evita identificatori persistenti, accorcia gli indirizzi IP, rimuove i parametri dalle URL e rispetta la scelta fatta nel banner di consenso. Verifica i dettagli per i tuoi mercati con una consulenza legale.

Un buon inizio è piccolo. Scegli le tre o quattro pagine che rendono di più, misura su di esse i Core Web Vitals, imposta un avviso sul 75° percentile e rivedilo dopo ogni rilascio. Se la tua domanda riguarda ciò che fanno i dipendenti e non le prestazioni di un sito, la categoria giusta è il monitoraggio dell'attività dei dipendenti, che usa dati diversi e altre salvaguardie.