Skip to main content
Roll out in-app interviews in stages instead of enabling a rule for everyone at once. Each stage limits who can be prompted, so you catch integration problems on your own devices before real users ever see a prompt.

​
1. Test in a dev build

Validate the SDK end-to-end in a development build on both platforms before any release build carries a live rule.
  • Install the SDK and run the app once so it contacts the project’s SDK API. The SDK not connected yet warning on the Targeting tab disappears once sdk_connected flips, which confirms the app reached UserJourneys.
  • Walk the full Test your integration checklist on iOS and Android: event wrapping, WebView rendering, microphone permission, browser fallback, and attribution.
  • Use a fresh throwaway referenceId per run so limits, cooldowns, and dismissals do not block re-testing.

​
2. Ship an internal-only rule in the release build

Put a live rule in front of only your team first.
  • Sync a small internal cohort (your team’s referenceIds) and create an audience Study Launch Rule targeting just that cohort, or use an app-event rule whose event you can trigger on demand.
  • Set the study to Active and the rule to Active. Keep the audience internal-only at this stage.

​
3. Verify on team phones

Install the release build on team devices and confirm real prompts appear.
  • Confirm the prompt shows for internal users and opens the interview in-app.
  • Confirm unrelated events do not prompt, and dismissing clears the prompt.
  • If nothing prompts, work through Why isn’t anyone getting prompted? — most often the study is not activated, the event name does not match exactly, or the SDK is not connected.

​
4. Widen the audience

Once internal verification passes, widen the rule’s audience (or enable the app-event rule for everyone) and watch the first sessions land before expanding further. Tune priority, cooldown, and max starts per person as you scale.