Remote configuration
Toggle SDK features from the dashboard without code changes — autocapture, session recording, sample rates, destinations.
Control SDK features from the dashboard (Settings → SDK Defaults) without code changes. The SDK fetches config from /api/d (browser alias for decide) on every page load. When a fresh merge completes (or the fetch fails and the SDK unblocks), __remote_config_loaded is set — HTTP event ingest and Google Tag client forwarding both wait on that moment so analytics toggles and gateway settings line up with whatever you configured in the dashboard.
#What's remotely configurable
Anything that doesn't need a code change to take effect:
- Autocapture allowlists / ignorelists
- Session recording on/off, sample rate, masking
- Web vitals on/off
- Per-destination forwarding (Google Tag, Meta CAPI, PostHog)
- Consent Mode v2 defaults and per-category mappings
- Chat widget visibility and welcome behaviour
- Sample rate for
$autocaptureand$rageclick
The SDK's init() config is the floor — it sets what the SDK can do. Remote config is the gate — it decides what the SDK will do, on a per-project basis. You cannot remotely enable a feature that wasn't compiled into the bundle (e.g. session recording requires the lazy chunk to be reachable from your api_host), but you can disable any feature without redeploying.
#Reload behaviour
Remote config is fetched every time init() runs, then cached in localStorage for the rest of the page. SPA route changes don't refetch. To force a refetch in a long-lived tab, call vt.updateConfig({}) — the empty merge re-fires the underlying request.
#When to use code config vs remote config
Use code (vt.init({...})) | Use remote config (dashboard) |
|---|---|
Token, api_host, persistence mode | Sample rates and rollout knobs |
| Bundle-affecting settings (chat enabled at all) | Per-environment toggles you change without deploys |
| Feature defaults you ship with the build | Operator-tunable knobs you adjust during incidents |