> ## Documentation Index
> Fetch the complete documentation index at: https://docs.orbit.devotel.io/llms.txt
> Use this file to discover all available pages before exploring further.

# Settings → Personalization: per-segment content for the web SDK

> Configure the Web Personalization console under Settings: map segments to content payloads and placement selectors, walk one setup end to end, and verify the web SDK serves it.

# Settings → Personalization

The **Personalization** page under **Settings** (`/settings/personalization`) is the operator console for the web SDK's on-site personalization. It manages the same slot-variant records covered by the [marketing-side website slots guide](/guides/website-personalization-slots), but from the settings side: name the placement, pick the segment it targets, and author the content the SDK serves. This guide walks the page's field map, one complete setup, and what to check during verification. Changes on this page and changes over the API reach the same records, so a team can split duties: marketing composes via the API, an operator tunes in the dashboard.

## 1. Where Web Personalization sits

Open **Settings → Personalization**. The page holds three things:

* **A "Create variant" dialog** — the editor for a single (slot, segment)→content mapping (covered below).
* **An embed snippet card** — a copy-ready `OrbitPersonalization` example showing `identify`, `page`, and `render` calls. Use it to paste a working starting point into your site, then replace the public key and API URL with your own.
* **A slot list** — one card per placement name, with its variants sorted by priority; each row shows the segment badge, content, CTA, priority, and active flag, plus edit/deactivate/delete actions.

The settings page manages the same slot-variant API contract as the website-slots guide: a variant is one record with a `slot` (the placement name), an optional `segment_label` (the target audience), the `content` payload, an optional `variant` tag for A/B testing, a `priority` ranking value, and an `active` switch. Segment vocabulary is the same fixed set (`champion`, `high_value_engaged`, `engaged`, `new`, `passive`, `at_risk`, `dormant`, `lost`) the CDP maintains on each contact. The website-slots guide covers the lifecycle of those segments and the lift-reporting discipline in depth; this page covers the operator workflow on the settings surface itself.

<Note>
  CDP segments vs. marketing slots. The segment labels the personalization editor targets come from the CDP lifecycle vocabulary, not from a CDN-side audience builder. The [CDP segments guide](/guides/cdp-segments) explains how contacts earn and move between those labels; the personalization console just resolves labels on every visitor, so a contact who drifts from `engaged` to `at_risk` starts seeing the at-risk variant without you editing anything.
</Note>

## 2. Map the settings fields

The variant form (Basic, CTA, and Advanced tabs) maps directly onto the slot-variant API record, in the same shape as the [Personalization API reference](/api-reference/personalization):

| Field              | What it sets on the record                                                                                     |
| ------------------ | -------------------------------------------------------------------------------------------------------------- |
| Slot id            | `slot` — the placement name the SDK renders by (`hero-banner`). Lowercase letters, digits, hyphen, underscore. |
| Target segment     | `segment_label` — the audience, or "Default (any visitor)" for the fallback.                                   |
| Content            | `content` — HTML or plain text the SDK injects, up to 5,000 characters.                                        |
| CTA text / CTA URL | `cta_text` / `cta_url` — a link rendered with the banner (https/http only, ≤500 characters).                   |
| Variant tag        | `variant` — an optional A/B identifier stamped on rendered impressions.                                        |
| Priority           | `priority` — 0–100; the higher value wins when several variants match the same visitor.                        |
| Active             | `active` — a pause switch; an inactive variant never serves.                                                   |

The slot id is the contract. Name it once per on-site placement and keep it stable — the SDK's `render('hero-banner', '#orbit-hero')` call resolves by that exact string, so renaming the slot on the settings page without updating the site selector leaves the placement unfilled.

To see what an edit will do to visitors before saving, use the **Preview** button on any slot card. Pick a segment in the dialog to see the same server-side resolution the SDK would return — the resolved variant's content, CTA, and applied segment — or a "no matching variant" miss when nothing qualifies.

The **embed snippet card** is a working starting point, not just an example. It exercises the three SDK calls verification needs: `identify` (bind the visitor when you know who they are), `page` (log a page view), and `render` (resolve and inject the slot). The **Web SDK setup** shortcut on the same card links into the developer docs where the public key is provisioned.

## 3. Walk through one setup end to end

This mirrors the end-to-end example in the website-slots guide, but through the settings page.

1. **Create the default.** Open **Create variant**, set the slot id (e.g. `hero-banner`), leave Target segment on "Default (any visitor)," type the fallback content, and save. This is the variant every visitor sees when no segment-specific variant matches — set it up first so the page never shows an empty slot.
2. **Add the per-segment treatment.** Open Create variant again with the same slot id, pick the target segment (for example `at_risk`), and write the treatment content. Give the variant a distinct Variant tag (for example `b`) so the lift report can pick it out, and keep its Active switch on.
3. **Preview.** On the slot card, open **Preview**, choose the segment you targeted, and confirm the resolved variant shows the treatment content. Repeat with no segment to confirm the default still resolves.
4. **Attach the placement to your site.** Paste the embed snippet into the page, keep the same slot id, and point the `render` call at the DOM selector you want filled (`render('hero-banner', '#orbit-hero', { html: true })`). The SDK fetches the variant from the public runtime endpoint and stamps render attributes (`data-orbit-slot`, `data-orbit-segment`, `data-orbit-variant`) plus a `personalization_rendered` event on the element.
5. **Verify the SDK serves it.** Load the site with the SDK initialized. For an identified visitor whose CDP segment matches the treatment, the slot renders the per-segment variant; a fresh or default-segmented visitor gets the default variant. A failed or timed-out (5-second ceiling) fetch degrades to the page's existing markup, so an unreachable API does not strip the slot bare.
6. **Measure.** `render()` fires a `personalization_rendered` event per serve and `track()` fires your conversion events; the slot's **lift report** joins the two over a lookback window. See the [website-slots guide](/guides/website-personalization-slots#6-prove-lift-against-the-holdout) for the variant\_a/variant\_b framing and significance threshold.

<Warning>
  The preview picker resolves against recorded segment labels server-side. A "No matching variant" result there is the same miss a browser would get — fix it before launching the placement, because a miss on the live page leaves the fallback markup (or nothing) rendered.
</Warning>

## 4. Role gating and the audit trail

Creating, updating, or deleting a variant requires the **owner or admin** role; the viewer role can read the list and run previews but cannot save. The gating is enforced on the API for both dashboard sessions and API keys.

Every mutation on this page lands in **Settings → Audit log** with the actor and the resource. The actions to filter on:

| Change          | Audit action                   |
| --------------- | ------------------------------ |
| Variant created | `personalization.slot_created` |
| Variant updated | `personalization.slot_updated` |
| Variant deleted | `personalization.slot_deleted` |

Use these to reconstruct who changed which slot and when — for example, when a site's hero copy changed at odd hours, filter the log by these three action names. See the [audit log guide](/guides/audit-log) for filtering and export.

Content saves are validated again at write time: markup that includes scripts, iframes, inline event handlers, `javascript:` URLs, or non-image `data:` URLs is rejected with a `422` rather than stored, so a pasted-in snippet with an active `<script>` fails safe. The full reject list is in the website-slots guide.

## 5. Related surfaces

* [Website personalization slots guide](/guides/website-personalization-slots) — the marketing-side slot API walkthrough, segment vocabulary, and lift-report discipline this page plugs into
* [CDP segments guide](/guides/cdp-segments) — how contacts earn and move between the segment labels the editor targets
* [Web SDK reference](/sdks/web) — the `OrbitPersonalization` module surface, `render()`/`track()` semantics, and the public key provisioning flow
* [Sandbox verification](/guides/sandbox-test-mode) — safe end-to-end testing of web SDK payloads before live traffic
* [Personalization API reference](/api-reference/personalization) — full slot CRUD contract for automation and audit
* [Audit log guide](/guides/audit-log) — query and export the trail this page writes