> ## Documentation Index
> Fetch the complete documentation index at: https://docs.userjourneys.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# How launches work

> Understand the supported React Native interview launch paths: tracked app events, synced audience prompts, and HTTPS invite links.

The React Native Interviews SDK supports three launch paths.

```text theme={null}
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.

```text theme={null}
analytics.track("Order Completed")
  -> original analytics call runs
  -> SDK checks cached interview trigger config (loaded at startup)
  -> unrelated event: ignored locally
  -> matching event: SDK creates pendingInvite from local config — no network call
  -> InterviewHost shows the in-app prompt instantly
  -> user accepts
  -> SDK resolves the signed launch decision with UserJourneys (the only network call)
  -> InterviewHost opens the web interview in-app
```

The in-app popup is rendered by `InterviewHost`. It appears
instantly from the trigger config the SDK loaded at startup — a matching event
creates the pending invite locally, with no network round-trip, so the prompt
never lags behind the user's tap. The signed launch is resolved only when the
user accepts the prompt. 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.

```text theme={null}
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
  -> InterviewHost shows the in-app prompt
  -> user accepts
  -> SDK resolves source="audience" with the respondent invite code
  -> InterviewHost 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.

```text theme={null}
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 interview 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](/interviews/targeting-rules) for how to create and
target the rules that connect events and audiences to studies.