Come funziona il tasso di campionamento delle session replay in Sentry, PostHog e altri

Che cos'è il tasso di campionamento del session replay?

Il tasso di campionamento del session replay è la quota di sessioni utente che uno strumento di replay registra. Di solito si scrive come frazione tra 0 e 1 o come percentuale tra 0 e 100. Con un tasso di 0.1, circa una sessione su dieci viene registrata per intero e le altre nove no. La documentazione di Sentry lo riassume in una riga: "Il campionamento controlla quanto traffico genera un Session Replay."

Il tasso viene deciso una sola volta, all'inizio della sessione, quindi un visitatore escluso dal campione resta escluso per tutta la visita. Conta perché un session replay ha senso solo per intero: una registrazione senza il primo snapshot completo del DOM non si può riprodurre.

I vari fornitori non sono d'accordo su unità di misura, valore predefinito e punto in cui si imposta. Nelle sezioni che seguono citiamo la documentazione di ciascuno.

In che modo il campionamento a livello di sessione è diverso da quello a livello di evento?

Il campionamento a livello di sessione decide se una sessione viene registrata o no. Quello a livello di evento registra la sessione, ma scarta o limita alcuni eventi al suo interno. Il primo controlla quanti replay conservi. Il secondo controlla quanto pesa ogni replay.

Il registratore open source rrweb mostra bene il campionamento a livello di evento. La sua opzione sampling accetta chiavi come mousemove, scroll, media e input, e la ricetta per il risparmio di spazio imposta scroll: 150 con il commento "do not emit twice in 150ms" e input: 'last', così di una sequenza digitata resta solo il valore finale. Ogni sessione viene comunque registrata, solo con meno eventi.

Nessuno dei due coincide con il campionamento che un report di analytics applica quando stima i totali partendo da un sottoinsieme di righe. Quel tipo è trattato in quando parte il campionamento dei dati in un report.

Come usa Sentry replaysSessionSampleRate e replaysOnErrorSampleRate?

Sentry usa due tassi, impostati in Sentry.init(). Il suo riferimento di configurazione li definisce così:

• replaysSessionSampleRate, tipo number, valore predefinito 0: "Il tasso di campionamento per i replay che iniziano a registrare subito e durano per l'intera sessione dell'utente. 1.0 raccoglie tutti i replay, 0 non ne raccoglie nessuno."
• replaysOnErrorSampleRate, tipo number, valore predefinito 0: "Il tasso di campionamento per i replay registrati quando si verifica un errore. Questo tipo di replay registra fino a un minuto di eventi precedenti all'errore e continua a registrare fino alla fine della sessione."

La pagina di configurazione di Sentry spiega l'ordine. Si controlla prima replaysSessionSampleRate. Se la sessione è campionata, "La registrazione completa della sessione parte e viene inviata a Sentry in tempo reale." Se non lo è, la registrazione resta "solo nella memoria, con gli ultimi 60 secondi conservati". Quando si verifica un errore in una sessione non campionata, si controlla replaysOnErrorSampleRate, e se scatta vengono inviati i "60 secondi in buffer + il resto della sessione". Se non scatta, il buffer viene scartato e non parte nulla.

Sentry pubblica due valori predefiniti diversi per le stesse opzioni. Il riferimento di configurazione indica 0 per entrambe, quindi un'installazione dell'SDK che non imposta né l'una né l'altra non registra nulla. Lo snippet del Loader Script nella pagina di configurazione dice invece che "inizializzerà Replay con la configurazione predefinita: replaysSessionSampleRate: 0.1, replaysOnErrorSampleRate: 1". Quale valore ottieni dipende da come hai installato Sentry, edè utile controllare quale sta usando il tuo progetto.

Sentry è anche l'unico fornitore tra questi a pubblicare una tabella di tassi consigliati, intitolata "Recommended Production Sample Rates":

Sul tasso per gli errori il consiglio è netto: "Tieni replaysOnErrorSampleRate a 1.0: le sessioni con errori offrono il maggior valore per il debug." Per i test raccomanda replaysSessionSampleRate: 1.0.

Come campiona PostHog le registrazioni delle sessioni?

PostHog imposta il tasso di campionamento nelle impostazioni di acquisizione dei replay, non nel codice dell'SDK. Ogni "trigger group" ha le sue condizioni (trigger su URL, trigger su eventi, un feature flag) più "il proprio tasso di campionamento, la durata minima e il tipo di corrispondenza". Una sessione viene registrata se corrisponde a un qualsiasi gruppo.

Il campionamento di PostHog è deterministico. La documentazione dice: "Quando inizia una nuova sessione, PostHog converte l'ID della sessione in un numero tra 0 e 1 con una funzione di hash. Questo numero viene poi confrontato con il tasso di campionamento configurato (per esempio 0.1 per il 10% o 0.2 per il 20%)." Lo stesso ID di sessione ottiene sempre la stessa risposta, "anche dopo il ricaricamento della pagina". La documentazione dice anche a cosa rinunci: "Non puoi scegliere quali sessioni vengono campionate."

Il tasso si applica dopo le condizioni di un gruppo, non insieme ad esse. L'esempio di PostHog è "un gruppo con un trigger su un evento di eccezione e un tasso di campionamento del 20% registra il 20% delle sessioni che hanno generato un'eccezione", non il 20% di tutte le sessioni più ogni eccezione. Se elimini l'ultimo trigger group, PostHog lo sostituisce con un gruppo predefinito "Record all sessions" con campionamento al 100%. La sua raccomandazione ufficiale va nella direzione opposta alla tabella di Sentry: "Il nostro consiglio è di iniziare catturando il 100% delle sessioni e di ridurre la percentuale quando serve."

Come gestisce il campionamento LogRocket?

LogRocket imposta i tassi di campionamento dentro Conditional Recording, che la sua documentazione descrive come "disponibile come componente aggiuntivo separato per i clienti Pro ed Enterprise". Crei una condizione di registrazione, per esempio un clic su un pulsante di pagamento o un errore di rete, e "imposti il tasso di campionamento" per quella condizione. La documentazione porta come esempio "registra il 20% degli utenti che visitano la nostra pagina di checkout". Più condizioni "vengono considerate separatamente, non cumulativamente, quindi a una sessione basta soddisfare una sola condizione per essere registrata."

Poiché una condizione può scattare a metà visita, LogRocket mantiene una finestra retroattiva: "Tutte le registrazioni includono fino a 10MB di attività precedente al momento in cui la condizione di registrazione viene soddisfatta." È un limite in byte, non in tempo, quindi la durata della finestra retroattiva cambia da una sessione all'altra.

Senza il componente aggiuntivo, i controlli nella pagina Recording Settings di LogRocket sono limiti e filtri, non tassi: mettere in pausa la registrazione, un limite mensile o giornaliero di sessioni e blocchi per posizione, indirizzo IP, versione dell'app o user agent. La documentazione pubblica di LogRocket non descrive alcun parametro SDK per un tasso di campionamento e non pubblica alcun tasso consigliato.

Microsoft Clarity campiona le registrazioni delle sessioni?

Le FAQ di Clarity dicono di no, e poi elencano un limite. Sotto "Perché dovrei usare Clarity?" promettono "Nessun campionamento (cioè il tracciamento di una sola parte del traffico del tuo sito)" e "questi siti non hanno limiti di traffico". Più in basso, la stessa pagina risponde a "Quante sessioni può registrare Clarity?" con "Clarity registra fino a 100.000 sessioni per progetto al giorno". Una terza risposta aggiunge: "Clarity traccia tutte le sessioni, ma le registrazioni potrebbero non essere disponibili per tutte".

Messe insieme, queste frasi dicono che Clarity traccia ogni sessione ma pone un tetto alle registrazioni, e non documenta come sceglie quali sessioni registrare oltre quel tetto. Clarity non offre nessuna impostazione per il tasso di campionamento.

Come funziona sessionReplaySampleRate di Datadog?

Datadog annida due percentuali. sessionSampleRate "controlla la percentuale di sessioni complessive che vengono tracciate" e ha come valore predefinito 100. sessionReplaySampleRate "si applica dopo il tasso di campionamento complessivo e controlla la percentuale di sessioni tracciate come Browser RUM e Session Replay". Entrambi accettano valori da 0 a 100, non da 0 a 1.

La guida al campionamento di Datadog porta un esempio: "Se imposti sessionSampleRate a 60 e sessionReplaySampleRate a 50, il 40% delle sessioni viene scartato, il 30% delle sessioni viene raccolto come Browser RUM e il 30% delle sessioni viene raccolto come Browser RUM e Session Replay". Il valore predefinito è cambiato con una versione major. Dalla versione 5.0.0 del Browser SDK, "il valore predefinito del parametro di inizializzazione sessionReplaySampleRate è 0. Le versioni precedenti dell'SDK usano 100".

Come si confrontano i fornitori sul tasso di campionamento delle session replay?

Che tasso di campionamento delle session replay dovresti scegliere?

Parti dal problema più raro che vuoi vedere, non dal budget. Il calcolo è semplice. Se un bug colpisce una sessione su 400 e registri il 10% delle sessioni, lo catturi circa una volta ogni 4.000 sessioni. Abbassa il tasso e l'attesa cresce in proporzione. Il tasso sugli errori di Sentry esiste perché un tasso fisso penalizza gli eventi rari, mentre i gruppi di trigger di PostHog e le condizioni di LogRocket ti permettono di tenere il 100% su checkout o registrazione e di campionare tutto il resto.

Prima di mettere in produzione un tasso, fai due verifiche. La prima: controlla quale valore predefinito usa davvero la tua installazione, perché Sentry e Datadog pubblicano entrambi uno 0 che significa "non registrare nulla". La seconda: conta entrambi i lati. Sessioni per tasso dà il numero di registrazioni, che è ciò che fatturano i piani a registrazione e ciò che la tua revisione sulla privacy deve coprire. Il campionamento riduce l'esposizione oltre che il costo, e il nostro confronto tra strumenti di session replay lo analizza fornitore per fornitore.

Le istruzioni di installazione dello script di registrazione di Flowsery dicono: "La registrazione e il campionamento AI sono entrambi al 100% se non vengono modificati esplicitamente". Ogni sessione viene registrata e analizzata dall'AI nella session replay AI di Flowsery, a meno che tu non abbassi il tasso.

Domande frequenti

Cosa significa replaysSessionSampleRate 0.1 in Sentry?

Significa che Sentry registra circa il 10% delle sessioni per intero, fin dal momento in cui iniziano. La documentazione di Sentry descrive 1.0 come la raccolta di tutte le replay e 0 come nessuna raccolta.

Qual è il tasso di campionamento predefinito delle session replay in Sentry?

Il riferimento alla configurazione dell'SDK indica 0 sia per replaysSessionSampleRate sia per replaysOnErrorSampleRate. Il Loader Script di Sentry usa invece 0.1 e 1 come configurazione predefinita.

replaysOnErrorSampleRate registra ciò che è successo prima dell'errore?

Sì. Per le sessioni non campionate, Sentry tiene in memoria gli ultimi 60 secondi, e quando un errore viene campionato invia quel buffer più il resto della sessione.

Posso scegliere quali sessioni campiona PostHog?

No. PostHog trasforma l'ID della sessione in un numero tra 0 e 1 con un hash e registra la sessione se quel numero è inferiore al tuo tasso. La sua documentazione afferma: "Non puoi scegliere quali sessioni vengono campionate".

sessionReplaySampleRate di Datadog è una percentuale di tutte le sessioni?

No. È una percentuale delle sessioni già conservate da sessionSampleRate. Con 60 e 50, l'esempio di Datadog raccoglie le replay per il 30% di tutte le sessioni.

Microsoft Clarity registra ogni sessione?

Le FAQ di Clarity dicono che non fa campionamento, ma dicono anche che Clarity registra fino a 100.000 sessioni per progetto al giorno e che le registrazioni "potrebbero non essere disponibili per tutte le sessioni".

Cosa succede alle sessioni che Sentry non campiona?

Sentry tiene la sessione in un buffer in memoria invece di scartarla del tutto. La pagina di configurazione descrive questo buffer come gli ultimi 60 secondi conservati, quindi scorre in avanti per tutta la visita. Quando si verifica un errore, viene controllato replaysOnErrorSampleRate. Se rientra nel campione, Sentry invia il buffer più il resto della sessione. Se non rientra, scarta il buffer. Una sessione senza errori non invia nulla a Sentry.

Con quale tasso di campionamento consiglia di iniziare PostHog?

La documentazione di PostHog consiglia di iniziare catturando il 100% delle sessioni e di abbassare il tasso solo se serve. È l'opposto della tabella di Sentry, che consiglia di scendere all'1% con volumi di traffico elevati. Coincide anche con la soluzione di ripiego che PostHog crea quando elimini l'ultimo gruppo di trigger: un gruppo "Record all sessions" al 100% di campionamento e senza condizioni.

Il campionamento condizionale di LogRocket è incluso in ogni piano?

LogRocket vende Conditional Recording, la funzione che imposta un tasso di campionamento per condizione, come componente aggiuntivo separato per i clienti Pro ed Enterprise. I piani che non lo includono hanno limiti e filtri: pausa della registrazione, tetto mensile o giornaliero di sessioni e blocchi per posizione, indirizzo IP, versione dell'app o user agent. Nessuno di questi funziona come tasso di campionamento.

Come riduce rrweb i dati all'interno di una sessione registrata?

rrweb riduce i dati dentro ogni registrazione con la sua opzione sampling, non saltando intere sessioni. La sua ricetta per il risparmio di spazio limita gli eventi di scroll a uno ogni 150 millisecondi e conserva solo l'ultimo valore di una sequenza di digitazione in un campo. Ogni sessione viene comunque registrata, e a ridursi è solo il volume di eventi al suo interno.