Widget configuration
Position, accent, screenshots, privacy-policy link, and stable element targeting — from project settings or per-page attributes.
Most widget settings live server-side in project settings, so you can change them without redeploying. Per-page data-* attributes and runtime calls override them. Precedence, lowest to highest: **server config → data-* attributes → runtime iterateTo(...) calls**.
Server settings
| Setting | Values | Notes |
|---|---|---|
| Position | bottom-right · bottom-left | Where the launcher sits |
| Accent color | hex | Tints the launcher and panel |
| Title | string | Heading shown at the top of the panel |
| Screenshots | on · off | Enables the capture + annotation flow |
| Privacy policy URL | URL | Linked from the panel when set |
Data attributes
| Attribute | Purpose |
|---|---|
data-key | Required. Your project public key (pk_...). |
data-position | Override the launcher position for this page only. |
Element targeting
The widget's element picker lets users point at exactly what broke. Each selected element is reported with several selector candidates so reports stay actionable even after markup changes. Make those selectors far more stable by annotating your own markup:
html
<button
data-feedback-id="checkout-submit"
data-feedback-label="Place order button"
data-feedback-component="CheckoutForm"
>
Place order
</button>data-feedback-id— a stable, unique id. The highest-confidence selector in reports; survives refactors that break CSS selectors.data-feedback-label— a human-readable name shown in the report instead of a raw selector.data-feedback-component— the owning component name, useful for routing reports to the right team or agent.
Masking & ignoring elements
Two attributes control what the capture can see. See Privacy & masking for the full pipeline.
data-feedback-mask— force an opaque mask over an element in screenshots (account numbers, avatars, anything sensitive).data-feedback-ignore— exclude an element from captures and from the element picker entirely.