Survey

/sunboard.survey authors the short questionnaire shown right after signup. Each answer becomes an owned attribute under user.onboarding.* — which your segments route on and your copy personalizes with {{user.onboarding.*}}. The survey is the instrument that collects what your product doesn't already know; the rest of onboarding routes off those answers.

It's usually run as a step of Onboarding, which decides whether a survey is needed and which answers route which cohort.

When to use it

• New users need different onboarding, and what distinguishes them isn't already on the user object you pass the SDK.
• You want to personalize the first experience on something the user tells you.

What happens

1. Inspects your product and hosted state — and whether an onboarding survey is already active for the environment (sunboard survey show).
2. Confirms a survey earns its place — if the routing signal is already a host property (plan, role), it says so and recommends segmenting on that instead. A survey is for what the product can't already tell you.
3. Designs 2–4 questions that route — each one mapping to a real cohort decision. Questions that wouldn't change what the user sees next are cut.
4. Writes the type: survey spec to sunboard/specs/<key>.yaml, with personalized copy and an exampleUser.onboarding block so sunboard validate can catch token typos.
5. Validates, deploys, and activates — sunboard survey set makes it the environment's onboarding survey. There's no "show the survey" segment to create; gating is implicit (active survey + no response yet).
6. Hands downstream routing to Segment — proposing segments over the collected onboarding.* attributes.

Question types

Option values (not labels) are stored, so you can reword copy without breaking segments.

Related