Skip to main content
The React Native Interviews SDK supports three launch paths. 
Tracked app event
  -> native prompt
  -> in-app WebView or browser fallback

Synced audience membership
  -> native prompt
  -> in-app WebView or browser fallback

HTTPS invite link
  -> in-app WebView or browser fallback
For event-triggered interviews, the prompt is the handoff before the WebView opens. Customizing the prompt changes that handoff UI, not the launch model.

​
Event-triggered interviews

Event-triggered interviews start from an analytics event your app already sends. An active Study Launch Rule connects the event name to the study that should run. 
analytics.track("Order Completed")
  -> original analytics call runs
  -> SDK checks cached UserJourneys trigger config
  -> unrelated event: ignored locally
  -> matching event: UserJourneys resolves launch decision
  -> SDK creates pendingInvite
  -> UserJourneysInterviewHost shows the in-app prompt
  -> user accepts
  -> UserJourneysInterviewHost opens the web interview in-app
The in-app popup is rendered by UserJourneysInterviewHost. It appears only after an eligible event creates a pending invite. The SDK does not push a user directly from a tracked event into the interview without that prompt. If UserJourneys decides the installed app should not open the interview in-app, accepting the prompt opens the server-provided browser fallback through React Native Linking.openURL.

​
Synced audience prompts

Audience prompts start from synced cohort membership, not from an app event. 
Mixpanel sends cohort members to UserJourneys
  -> UserJourneys stores active audience members
  -> active Study Launch Rule connects the audience to a study
  -> SDK fetches config with referenceId
  -> matching audience member materializes a respondent short code
  -> SDK sets pendingInvite
  -> UserJourneysInterviewHost shows the in-app prompt
  -> user accepts
  -> SDK resolves source="audience" with the respondent invite code
  -> UserJourneysInterviewHost opens the web interview in-app
The public mobile SDK never syncs cohorts and never carries private API keys. Cohort sync runs through UserJourneys integration endpoints and authenticated provider webhooks. The mobile app only sends the same referenceId used by the synced audience member.

​
HTTPS invite links

Invite links are for Intercom, email, push, SMS, and other message channels. 
User taps https://app.userjourneys.ai/i/{inviteCode}
  -> app opens through Universal Links or App Links when installed
  -> SDK resolves the invite code with UserJourneys
  -> supported app: WebView opens in-app
  -> unsupported or missing app: browser interview opens
The link contains routing context. It does not contain conversation tokens, voice agent ids, room ids, or private runtime config. Universal Links/App Links require both sides of the handshake: your app declares app.userjourneys.ai, and UserJourneys authorizes your app identifiers on that domain. Without that domain authorization, the same HTTPS invite link still works as the browser fallback.

​
What UserJourneys controls

After the app integrates the SDK, UserJourneys controls:
  • which tracked events are active interview triggers;
  • which Study Launch Rules connect events or audiences to studies;
  • which synced audience members have pending prompts;
  • eligibility and targeting for a launch;
  • which interview runs for a trigger or invite;
  • whether the app receives an in-app WebView launch or browser fallback.
The app controls:
  • where the wrapped analytics client is exported;
  • how referenceId is derived;
  • which primitive event properties are mapped into UserJourneys metadata;
  • whether the default prompt or a custom pending-invite prompt is rendered;
  • app-side Universal Links/App Links setup for HTTPS invite links.
See Study Launch Rules for how to create and target the rules that connect events and audiences to studies.