Skip to main content
The widget is configured from two places: a small set of install-time data-* attributes on the <script> tag (set once, at install), and the remote configuration fetched from your dashboard at runtime (change any time, no code edit). Behavior toggles — tracking mode, autocapture, Web Vitals, replay — live in the remote config; the tag only carries identity and a few advanced switches.

Install-time data attributes

Read from the tracker’s own <script> tag. Only data-site-id is required; the rest are optional.

Global event properties

Any attribute on the script tag prefixed with event- becomes a global property merged into every event’s props (an explicit props value on a specific event wins):
Here every event carries { plan: 'pro', env: 'production' }.

Remote configuration

Before its first pageview, the widget fetches your site’s config from:
{trackingKey} is the same value as data-site-id. This endpoint is public and unauthenticated (it only exposes on/off toggles, never analytics data), and it is documented in full — including its own rate-limit bucket — in Tracking configuration. If the fetch fails (network / 404 / bad JSON), the widget boots on safe schema defaults instead of not loading. The response is a flat JSON object:

What each field controls

Where to change these

Every remote toggle is set from the site’s settings in your dashboard, or through the API:
  • Tracking modePATCH /api/sites/{siteKey}/tracking-mode (Sites).
  • Web Vitals / error tracking / session replay — the enable endpoints in Tracking configuration.
Changing any of them invalidates the config cache, so the next config fetch returns the new values.