Skip to main content
Triggers are configured per survey, in the survey builder’s Trigger tab (not in a separate project-wide screen). Open a survey from admin.insito.app → your project → Surveys, then switch to the Trigger tab.

​
Trigger conditions

The Trigger tab lets you enable one or more condition cards, combined with OR logic (the survey fires when any enabled condition qualifies):
  • App event — one or more event keys your app fires with MicroSurvey.trigger("checkout_completed").
  • Screen visit — one or more screens, optionally with an “after N visits” threshold.
  • App open — after a minimum number of app starts (cold launches by default; can include foreground resumes).
  • Set delay — wait N seconds after a condition qualifies before showing.
The event-key and screen-name fields are searchable selects backed by the Events and Screens registry. Only approved variables appear in the picker; you can also type a new key, which registers as a manual variable.

​
Frequency and throttling

Below the conditions, the Trigger tab controls how often the survey can appear:
  • Minimum days between shows (throttle_days, default 7) — the project-wide throttle window. See throttling.
  • Max shows per user — a hard cap on how many times this survey is ever shown to one user, counted from the impressions table.

​
Confirming a trigger is wired

After shipping a version that fires a new key, watch for it to appear in the Auto-discovered list under Settings → [your app] → Events (or Screens). If nothing shows up after some production traffic, check:
  • The key in the dashboard matches the string in your app exactly (keys are case-sensitive; there’s no server-side normalisation).
  • MicroSurvey.identify() ran before the trigger.
  • The SDK is initialised (turn on debug: true in development).
A survey only shows if throttling passes, a condition matches, the survey’s response limit isn’t reached, audience filters pass, and the per-user show cap isn’t hit — evaluated in that order. See Triggers (concepts) for the full evaluation flow.

​
Targeting by audience

A trigger decides when a survey is evaluated; the Audience tab decides who qualifies. Audience filters run against two kinds of properties:
  • Device properties — auto-captured by the SDK on every identify() (platform, app_version, locale, timezone, osVersion, sessionCount, daysSinceInstall, environment). No setup required.
  • User properties — custom, business-level attributes you send via identify({ properties }), discovered into the User Properties registry.
The property picker groups these two sources, and the available operators adapt to each property’s type (text, number, or boolean). For example: only show an upsell when plan equals "free" and daysSinceInstall ≥ 7.

​
Screen triggers

If you use screen tracking, the SDK reports visited screens (and fires screen_viewed:<pathname>). Reported screens show up under Settings → [your app] → Screens and in the project’s Screen map view, where you approve the ones you want to use as Screen visit trigger conditions.