React Native App Analytics for Expo and iOS or Android

A React Native app can look like one product to its customers while behaving like several different systems to its analytics team. The marketing site runs in a browser, the iOS and Android apps run in native containers, and an Expo Web build is a website again. If you measure only downloads and crashes, you miss the journey between opening the app and getting value from it. React Native app analytics should make that journey visible without changing how the product works.

The practical starting point is to record the screen a person reaches, a small set of meaningful actions, and a stable account ID after login. Talivia React Native analytics provides an SDK for that work. It sends app events to the same Talivia collector used by the website tracker, so both surfaces can be inspected in one workspace when configured with the same Website ID and hostname. This guide shows how to set it up, choose events, and interpret the results honestly.

Decide what a successful app journey looks like

Before adding code, write down the path a new customer should complete. For a project app, that might be Welcome → SignUp → Home → first project created. For a marketplace, it might be search, listing view, saved item, and completed request. Name the milestones according to business outcomes, not button labels. A renamed button should not break a year of reporting.

Use three layers of measurement. Screen views show where navigation took the user. Product events show that something important actually happened. Identity links activity to an account your application knows. A screen view of Checkout does not mean a purchase succeeded. A tap on “Create” does not mean an object was saved. The event should fire after the app receives a successful result from its own business flow.

An initial measurement plan can stay small:

Document each event's trigger and properties in a short event dictionary. Decide how retries, repeated taps, and background responses should be handled. That small step makes your reports understandable to product, engineering, and marketing teams alike. For a broader framework across platforms, see the mobile app analytics guide.

Install the React Native SDK for native builds

The published package is @talivia/react-native. Install it in your React Native project. In Expo, install AsyncStorage and the secure UUID adapter as well:

npm install @talivia/react-native
npx expo install @react-native-async-storage/async-storage expo-crypto

The SDK needs a Talivia Website ID, the corresponding website hostname, the app platform, storage, and a secure way to generate visitor and session IDs. Initialize it only when your app's consent and privacy settings allow collection. A minimal Expo setup looks like this:

import AsyncStorage from '@react-native-async-storage/async-storage';
import * as Crypto from 'expo-crypto';
import { Platform } from 'react-native';
import { Talivia } from '@talivia/react-native';

const analytics = new Talivia({
  websiteId: 'YOUR_WEBSITE_UUID',
  host: 'https://talivia.com',
  hostname: 'your-site.com',
  platform: Platform.OS === 'ios' ? 'ios' : 'android',
  storage: AsyncStorage,
  uuid: prefix => `${prefix}_${Crypto.randomUUID()}`,
});

await analytics.init();

Replace the Website ID and hostname with the values for your own Talivia workspace. In bare React Native, supply a storage adapter and a secure UUID generator appropriate to your runtime; a runtime with crypto.randomUUID or crypto.getRandomValues can use the SDK's default generator. The React Native installation documentation has the current setup and code example.

The native SDK is for iOS and Android builds, including those made with Expo. Expo Web uses the browser tracker, because its pages run in a browser. If your project ships both targets, follow the Expo Web installation guide for the web build and use the mobile SDK in the native app. Treating them as separate runtimes prevents accidental gaps or duplicate events.

Connect screen tracking to navigation

The package deliberately does not guess how your navigation works. It cannot know whether a nested route, modal, or tab should count as a new product screen. Call screen() from the navigation change callback for React Navigation or Expo Router, using a stable screen name:

await analytics.screen('Home');
await analytics.screen('Project/Detail');

Choose names that product reviewers will recognize. Avoid putting personal information, dynamic search text, or a raw customer ID in the screen name. A template such as Project/Detail remains useful across many records. The SDK sends native screens as mobile paths in Talivia, with platform context for iOS or Android. These are app screen views, even though they share the collector and dashboard with website pageviews.

Review the navigation callback for duplicate triggers. A router may notify on focus, nested state updates, or a transition that has not yet finished. Record the screen that actually became visible, once per meaningful transition. Then open the session activity view and confirm that a test journey appears in the order a user experienced it.

Record business outcomes with explicit events

Call track() after the action succeeds in your existing app flow. Keep the event name stable and short, and send only the properties needed to answer a specific question:

await analytics.track('signup_completed', { method: 'email' });
await analytics.track('first_project_created', { template: 'blank' });

For signup, wait for the backend to confirm the account. For a project, wait until the record exists. If a network request fails, no success event should be emitted. This is more reliable than recording a button press and hoping the action completed. It also lets teams compare onboarding completion, activation, and repeat use without redefining the business around an analytics SDK.

Keep event properties deliberately narrow. A feature category or plan name can be helpful; access tokens, email addresses, free-form user content, and payment details should not enter general analytics events. Define a naming convention shared with web tracking if the same business milestone exists on both surfaces. The event tracking documentation explains how named events appear beside other Talivia activity.

Identify known users without overstating cross-device reports

After your authentication flow establishes the account, call identify() with a stable internal ID. Use that same ID in web tracking if the account uses both surfaces. On logout, call reset() so the next person using a shared device starts with a new anonymous visitor identity:

await analytics.identify(account.id);
// Later, after logout succeeds:
await analytics.reset();

The SDK stores the visitor, session, and known user state through the supplied storage adapter. It starts a new session after 30 minutes of inactivity. A known ID creates useful links in Talivia's customer identity records, but current funnels still group by visitor token. Signing into a browser and phone with the same account does not merge every pre-login action into one cross-device funnel. Read an app-to-web path as two measured surfaces with a known account connection, not as proof of a single uninterrupted anonymous journey.

This distinction matters when reporting conversion rates. A person who browses on a laptop and completes onboarding on a phone can appear in both source streams. Define whether your report counts visitors, sessions, accounts, or successful actions before comparing web and app numbers. The mobile analytics documentation describes this shared-workspace model and its current limits.

Check offline delivery and acquisition limits

The SDK retries a network failure on the next event or an explicit flush(). Its queue holds at most 100 events in memory. Pending messages disappear if the app process exits; it is not a durable offline store. A server response that permanently rejects an event can also drop that event. Test a short airplane-mode journey, reconnect, call flush(), and check which events arrived before relying on those reports for decisions.

Native acquisition is another separate problem. The SDK does not automatically discover app-store install sources, deep-link campaigns, or ad-network attribution. A website referrer does not magically become an iOS or Android install source. If campaign-to-install measurement matters, add an explicit attribution integration and decide how its evidence enters your reporting. Be clear about the source of every claim in a dashboard.

Client-side events also cannot verify money. A checkout screen or a purchase_completed event from an app may be repeated, spoofed, refunded, or never settled. Record authoritative revenue through a trusted backend or supported payment integration, then use revenue attribution to connect confirmed payments with eligible journey evidence. Product behavior and verified revenue answer different questions, and both should be accurate.

Validate one journey before expanding the plan

Start with a test account. Open the app, navigate to Home, complete one meaningful action, sign in, log out, and reopen after the session timeout. Inspect the event order and platform label. Confirm that screens are not doubled, successful actions are not recorded on failed requests, and the account ID appears only after authentication. Repeat on both iOS and Android if you ship both.

Then test the Expo Web build with the browser tracker separately. Check that it lands in the intended workspace and that pageviews are not sent by the native SDK. If web and native activity do not appear together, verify the Website ID and hostname before adding more events. A small, trustworthy journey is a better launch signal than a long event list with uncertain meanings.

React Native app analytics becomes useful when it follows the business flow you already have: navigation supplies screens, completed actions supply milestones, authentication supplies known identity, and the server supplies payment truth. Begin with the Talivia React Native overview, follow the SDK setup guide, and expand tracking only after the first real journey reads clearly.