> ## 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.

# Test your integration

> Confirm analytics-triggered launches, invite links, WebView rendering, fallback, and attribution before releasing your app.

Use this checklist before releasing an app version with UserJourneys React
Native SDK.

<Warning>
  Opening a browser interview link is not enough. A React Native SDK validation
  should run inside your app so event wrapping, Universal Links/App Links,
  WebView rendering, microphone permissions, fallback behavior, and attribution
  are tested together.
</Warning>

## Before you start

Prepare a build and a test user that can safely create interview sessions:

* An iOS or Android app build that includes the SDK and `react-native-webview`.
* A non-production interview study with an active Study Launch Rule for the
  test event.
* If you use cohort prompts, one active Study Launch Rule for a non-production
  synced audience.
* A known user id that matches the id your analytics tool uses for the same person.
* One analytics event that should launch an interview.
* One synced audience member for the same known user id, if you use cohort
  prompts.
* One Interview HTTPS invite link.
* Universal Links/App Links authorized on `app.userjourneys.ai` for the app
  build you are testing.

## App build

Confirm the app can load the in-app WebView host:

* The app installs and opens on a simulator, emulator, or physical device.
* `InterviewHost` is mounted once near the app root.
* Expo apps are validated in a development build, EAS build, or prebuild output.
* Android builds include WebView microphone permissions.
* iOS builds can request microphone permission from the WebView interview.

## Analytics launch

Run the same product action a real user would take.

<Steps>
  <Step title="Trigger the product event">
    Complete the app action that sends the configured analytics event.
  </Step>

  <Step title="Confirm normal analytics still works">
    Verify your existing analytics dashboard still receives the event.
  </Step>

  <Step title="Confirm UserJourneys opens only when expected">
    The configured event should show the native interview prompt. Nearby unrelated
    events should keep tracking normally without showing a prompt or opening an
    interview.
  </Step>

  <Step title="Accept and dismiss the prompt">
    Accepting the prompt should open the in-app WebView. Dismissing the prompt
    should clear it without opening an interview.
  </Step>

  <Step title="Confirm fallback">
    If UserJourneys returns an external browser decision for the app version or
    device, accepting the prompt should open the fallback URL with React Native
    `Linking.openURL` instead of leaving the user stuck.
  </Step>
</Steps>

The app should not need changes at every existing `track` call. The SDK is
installed once around your central analytics client and UserJourneys controls
which events are active for interviews.

<Tip>
  Launch limits, cooldowns, and dismissals are keyed off the `referenceId`, so a
  test user that already hit a limit or cooldown will not prompt again. To re-run a
  rule cleanly, use a fresh throwaway `referenceId` for each test run — for example
  `dev-test-1`, then `dev-test-2` — so the new id has no start history, cooldown, or
  dismissal. Switch back to your real `referenceId` before releasing.
</Tip>

## Invite links

Validate the link path separately from analytics events.

<Steps>
  <Step title="Open the HTTPS invite link with the app installed">
    The link should open your app through Universal Links or App Links and present
    the in-app WebView when the app version is supported.
  </Step>

  <Step title="Confirm domain authorization">
    If the link opens only in the browser with the app installed, confirm
    UserJourneys has your Apple Team ID, iOS bundle ID, Android application ID,
    and Android SHA-256 signing certificate fingerprint.
  </Step>

  <Step title="Open the same link without app handling">
    The same HTTPS link should still open the web interview in a browser when the
    app is not installed or the app cannot handle the link.
  </Step>

  <Step title="Open a non-interview link">
    Your app should ignore unrelated links and keep its normal link behavior.
  </Step>
</Steps>

## Synced audience prompts

Validate the cohort path separately from analytics events.

<Steps>
  <Step title="Sync a test respondent">
    Sync the test user's `referenceId` or provider member id into a
    non-production Mixpanel cohort connected to UserJourneys.
  </Step>

  <Step title="Open the app as that user">
    The SDK config request should include the same `referenceId` and receive a
    `pending_prompts` entry from UserJourneys.
  </Step>

  <Step title="Accept the native prompt">
    Accepting the prompt should resolve `source: "audience"` with the respondent
    short code, Study Launch Rule id, and audience id, then open the in-app
    WebView or the server-selected fallback.
  </Step>

  <Step title="Confirm no private key is in the app">
    The mobile app should only use the public SDK key. Cohort sync must use a
    private project API key or authenticated provider webhook outside the app.
  </Step>
</Steps>

## Interview experience

Walk through the visible interview states:

* Loading state while the WebView loads the signed launch URL.
* Welcome screen.
* Environment and microphone setup.
* Active voice interview.
* Completed state.
* Leave or abandon flow.
* Microphone-denied state.
* Limit or unavailable state, if your test interview is configured for it.

The in-app interview should match the browser participant
experience because both surfaces render the same web embed. Use screenshot
comparison against the browser embed for release checks when visual drift is a
risk.

## Attribution

After the test session, confirm the session is attached to the right user and
launch source in UserJourneys.

You should be able to identify:

* The app user or analytics person id.
* Whether the session came from an analytics event or invite link.
* The event name, Study Launch Rule, audience, or invite that started the
  session.
* The study that ran.
* The session outcome: started, completed, abandoned, screened out, unavailable, or fallback.

## Failure cases

Test the cases users are likely to hit:

* Offline or poor network.
* WebView load failure.
* Microphone permission denied.
* User grants microphone permission after initially denying it.
* User dismisses the native prompt.
* Unsupported app version or device runtime.
* Interview unavailable or limit reached.
* User leaves before completing the interview.

The app should not crash in these cases. It should either show the appropriate
interview state, return the user to the app, or open the fallback interview
URL.

## Compatibility

| Surface              | Minimum                                          | Notes                                                                             |
| -------------------- | ------------------------------------------------ | --------------------------------------------------------------------------------- |
| React Native         | `0.70`                                           | SDK peer range.                                                                   |
| React                | `18.1`                                           | Match your React Native version's React peer range.                               |
| React Native WebView | `13.16`                                          | In-app interview host.                                                            |
| Expo                 | Development build                                | Validate the release-like build users receive.                                    |
| iOS                  | App build with WebView and microphone permission | Use the deployment target compatible with your app.                               |
| Android              | App build with WebView microphone permissions    | Include `RECORD_AUDIO` and `MODIFY_AUDIO_SETTINGS` through the native app config. |

## Package verification

Before shipping a new SDK version, UserJourneys validates the package with:

* TypeScript build and typecheck for the private core and React Native package.
* Unit tests for trigger config, launch decisions, invite links, fallback, and
  WebView bridge handling.
* Consumer compile against the packed public package.
* Package verification that the published tarball does not depend on the private
  separate core package.

## Ready to release

Treat the integration as ready when:

* The configured analytics event shows the native prompt before opening.
* Accepting the prompt opens the in-app WebView or browser fallback.
* Dismissing the prompt does not open an interview.
* Unrelated analytics events do not open interviews.
* Synced audience membership shows the native prompt for the matching
  `referenceId`.
* HTTPS invite links open in-app when supported and web when unsupported.
* Microphone permission, leave, completion, and fallback states behave correctly.
* UserJourneys records the correct user identity, launch source, and outcome.