Skip to main content

Documentation Index

Fetch the complete documentation index at: https://docs.insito.app/llms.txt

Use this file to discover all available pages before exploring further.

A trigger is a short event name your app fires (MicroSurvey.trigger("checkout_completed")) and an Insito admin attaches to a survey in the dashboard. Splitting them like this means non-engineers can change what gets asked without shipping a new app build.

​
Anatomy of a trigger

Three things have to be true for the modal to appear:
  1. A survey exists with triggerKey: "checkout_completed" and status: "active" in your project.
  2. The current user passes throttling (28 days default, configurable).
  3. The user has been identified in the current session (MicroSurvey.identify was called).
If any of the three are false, the API returns survey: null and the SDK silently returns to idle. No errors thrown, nothing flashes on screen — the user is none the wiser.

​
Naming conventions

Trigger keys are free-form strings, but conventions help when several people are wiring surveys in the dashboard.
  • lowercase_snake_case — Insito normalises to this anyway.
  • Verb_in_past_tense for completed actions: signup_completed, checkout_completed, subscription_renewed.
  • Noun for visits: home_screen, settings_screen.
  • Suffix with _v2, _v3 if you change semantics, so old SDK versions on user phones don’t accidentally hit the new survey.

​
Where to fire triggers

The “right” place to call MicroSurvey.trigger() depends on what you want to measure:

Post-conversion

The checkout success screen, payment confirmation, “thanks for upgrading” page. High-signal moments — NPS lands close to the actual experience.

Post-onboarding

After the welcome flow finishes. “How easy was that?” with a 1–5 rating. Spot drop-off causes before they churn.

Feature first-use

When the user finishes their first action with a new feature. Pair with screen tracking so you can target by path.

Manual feedback

A “Send feedback” button in your settings screen. Fire MicroSurvey.trigger("manual_feedback") from onPress.

​
What NOT to do

Do not fire triggers on every render. useEffect with an empty dependency array — or a dedicated user action — is the right pattern. The SDK guards against in-flight triggers, but you’ll burn impressions for nothing if the call fires 10 times per screen.
// Bad — fires on every re-render
<Text>{MicroSurvey.trigger("home_screen")}</Text>

// Good — fires once on mount
useEffect(() => {
  void MicroSurvey.trigger("home_screen");
}, []);

// Also good — fires on user action
<Button onPress={() => MicroSurvey.trigger("manual_feedback")} />

​
Server-side evaluation

Triggers evaluate server-side. Implication: you can pause a survey mid-rollout (toggle it to inactive), change its questions, or move it to a different trigger key, and users on the old app build will see the change instantly. No re-release needed. This also means deleted surveys are inert. The SDK fires the trigger, the server doesn’t find a match, the SDK returns to idle. No errors, no warnings, no console.log noise.

​
Limits

  • Trigger keys can be up to 64 characters, must match ^[a-z][a-z0-9_]*$.
  • Each project can have one active survey per trigger key. If you want A/B, use a single survey with multiple-choice questions containing the variants.
  • Throttling is per-(trigger, userId). Different triggers fire independently.

​
Next

Throttling rules

How the 28-day window works and how to override it.

Creating a survey

Walk through the dashboard survey builder.