Surveys & owned attributes

Collect a couple of facts at signup, store them as onboarding.* attributes, and route each new user into the right onboarding.

Sometimes the right onboarding depends on something you don't know yet — what the user is here to do, how big their team is, which role they hold. A survey is a short questionnaire shown right after signup that collects exactly those facts, stores them as owned attributes, and lets your segments route the user into the right experience — all without your app touching a database.

How it works

  1. A new user signs in. If an onboarding survey is active for the environment and they haven't answered it yet, it's shown first — it pre-empts every other experience until answered.
  2. They answer. Each answer is written to user.onboarding.<key> — a question keyed useCase becomes user.onboarding.useCase.
  3. The session re-bootstraps immediately: Sunboard re-evaluates segments with the new attributes, and the matching experience renders in the same session — no reload, no navigation.
sign up → survey → onboarding.useCase = "marketing" → marketing checklist

Owned attributes

The onboarding.* namespace is owned by Sunboard, not your app:

  • You never pass them on the user object — the survey populates them, and they survive every later bootstrap that sends your own properties.
  • Segments match on them like any other property — { "property": "onboarding.useCase", "equals": "marketing" }, plus in and contains for multi-select answers.
  • Copy personalizes on them with {{user.onboarding.useCase}} tokens, so the experience the survey routes into can speak back to the answer.

Self-reported, not trusted

Survey answers are great for routing and personalization, but they're self-reported — never gate entitlement, billing, or access on them. Trusted facts come from your own user properties.

One survey per environment

A survey isn't bound to a segment like an experience is. There's one optional onboarding survey per environment, activated with sunboard survey set. Gating is implicit: it shows whenever it's active and the user has no response yet. You never write a "show the survey" rule.

Setting one up

Ask your agent for Onboarding — it decides whether a survey earns its place (you don't need one if the routing signal is already on your user object) and authors it alongside the segments it feeds. To author one directly, use the Survey skill; to style it, see Survey UI.

On this page