Creating surveys

The survey builder lives at admin.insito.app → your project → Surveys → New survey. This page walks through each step.

​

The builder

A survey has six tabs:

1. Questions — at least one answerable question; up to 20 items total (including optional welcome and end screens).
2. Logic — branching rules between questions.
3. Trigger — trigger conditions (event keys, screen visits, app open), throttling, and when to show the modal.
4. Audience — device and user-property filters.
5. Schedule — start/end dates, timezone, and response caps.
6. Responses — the survey’s collected responses (table with CSV export).

While editing, changes autosave to a draft (debounced, on tab switch, and when you leave a field). Live respondents keep seeing the last published version until you explicitly publish.

​

1. Naming and status

Open Survey settings (gear icon) for description and behavior toggles like branding, question numbers, back navigation, and autosave.

​

2. Throttling

On the Trigger tab, set Minimum days between shows (throttle_days, default 7, range 0–365). Set it to 0 to disable throttling for the survey.

​

3. Questions

Add at least one answerable question. A survey holds up to 20 questions total, including optional welcome and end screens. Respondents see them one at a time inside the modal. When Allow back button is enabled in survey settings, respondents can revisit earlier questions; optional questions still show Skip.

​

Question types

​

Common patterns

Pure NPS (one question, two if you want a follow-up):

1. NPS: “How likely are you to recommend us to a friend?”
2. Open text: “What’s the main reason for your score?”

Feature satisfaction (three questions):

1. Rating: “How satisfied are you with this feature?”
2. Multiple choice: “What did you like most?” — ["Speed", "Reliability", "Design", "Other"]
3. Open text (optional): “Anything else we should know?”

Onboarding effort (one question):

1. Rating: “How easy was it to set up the app?” — labels Very hard–Very easy.

​

Required vs optional

Toggle Required on each question. Required questions block the “Next” button until answered; optional questions show a “Skip” affordance. Open-text questions ignore the required flag if the user submitted at least one character of whitespace, so be explicit in your question copy.

​

4. Audience (optional)

Filter who sees the survey with device and user-property conditions, e.g.:

• Platform — react_native, ios, android, or flutter.
• App version — exact match or range. Useful for cohort studies (only ask users on the new build).
• User properties — any custom attribute you send via identify({ properties }).

You choose whether the conditions combine with AND or OR. If the user’s identify() payload doesn’t include a field a filter requires, they don’t see the survey.

​

Draft, publish, and activate

​

Editing live surveys

Editing an active or paused survey is safe — you can iterate in draft without affecting live respondents until you publish. There are two caveats:

• Changing the trigger key rewrites history. Existing responses stay attached to the new key, which can be confusing if you’re comparing across rollouts. Prefer creating a new survey under a new key (e.g. checkout_completed_v2).
• Removing or renaming questions changes the published set. Existing responses keep the answers they recorded, but a removed question won’t appear in the analytics roll-up. Add a new question instead of editing an old one’s text if you want clean before/after analytics.

In-progress SDK sessions keep the previous live version until dismissed; the next trigger loads the newly published content.

​

Next