Skip to main content

​
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, 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.
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 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.

​
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: 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 for the variant_a/variant_b framing and significance threshold.
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.

​
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: 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 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.