Comment fonctionne un taux d'échantillonnage du session replay dans Sentry, PostHog et les autres

Qu'est-ce qu'un taux d'échantillonnage du session replay ?

Un taux d'échantillonnage du session replay est la part des sessions utilisateur qu'un outil de replay enregistre, généralement exprimée comme une fraction entre 0 et 1 ou un pourcentage entre 0 et 100. À un taux de 0.1, environ une session sur dix est enregistrée en entier et les neuf autres ne le sont pas. La documentation de Sentry le résume en une ligne : "Sampling controls how much traffic results in a Session Replay."

Le taux est décidé une seule fois, au démarrage de la session, donc un visiteur exclu de l'échantillon le reste pendant toute la visite. C'est important parce qu'un session replay n'a de sens que complet : un enregistrement auquel manque son premier snapshot complet du DOM ne peut pas être rejoué.

Les éditeurs ne s'accordent ni sur l'unité, ni sur la valeur par défaut, ni sur l'endroit où on la règle. Les sections ci-dessous citent la documentation de chaque éditeur.

En quoi l'échantillonnage au niveau de la session diffère-t-il de l'échantillonnage au niveau des événements ?

L'échantillonnage au niveau de la session décide si une session est enregistrée ou non. L'échantillonnage au niveau des événements enregistre la session mais abandonne ou limite certains événements à l'intérieur. Le premier contrôle le nombre de replays que vous stockez. Le second contrôle le poids de chaque replay.

L'enregistreur open source rrweb illustre clairement l'échantillonnage au niveau des événements. Son option sampling prend des clés comme mousemove, scroll, media et input, et sa recette de stockage définit scroll: 150 avec le commentaire "do not emit twice in 150ms" et input: 'last' pour ne garder que la valeur finale d'une séquence tapée. Chaque session est toujours enregistrée, simplement avec moins d'événements.

Aucun des deux n'est l'échantillonnage qu'un rapport d'analytics applique quand il estime des totaux à partir d'un sous-ensemble de lignes. Ce cas est traité dans quand l'échantillonnage des données commence dans un rapport.

Comment Sentry utilise-t-il replaysSessionSampleRate et replaysOnErrorSampleRate ?

Sentry utilise deux taux, définis dans Sentry.init(). Sa référence de configuration les définit ainsi :

• replaysSessionSampleRate, type number, valeur par défaut 0 : "The sample rate for replays that begin recording immediately and last the entirety of the user's session. 1.0 collects all replays, and 0 collects none."
• replaysOnErrorSampleRate, type number, valeur par défaut 0 : "The sample rate for replays that are recorded when an error happens. This type of replay will record up to a minute of events prior to the error and continue recording until the session ends."

La page de configuration de Sentry explique l'ordre. replaysSessionSampleRate est vérifié en premier. Si la session est échantillonnée, "Full session recording starts and is sent to Sentry in real-time." Sinon, l'enregistrement est "buffered in memory only (last 60 seconds kept)". Quand une erreur survient dans une session non échantillonnée, replaysOnErrorSampleRate est vérifié, et un tirage positif envoie le "Buffered 60 seconds + rest of session". Un tirage négatif vide le buffer et rien n'est envoyé.

Sentry publie deux valeurs par défaut différentes pour les mêmes options. La référence de configuration indique 0 pour les deux, donc une installation par le SDK qui ne définit ni l'une ni l'autre n'enregistre rien. Le snippet du Loader Script sur la page de configuration indique qu'il "will initialize Replay with the default config: replaysSessionSampleRate: 0.1, replaysOnErrorSampleRate: 1". La valeur par défaut que vous obtenez dépend de la façon dont vous avez installé Sentry, et il vaut la peine de vérifier laquelle votre projet utilise.

Sentry est aussi le seul éditeur présenté ici qui publie un tableau de taux recommandés, sous le titre "Recommended Production Sample Rates" :

Son conseil sur le taux d'erreur est direct : "Keep replaysOnErrorSampleRate at 1.0 - error sessions provide the most debugging value." Pour les tests, il recommande replaysSessionSampleRate: 1.0.

Comment PostHog échantillonne-t-il les enregistrements de session ?

PostHog règle son taux d'échantillonnage dans les paramètres d'ingestion des replays, pas dans le code du SDK. Chaque "trigger group" a ses propres conditions (déclencheurs d'URL, déclencheurs d'événement, un feature flag) plus "its own sample rate, minimum duration, and match type". Une session est enregistrée si elle correspond à n'importe quel groupe.

L'échantillonnage de PostHog est déterministe. Sa documentation dit : "When a new session starts, PostHog converts the session ID into a number between 0 and 1 using a hash function. This number is then compared to your configured sample rate (for example, 0.1 for 10% or 0.2 for 20%)." Le même ID de session obtient toujours la même réponse, "even across page refreshes". La documentation dit aussi ce à quoi vous renoncez : "You can't choose which sessions are sampled."

Le taux s'applique après les conditions d'un groupe, pas en parallèle. L'exemple de PostHog est "a group with an exception event trigger and a 20% sample rate records 20% of the sessions that threw an exception", et non 20 % de toutes les sessions plus chaque exception. Si vous supprimez votre dernier trigger group, PostHog le remplace par un groupe par défaut "Record all sessions" à 100 % d'échantillonnage. Sa recommandation publiée va dans le sens inverse du tableau de Sentry : "Our recommendation is to start with capturing 100% of sessions and decrease it as needed."

Comment LogRocket gère-t-il l'échantillonnage ?

LogRocket règle les taux d'échantillonnage dans Conditional Recording, que sa documentation présente comme "Available as a separate add on for Pro and Enterprise customers". Vous créez une condition d'enregistrement, comme un clic sur un bouton de paiement ou une erreur réseau, et vous "set the sampling rate" pour elle. La documentation donne "record 20% of users who visit our checkout page" comme exemple. Plusieurs conditions "will be considered separately, not cumulatively, so a session needs to meet only one condition in order to be recorded."

Comme une condition peut se déclencher en milieu de visite, LogRocket conserve un historique : "All recordings record up to 10MB of activity prior to the recording condition being met." C'est une limite en octets, pas en temps, donc la durée de cet historique varie d'une session à l'autre.

Sans l'option, les réglages de la page Recording Settings de LogRocket sont des limites et des filtres, pas des taux : mise en pause de l'enregistrement, limite mensuelle ou quotidienne de sessions, et blocages par localisation, adresse IP, version d'application ou user agent. La documentation publique de LogRocket ne décrit aucun paramètre de SDK pour un taux d'échantillonnage et ne publie aucun taux recommandé.

Microsoft Clarity échantillonne-t-il les enregistrements de session ?

La FAQ de Clarity dit que non, puis mentionne un plafond. Sous "Why should I use Clarity?", elle promet "No sampling (that is, tracking only a portion of your site's traffic)" et "there are no traffic limits on these sites." Plus bas, la même page répond à "How many sessions can Clarity record?" par "Clarity records up to 100,000 sessions per project per day." Une troisième réponse ajoute : "Clarity tracks all sessions, but recordings might not be available for all sessions."

Lues ensemble, ces réponses indiquent que Clarity suit toutes les sessions mais plafonne les enregistrements, et ne documente pas comment il choisit les sessions à enregistrer au-delà du plafond. Clarity n'expose aucun réglage de taux d'échantillonnage.

Comment fonctionne le sessionReplaySampleRate de Datadog ?

Datadog imbrique deux pourcentages. sessionSampleRate "controls the percentage of overall sessions being tracked" et vaut 100 par défaut. sessionReplaySampleRate "is applied after the overall sample rate, and controls the percentage of sessions tracked as Browser RUM & Session Replay." Les deux prennent des valeurs de 0 à 100, et non de 0 à 1.

Le guide d'échantillonnage de Datadog développe un exemple : "If you set sessionSampleRate to 60 and sessionReplaySampleRate to 50, 40% of sessions are dropped, 30% of sessions are collected as Browser RUM, and 30% of sessions are collected as Browser RUM & Session Replay." La valeur par défaut a changé avec une version majeure : depuis le Browser SDK v5.0.0, "the sessionReplaySampleRate initialization parameter default value is 0. Previous versions of the SDK use 100."

Comment les éditeurs se comparent-ils sur les taux d'échantillonnage du session replay ?

Quel taux d'échantillonnage du session replay choisir ?

Partez du problème le plus rare que vous devez voir, pas du budget. Le calcul est simple : si un bug touche une session sur 400 et que vous enregistrez 10 % des sessions, vous le capturez environ une fois toutes les 4,000 sessions. Baissez le taux et l'attente s'allonge en proportion. Le taux d'erreur de Sentry existe parce qu'un taux fixe joue contre les événements rares, et les trigger groups de PostHog comme les conditions de LogRocket vous permettent de garder 100 % sur le paiement ou l'inscription tout en échantillonnant le reste.

Deux vérifications avant de mettre un taux en production. D'abord, confirmez la valeur par défaut que votre installation utilise réellement, puisque Sentry et Datadog publient tous deux un 0 qui signifie "ne rien enregistrer". Ensuite, comptez les deux côtés : le nombre de sessions multiplié par le taux donne le nombre d'enregistrements, ce qu'un forfait facturé à l'enregistrement vous fait payer et ce que votre revue de confidentialité doit couvrir. L'échantillonnage réduit l'exposition autant que le coût, ce que notre comparatif des outils de session replay examine éditeur par éditeur.

Les instructions d'installation du script d'enregistrement de Flowsery indiquent : "Recording and AI sampling are both 100% unless explicitly changed." Chaque session est enregistrée et examinée par l'IA dans l'AI session replay de Flowsery, sauf si vous baissez ce taux.

Questions fréquentes

Que signifie replaysSessionSampleRate 0.1 dans Sentry ?

Cela signifie que Sentry enregistre environ 10 % des sessions en entier dès leur démarrage. La documentation de Sentry décrit 1.0 comme la collecte de tous les replays et 0 comme n'en collectant aucun.

Quel est le taux d'échantillonnage du session replay par défaut dans Sentry ?

La référence de configuration du SDK indique 0 pour replaysSessionSampleRate comme pour replaysOnErrorSampleRate. Le Loader Script de Sentry utilise plutôt 0.1 et 1 comme configuration par défaut.

replaysOnErrorSampleRate enregistre-t-il ce qui s'est passé avant l'erreur ?

Oui. Sentry garde en mémoire tampon les 60 dernières secondes des sessions non échantillonnées, et une erreur échantillonnée envoie ce buffer plus le reste de la session.

Puis-je choisir quelles sessions PostHog échantillonne ?

Non. PostHog hache l'ID de session en un nombre entre 0 et 1 et enregistre la session si ce nombre est inférieur à votre taux. Sa documentation indique que "You can't choose which sessions are sampled."

Le sessionReplaySampleRate de Datadog est-il un pourcentage de toutes les sessions ?

Non. C'est un pourcentage des sessions déjà conservées par sessionSampleRate. À 60 et 50, l'exemple de Datadog lui-même collecte des replays pour 30 % de toutes les sessions.

Microsoft Clarity enregistre-t-il chaque session ?

La FAQ de Clarity dit qu'il ne fait aucun échantillonnage, mais aussi que Clarity enregistre jusqu'à 100,000 sessions par projet et par jour et que les enregistrements "might not be available for all sessions."

Que se passe-t-il pour les sessions que Sentry n'échantillonne pas ?

Sentry met la session en mémoire tampon au lieu de l'abandonner entièrement. La page de configuration décrit ce tampon comme les 60 dernières secondes conservées, il avance donc en continu pendant toute la visite. Quand une erreur survient, replaysOnErrorSampleRate est vérifié : un tirage positif envoie le tampon plus le reste de la session, et un tirage négatif abandonne le tampon. Une session sans erreur n'envoie rien à Sentry.

Quel taux d'échantillonnage PostHog recommande-t-il au départ ?

La documentation de PostHog recommande de commencer par capturer 100% des sessions et de ne baisser le taux qu'en cas de besoin. Cela va à l'inverse du tableau de Sentry, qui recommande de descendre à 1% pour un trafic élevé. Cela correspond aussi au groupe de repli que PostHog crée quand vous supprimez votre dernier trigger group : un groupe "Record all sessions" à 100% d'échantillonnage, sans aucune condition.

L'échantillonnage conditionnel de LogRocket est-il inclus dans tous les plans ?

LogRocket vend Conditional Recording, la fonctionnalité qui fixe un taux d'échantillonnage par condition, comme un module complémentaire séparé pour les clients Pro et Enterprise. Les plans sans ce module reçoivent à la place des limites et des filtres : mise en pause de l'enregistrement, un plafond de sessions mensuel ou journalier, et des blocages par emplacement, adresse IP, version de l'app ou user agent. Aucune de ces options ne fait office de taux d'échantillonnage.

Comment rrweb réduit-il les données à l'intérieur d'une session enregistrée ?

rrweb réduit les données à l'intérieur de chaque enregistrement via son option sampling, plutôt que de sauter des sessions entières. Sa recette de stockage limite les événements de défilement à un toutes les 150 millisecondes et ne conserve que la dernière valeur d'une séquence de saisie tapée. Chaque session reste enregistrée, seul le volume d'événements à l'intérieur diminue.