You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Commit 0dcc0b8
Browse filesBrowse the repository at this point in the historyBrowse files
Copy file name to clipboardExpand all lines: en/rum/best-practices/sampling.mdx
+5-1Lines changed: 5 additions & 1 deletion
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -309,7 +309,11 @@ The base rule uses `hash(userId) % 100` instead of `Math.random()`, which brings
309
309
310
310
## Best practice 3: full error capture with proportional sampling for the rest
311
311
312
-
A common requirement is "cut data volume to 20%, but never miss an error". Setting `sessionSampleRate` to 20 will not do it: sampling works per session, and a session that loses the draw reports nothing at all — errors included (rule 1). You would lose roughly four fifths of your errors along with the volume. The correct shape is to collect every session so no error is lost, then bucket on a stable key inside `beforeSend` so only the winning share keeps full data:
312
+
<Note>
313
+
Starting with Web SDK **0.3.0**, enable `sessionOnError` (and `sessionReplayOnError` if you need error replays) to capture error sessions without writing your own `beforeSend`; see [on-error session capture](/en/rum/sdk/web/advanced-config#on-error-session-capture) for configuration, billing, and limitations. The recipe below remains available for older versions or custom event filtering. Its failed-request filtering differs from the new options: a failed resource event alone does not trigger on-error capture.
314
+
</Note>
315
+
316
+
A common requirement is "cut data volume to 20%, but never miss an error". Setting `sessionSampleRate` to 20 will not do it: sampling works per session, and a session that loses the draw reports nothing at all — errors included (rule 1). You would lose roughly four fifths of your errors along with the volume. The custom filtering recipe below collects every session so no error is lost, then buckets on a stable key inside `beforeSend` so only the winning share keeps full data:
313
317
314
318
-**Error events**: always kept — 100% of errors
315
319
-**Failed requests**: always kept — 100% of API failures (HTTP 5xx and request failures are resource events, not error events)
Copy file name to clipboardExpand all lines: en/rum/quickstart/app-management.mdx
+4Lines changed: 4 additions & 0 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -307,10 +307,14 @@ The **Remote Configuration** tab lets you adjust collection and privacy paramete
307
307
|------|------|------|
308
308
|**Session sample rate**| Integer 0–100 (%) | Percentage of sessions collected. Leave it empty to skip delivering this field; clients keep the value set at SDK initialization |
309
309
|**Session replay sample rate**| Integer 0–100 (%) | Percentage of sessions recorded by Session Replay. If empty, the SDK setting applies |
310
+
|**On-error session capture** (`sessionOnError`) | On / Off / Use SDK setting | For sessions missed by session sampling, uploads up to the last minute of events on error and continues collection; requires Web SDK 0.3.0 or later |
311
+
|**On-error replay capture** (`sessionReplayOnError`) | On / Off / Use SDK setting | For collected sessions missed by replay sampling, uploads buffered replay on error and continues recording; requires Web SDK 0.3.0 or later |
310
312
|**Trace sample rate**| Integer 0–100 (%) | A second session-level sampling pass within already-collected sessions, deciding which sessions inject trace headers into eligible requests; the outcome is consistent within one session. Overall trace coverage is roughly *session sample rate × trace sample rate*. If empty, the SDK setting applies |
311
313
|**Replay privacy level**|`mask` / `mask-user-input` / `allow`| Default masking of page content in Session Replay: `mask` obscures text and hides input values; `mask-user-input` keeps page text and hides only what users typed; `allow` records the page as it is. Loosening the level starts collecting content that was not collected before, and replays already uploaded cannot be retroactively masked. The console asks you to confirm again before publishing |
312
314
|**Custom configuration keys**| Key–value pairs typed as string / number / boolean / JSON | Delivered to clients together with the remote configuration and read by your application code; the platform does not interpret them. Up to 5 keys; each key name is at most 64 bytes (counted in UTF-8, not characters), each value at most 4 KB and nesting at most 3 levels (objects and arrays each count one level), and all custom entries together at most 16 KB |
313
315
316
+
The two on-error options are independent: **On** delivers `true`, **Off** delivers `false`, and **Use SDK setting** omits the field so the corresponding `init()` option applies (off if unset). Browser applications require Web SDK 0.3.0 or later with `remoteConfigurationEnabled: true` at initialization. Turning off on-error capture does not affect sessions selected by ordinary sampling. See [Web SDK on-error session capture](/en/rum/sdk/web/advanced-config#on-error-session-capture) for scope, billing, and limitations.
317
+
314
318
iOS, Android, Flutter, and WeChat Mini Program applications also show the **Remote Configuration** tab, but their SDKs read only the **session sample rate** and **custom configuration keys** (none of them has Session Replay; the other values are neither delivered nor effective). Every SDK has to opt in with `remoteConfigurationEnabled: true` at initialization (off by default; an application that has not opted in never requests the configuration). On iOS this requires SDK 0.6.0 or later, see [iOS SDK Advanced Configuration](/en/rum/sdk/ios/advanced-config#remote-configuration); on Android it requires SDK 0.7.0 or later, see [Android SDK Advanced Configuration](/en/rum/sdk/android/advanced-config#remote-configuration-adjust-the-sample-rate-from-the-console); on Flutter it requires `flashcat_flutter_plugin` 0.2.0 or later, see [Flutter SDK Advanced Configuration](/en/rum/sdk/flutter/advanced-config#remote-configuration).
Copy file name to clipboardExpand all lines: en/rum/sdk/web/advanced-config.mdx
+44-3Lines changed: 44 additions & 3 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -326,9 +326,50 @@ flashcatRum.init({
326
326
```
327
327
328
328
<Warning>
329
-
Sampled-out sessions will not collect any page views or related telemetrydata.
329
+
By default, sessions missed by ordinary sampling do not collect page views or related telemetry. Enabling on-error capture below allows buffered data to be uploaded when an error occurs.
330
330
</Warning>
331
331
332
+
### On-error session capture
333
+
334
+
Web SDK **0.3.0 and later** can capture sessions and replays that report an error in addition to ordinary sampling. Both options are booleans, default to `false`, and apply only to sessions **not selected** by the corresponding sample rate. Sessions already selected keep their normal collection behavior.
335
+
336
+
| Option | Applies to | On the first error |
337
+
|------|----------|----------------|
338
+
|`sessionOnError`| Sessions not selected by `sessionSampleRate`| Uploads up to the last minute of buffered RUM events, then continues normal collection and upload |
339
+
|`sessionReplayOnError`| Collected sessions whose replay was not selected by `sessionReplaySampleRate`| Uploads up to the last minute of buffered replay, then continues normal recording and upload |
340
+
341
+
For example, keep 20% of ordinary sessions and capture error sessions and their replays from the remainder:
342
+
343
+
```javascript
344
+
flashcatRum.init({
345
+
applicationId:"<YOUR_APPLICATION_ID>",
346
+
clientToken:"<YOUR_CLIENT_TOKEN>",
347
+
sessionSampleRate:20,
348
+
sessionReplaySampleRate:0,
349
+
sessionOnError:true,
350
+
sessionReplayOnError:true
351
+
});
352
+
```
353
+
354
+
-**Buffer first, upload on error**: sessions missed by ordinary sampling collect into memory from the start and retain a limited history. The first qualifying error releases that history. The lookback is at most one minute, not a guaranteed full minute, and cannot recover data from before SDK initialization or recording started.
355
+
-**No error means no storage or charge**: if a session retained by `sessionOnError` never reports an error, neither its events nor its replay are uploaded, and it incurs no session charge. With only `sessionReplayOnError` enabled, candidate replays without errors are not uploaded or charged, but RUM sessions selected by ordinary sampling are still uploaded and billed normally.
356
+
-**Each captured session counts once**: ordinary sampling and on-error capture do not count the same session twice. On-error sessions count as actual sessions in statistics, without extrapolation by `1 / sessionSampleRate`, and repeated errors do not count them again.
357
+
-**A RUM error event triggers capture**: examples include automatically captured JavaScript errors and errors reported with `addError()`. Errors discarded by `beforeSend` or rate limiting, and the SDK's own errors, do not trigger capture. A failed request or HTTP 5xx resource event alone does not trigger capture.
358
+
359
+
<Note>
360
+
At `sessionSampleRate: 100`, `sessionOnError` has no additional effect; at `sessionReplaySampleRate: 100`, `sessionReplayOnError` has no additional effect. If `sessionSampleRate` is `0` and `sessionOnError` is off, enabling only `sessionReplayOnError` cannot collect any sessions. To keep only error sessions and their replays, set both sample rates to `0` and enable both on-error options.
361
+
</Note>
362
+
363
+
#### Known limitations
364
+
365
+
-**SPA replays do not look back across views**: the replay reaches back only to the start of the view where the error occurred, up to one minute. RUM events can look back up to one minute across views.
366
+
-**Leaving immediately after an error can lose history**: closing or navigating away within seconds of the first error can lose part of a large upload (roughly above 64 KiB) because browsers limit data sent at page exit. Compression does not guarantee delivery. The SDK sends views and errors first; older other events and the final view update may be lost.
367
+
-**Buffering replay still has a performance cost**: a large, frequently changing DOM can overflow the buffer and repeatedly trigger full snapshots, adding main-thread work and shortening the available replay history. Prefer enabling only `sessionOnError` on such pages.
368
+
-**Manual recording has no earlier replay history**: if you control recording with `startSessionReplayRecording()`, explicitly set `startSessionReplayRecordingManually: true`. In particular, with remote configuration enabled, the recorder may start automatically even when the initial replay sample rate is `0`. Do not rely on a rate of `0` to wait for consent. Actions before manual recording starts cannot be recovered.
369
+
-**Withdrawing consent does not cancel an already-triggered upload**: if a session has already reported an error, withdrawing tracking consent still uploads its buffered data collected while consent was granted.
370
+
371
+
You can also change both options through [remote configuration](/en/rum/quickstart/app-management#remote-configuration).
372
+
332
373
## User Tracking Consent
333
374
334
375
To comply with privacy regulations like GDPR and CCPA, Flashduty RUM allows setting user tracking consent state during initialization:
0 commit comments