Configure session filters

By default, RUM sends light measurements (web vitals, view counts, error counts) for every session. Detail collection (full error stacks, click targets, resource timings) and session replay activate only when a session matches a filter.

This is the core cost-control mechanism: capture every user lightly, and only the interesting ones in detail.

Filter types

`filter_type`	Activates on
`error`	The session has thrown one or more errors.
`slow_performance`	A web vital exceeded a threshold (LCP, FCP, CLS).
`custom`	Any condition you define via the `conditions` map.

Each filter has:

name — display label.
filter_type — one of the above.
conditions — type-specific config.
capture_replay — if true, also activate session replay (loads the rrweb chunk).
enabled — toggle off without deleting.
priority — when multiple filters could match, lowest priority wins (today, all matching filters activate).

Examples

”Always capture detail for sessions with errors”

curl -X POST "https://api.siteqwality.com/rum/$APP_ID/filters" \
  -H "Authorization: Bearer $SITEQWALITY_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "name": "Error sessions — capture detail",
    "filter_type": "error",
    "conditions": {},
    "capture_replay": false,
    "enabled": true,
    "priority": 100
  }'

Result: any session that hits an error gets full error stacks, click targets, and resource timings.

”Replay errored sessions”

curl -X POST "https://api.siteqwality.com/rum/$APP_ID/filters" \
  -H "Authorization: Bearer $SITEQWALITY_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "name": "Error sessions — replay",
    "filter_type": "error",
    "conditions": {},
    "capture_replay": true,
    "enabled": true,
    "priority": 50
  }'

Result: errored sessions get full detail and replay.

”Replay slow LCP sessions”

curl -X POST "https://api.siteqwality.com/rum/$APP_ID/filters" \
  -H "Authorization: Bearer $SITEQWALITY_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "name": "Slow LCP",
    "filter_type": "slow_performance",
    "conditions": { "lcp_ms_threshold": 2500 },
    "capture_replay": true,
    "enabled": true,
    "priority": 75
  }'

Result: any session with LCP > 2.5s gets replay.

”Custom — match logged-in admin users”

curl -X POST "https://api.siteqwality.com/rum/$APP_ID/filters" \
  -H "Authorization: Bearer $SITEQWALITY_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "name": "Admin sessions",
    "filter_type": "custom",
    "conditions": { "user_attribute": "role", "user_attribute_value": "admin" },
    "capture_replay": true,
    "enabled": true,
    "priority": 25
  }'

Custom filter conditions are a free-form JSON object — the dashboard builder gives you a UI; via API you compose them by key/value matches against session metadata.

Sampling vs filtering

Both reduce volume. The difference:

Sampling is random — keep N% of sessions regardless of content.
Filtering is targeted — keep sessions matching a condition.

SiteQwality currently uses filtering, not sampling. For “I want 1% of all sessions replayed at random” the workaround today is a custom filter that matches based on a hash of the session ID — talk to support for the canonical pattern.

Recommended starting filter set

For a production SaaS:

Error sessions — replay (capture_replay: true). All errored sessions get the full picture.
Slow LCP — capture detail (capture_replay: false). LCP > 4s; gets click targets and resource timings to diagnose.
Admin/internal sessions — replay (capture_replay: true). For when staff trip over a bug.

Keep total active replay volume low — replay segments are large and storage adds up.