Wie eine Session-Replay-Sampling-Rate in Sentry, PostHog und anderen Tools funktioniert

Was ist eine Session-Replay-Sampling-Rate?

Eine Session-Replay-Sampling-Rate ist der Anteil der Nutzersitzungen, den ein Replay-Tool aufzeichnet, meist geschrieben als Bruch zwischen 0 und 1 oder als Prozentsatz zwischen 0 und 100. Bei einer Rate von 0.1 wird ungefähr eine von zehn Sitzungen vollständig aufgezeichnet, die anderen neun nicht. Die Dokumentation von Sentry sagt es in einer Zeile: "Sampling controls how much traffic results in a Session Replay."

Die Rate wird einmal entschieden, wenn die Sitzung beginnt, ein ausgesampelter Besucher bleibt also für den ganzen Besuch ausgesampelt. Das ist wichtig, weil ein Session Replay nur als Ganzes Sinn ergibt: Eine Aufzeichnung, der ihr erster vollständiger DOM-Snapshot fehlt, lässt sich nicht abspielen.

Die Anbieter sind sich uneinig über die Einheit, den Standardwert und den Ort, an dem Sie ihn setzen. Die Abschnitte unten zitieren jeweils die Dokumentation des Anbieters selbst.

Wie unterscheidet sich Sampling auf Sitzungsebene von Sampling auf Event-Ebene?

Sampling auf Sitzungsebene entscheidet, ob eine Sitzung überhaupt aufgezeichnet wird. Sampling auf Event-Ebene zeichnet die Sitzung auf, verwirft oder drosselt aber einige Events darin. Das erste steuert, wie viele Replays Sie speichern. Das zweite steuert, wie schwer jedes Replay ist.

Der Open-Source-Recorder rrweb zeigt Sampling auf Event-Ebene deutlich. Seine Option sampling nimmt Schlüssel wie mousemove, scroll, media und input, und sein Speicher-Rezept setzt scroll: 150 mit dem Kommentar "do not emit twice in 150ms" und input: 'last', sodass nur der Endwert einer getippten Folge erhalten bleibt. Jede Sitzung wird weiterhin aufgezeichnet, nur mit weniger Events.

Keines von beiden ist dasselbe wie das Sampling, das ein Analytics-Bericht anwendet, wenn er Summen aus einer Teilmenge der Zeilen hochrechnet. Diese Art behandelt wann in einem Bericht das Daten-Sampling einsetzt.

Wie nutzt Sentry replaysSessionSampleRate und replaysOnErrorSampleRate?

Sentry nutzt zwei Raten, gesetzt in Sentry.init(). Die Konfigurationsreferenz definiert sie so:

• replaysSessionSampleRate, Typ number, Standard 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, Typ number, Standard 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."

Die Setup-Seite von Sentry erklärt die Reihenfolge. replaysSessionSampleRate wird zuerst geprüft. Wird die Sitzung gesampelt, gilt: "Full session recording starts and is sent to Sentry in real-time." Wird sie es nicht, ist die Aufzeichnung "buffered in memory only (last 60 seconds kept)". Tritt in einer nicht gesampelten Sitzung ein Fehler auf, wird replaysOnErrorSampleRate geprüft, und ein Treffer sendet "Buffered 60 seconds + rest of session". Ein Fehlschlag verwirft den Puffer, und nichts wird gesendet.

Sentry veröffentlicht für dieselben Optionen zwei verschiedene Standardwerte. Die Konfigurationsreferenz nennt für beide 0, eine SDK-Installation, die keine von beiden setzt, zeichnet also nichts auf. Das Snippet für das Loader Script auf der Setup-Seite sagt, es "will initialize Replay with the default config: replaysSessionSampleRate: 0.1, replaysOnErrorSampleRate: 1". Welchen Standard Sie bekommen, hängt davon ab, wie Sie Sentry installiert haben, und es lohnt sich zu prüfen, welcher in Ihrem Projekt läuft.

Sentry ist außerdem der einzige Anbieter hier, der eine Tabelle mit empfohlenen Raten veröffentlicht, unter dem Titel "Recommended Production Sample Rates":

Der Rat zur Fehlerrate ist unmissverständlich: "Keep replaysOnErrorSampleRate at 1.0 - error sessions provide the most debugging value." Zum Testen empfiehlt Sentry replaysSessionSampleRate: 1.0.

Wie sampelt PostHog Session-Aufzeichnungen?

PostHog setzt seine Sampling-Rate in den Einstellungen für die Replay-Ingestion, nicht im SDK-Code. Jede "trigger group" hat ihre eigenen Bedingungen (URL-Trigger, Event-Trigger, ein Feature Flag) plus "its own sample rate, minimum duration, and match type". Eine Sitzung wird aufgezeichnet, wenn sie zu irgendeiner Gruppe passt.

Das Sampling von PostHog ist deterministisch. Die Dokumentation sagt: "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%)." Dieselbe Sitzungs-ID bekommt immer dieselbe Antwort, "even across page refreshes". Die Dokumentation sagt auch, worauf Sie verzichten: "You can't choose which sessions are sampled."

Die Rate greift nach den Bedingungen einer Gruppe, nicht parallel zu ihnen. Das Beispiel von PostHog lautet "a group with an exception event trigger and a 20% sample rate records 20% of the sessions that threw an exception", nicht 20% aller Sitzungen plus jede Exception. Wenn Sie Ihre letzte Trigger-Gruppe löschen, ersetzt PostHog sie durch eine Standardgruppe "Record all sessions" mit 100% Sampling. Die veröffentlichte Empfehlung läuft in die entgegengesetzte Richtung zur Tabelle von Sentry: "Our recommendation is to start with capturing 100% of sessions and decrease it as needed."

Wie handhabt LogRocket das Sampling?

LogRocket setzt Sampling-Raten innerhalb von Conditional Recording, das die Dokumentation als "Available as a separate add on for Pro and Enterprise customers" kennzeichnet. Sie legen eine Aufzeichnungsbedingung an, etwa einen Klick auf einen Checkout-Button oder einen Netzwerkfehler, und "set the sampling rate" dafür. Die Dokumentation nennt "record 20% of users who visit our checkout page" als Beispiel. Mehrere Bedingungen "will be considered separately, not cumulatively, so a session needs to meet only one condition in order to be recorded."

Weil eine Bedingung mitten in einem Besuch auslösen kann, behält LogRocket einen Rückblick: "All recordings record up to 10MB of activity prior to the recording condition being met." Das ist eine Byte-Grenze, keine Zeitgrenze, die Länge des Rückblicks schwankt also von Sitzung zu Sitzung.

Ohne das Add-on sind die Einstellungen auf der Seite Recording Settings von LogRocket Grenzen und Filter, keine Raten: Aufzeichnung pausieren, ein monatliches oder tägliches Sitzungslimit und Sperren nach Standort, IP-Adresse, App-Version oder User Agent. Die öffentliche Dokumentation von LogRocket beschreibt keinen SDK-Parameter für eine Sampling-Rate und veröffentlicht keine empfohlene Rate.

Sampelt Microsoft Clarity Session-Aufzeichnungen?

Die FAQ von Clarity sagt nein und nennt dann eine Obergrenze. Unter "Why should I use Clarity?" verspricht sie "No sampling (that is, tracking only a portion of your site's traffic)" und "there are no traffic limits on these sites." Weiter unten beantwortet dieselbe Seite "How many sessions can Clarity record?" mit "Clarity records up to 100,000 sessions per project per day." Eine dritte Antwort ergänzt: "Clarity tracks all sessions, but recordings might not be available for all sessions."

Zusammen gelesen erfasst Clarity jede Sitzung, begrenzt aber die Aufzeichnungen, und dokumentiert nicht, wie es jenseits der Grenze auswählt, welche Sitzungen aufgezeichnet werden. Clarity bietet keine Einstellung für eine Sampling-Rate.

Wie funktioniert sessionReplaySampleRate bei Datadog?

Datadog verschachtelt zwei Prozentsätze. sessionSampleRate "controls the percentage of overall sessions being tracked" und steht standardmäßig auf 100. sessionReplaySampleRate "is applied after the overall sample rate, and controls the percentage of sessions tracked as Browser RUM & Session Replay." Beide nehmen Werte von 0 bis 100, nicht von 0 bis 1.

Der Sampling-Leitfaden von Datadog rechnet ein Beispiel durch: "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." Der Standardwert hat sich mit einer Hauptversion verschoben: Ab Browser SDK v5.0.0 gilt, "the sessionReplaySampleRate initialization parameter default value is 0. Previous versions of the SDK use 100."

Wie schneiden die Anbieter bei der Session-Replay-Sampling-Rate im Vergleich ab?

Welche Session-Replay-Sampling-Rate sollten Sie wählen?

Gehen Sie vom seltensten Problem aus, das Sie sehen müssen, nicht vom Budget. Die Rechnung ist einfach: Wenn ein Bug eine von 400 Sitzungen trifft und Sie 10% der Sitzungen aufzeichnen, erfassen Sie ihn etwa einmal alle 4,000 Sitzungen. Senken Sie die Rate, und die Wartezeit wächst proportional. Die Fehlerrate von Sentry existiert, weil eine pauschale Rate gegen seltene Ereignisse arbeitet, und die Trigger-Gruppen von PostHog und die Bedingungen von LogRocket lassen Sie 100% bei Checkout oder Registrierung behalten, während Sie alles andere sampeln.

Zwei Prüfungen, bevor Sie eine Rate ausrollen. Erstens: Bestätigen Sie den Standardwert, den Ihre Installation tatsächlich nutzt, denn Sentry und Datadog veröffentlichen beide eine 0, die "nichts aufzeichnen" bedeutet. Zweitens: Zählen Sie beide Seiten. Sitzungen mal Rate ergibt die Aufzeichnungen, und genau die rechnet ein Tarif pro Aufzeichnung ab und genau die muss Ihre Datenschutzprüfung abdecken. Sampling senkt die Exposition ebenso wie die Kosten, was unser Vergleich von Session-Replay-Tools Anbieter für Anbieter betrachtet.

Die Installationsanleitung von Flowsery für sein Aufzeichnungsskript hält fest: "Recording and AI sampling are both 100% unless explicitly changed." Jede Sitzung wird aufgezeichnet und von der KI im AI Session Replay von Flowsery geprüft, sofern Sie die Rate nicht senken.

Häufig gestellte Fragen

Was bedeutet replaysSessionSampleRate 0.1 in Sentry?

Es bedeutet, dass Sentry etwa 10% der Sitzungen ab ihrem Beginn vollständig aufzeichnet. Die Dokumentation von Sentry beschreibt 1.0 als Erfassung aller Replays und 0 als Erfassung keines einzigen.

Was ist die Standard-Session-Replay-Sampling-Rate in Sentry?

Die SDK-Konfigurationsreferenz nennt 0 sowohl für replaysSessionSampleRate als auch für replaysOnErrorSampleRate. Das Loader Script von Sentry verwendet stattdessen 0.1 und 1 als Standardkonfiguration.

Zeichnet replaysOnErrorSampleRate auf, was vor dem Fehler passiert ist?

Ja. Sentry puffert bei nicht gesampelten Sitzungen die letzten 60 Sekunden im Speicher, und ein gesampelter Fehler sendet diesen Puffer plus den Rest der Sitzung.

Kann ich wählen, welche Sitzungen PostHog sampelt?

Nein. PostHog hasht die Sitzungs-ID zu einer Zahl zwischen 0 und 1 und zeichnet die Sitzung auf, wenn diese Zahl unter Ihrer Rate liegt. Die Dokumentation hält fest: "You can't choose which sessions are sampled."

Ist sessionReplaySampleRate bei Datadog ein Prozentsatz aller Sitzungen?

Nein. Es ist ein Prozentsatz der Sitzungen, die sessionSampleRate bereits behalten hat. Bei 60 und 50 erfasst das eigene Beispiel von Datadog Replays für 30% aller Sitzungen.

Zeichnet Microsoft Clarity jede Sitzung auf?

Die FAQ von Clarity sagt, es sample nicht, sagt aber auch, dass Clarity bis zu 100,000 Sitzungen pro Projekt und Tag aufzeichnet und dass Aufzeichnungen "might not be available for all sessions."

Was passiert mit Sitzungen, die Sentry nicht sampelt?

Sentry puffert die Sitzung im Speicher, anstatt sie komplett zu verwerfen. Die Setup-Seite beschreibt diesen Puffer als die letzten 60 Sekunden, die behalten werden, er rollt also über den ganzen Besuch mit. Tritt ein Fehler auf, wird replaysOnErrorSampleRate geprüft: Ein Treffer sendet den Puffer plus den Rest der Sitzung, ein Fehlschlag verwirft den Puffer. Eine Sitzung ohne Fehler sendet nichts an Sentry.

Welche Sampling-Rate empfiehlt PostHog zum Start?

PostHogs Dokumentation empfiehlt, mit 100% der Sitzungen zu starten und die Rate erst bei Bedarf zu senken. Das läuft Sentrys Tabelle entgegen, die bei hohem Traffic eine Senkung auf 1% empfiehlt. Es passt auch zu der Ersatzgruppe, die PostHog anlegt, wenn Sie Ihre letzte Trigger-Gruppe löschen: eine Gruppe "Record all sessions" mit 100% Sampling und ohne Bedingungen.

Ist LogRockets bedingtes Sampling in jedem Plan enthalten?

LogRocket verkauft Conditional Recording, die Funktion, die eine Sampling-Rate pro Bedingung festlegt, als separates Add-on für Pro- und Enterprise-Kunden. Pläne ohne dieses Add-on erhalten stattdessen Limits und Filter: Aufzeichnung pausieren, ein monatliches oder tägliches Sitzungslimit sowie Sperren nach Standort, IP-Adresse, App-Version oder User-Agent. Keine dieser Optionen wirkt als Sampling-Rate.

Wie reduziert rrweb Daten innerhalb einer aufgezeichneten Sitzung?

rrweb kürzt die Daten innerhalb jeder Aufzeichnung über seine sampling-Option, statt ganze Sitzungen zu überspringen. Sein Speicher-Rezept begrenzt Scroll-Events auf eines alle 150 Millisekunden und behält nur den letzten Wert einer getippten Eingabesequenz. Jede Sitzung wird weiterhin aufgezeichnet, nur die Menge der Events darin schrumpft.