React Native Analytics: A Practical Implementation Guide

If you're reading this, you probably want to know what users actually do in your React Native app. Which screens do they reach, which buttons do they tap, and where do they give up? There's an even higher chance you've noticed that analytics built for native apps sees very little of it.

The good news: This guide explains what makes analytics different in React Native and what's worth tracking. It shows how to plan your events before you write code. Then it walks through screen tracking, events, user identity and error capture with UXCam, using libraries you already know, such as React Navigation and Expo Router. UXCam's React Native SDK covers your iOS and Android apps, and its web SDK covers your website in the same account. One tracking plan can serve mobile and the web.

Why analytics works differently in React Native

React Native renders real native views, so it's tempting to expect native analytics tools to pick everything up. They don't. The parts that matter most for analytics are decided in JavaScript: which screen is showing, why it changed, and what the user meant by a tap. That changes where your tracking code lives and which signals you can trust.

Your screens are JavaScript components

In a native iOS or Android app, each screen is usually its own view controller or activity, and analytics SDKs log screen views by listening to that lifecycle. In React Native, a navigation library decides which component tree to show. So the native events that automatic tracking relies on either don't fire per screen or carry generic container names.

That's why UXCam's own screen tagging guide calls automatic tagging "not reliable" in React Native. It recommends tagging screens from JavaScript instead.

Navigation is a library choice, not a platform feature

Most apps use React Navigation, a growing number use Expo Router, and some large codebases run Wix's React Native Navigation. Each one reports screen changes in its own way: focus effects and a state-change callback in React Navigation, route segments in Expo Router, appear events in Wix. Your screen tracking has to hook into the one you use. Make that decision before the first screen ships.

Renders are not user actions

React components re-render whenever state or props change, which can happen dozens of times while someone looks at one screen. If you log an event in a render body, or in an effect that re-runs on every change, each render becomes a fake user action.

Development builds add a twist. React's StrictMode runs effects twice on mount on purpose, so a naive "log on mount" effect double-counts in development. Production builds don't, but logging only from event handlers and focus callbacks keeps both environments honest.

One codebase still runs on two platforms

Shared JavaScript doesn't mean shared behavior. Android users go back with the system back gesture or button, while iOS users swipe from the edge. Keyboards cover different parts of a form, and permission prompts look different. A component picked with Platform.OS can split a flow without anyone noticing. Plan to segment every key metric by platform from day one.

Expo Go is not your production app

Analytics SDKs with native modules can't run inside Expo Go, and UXCam is one of them. Expo Go is the sandbox app many teams use while prototyping. To test tracking, you need a development build or EAS Build. Also check that every analytics library you add supports the New Architecture, now the default for new projects. UXCam's React Native SDK has supported it since version 6.0.0.

What to track in a React Native app

Track behavior that explains how people experience your app, because counting everything that moves only adds noise. These categories cover most React Native apps.

Screen views

Screen views are the backbone of every other analysis. Funnels, journeys, heatmaps and time on screen all depend on knowing which screen a user was on. Use human-readable names such as Product Details or Checkout Payment, and tag tabs and modals as their own screens. Keep IDs out of the names. "Product Details - Electronics" is a useful screen; "Product Details - 12345" creates thousands of screens nobody can analyze.

Component interactions with context

A bare "button_pressed" event tells you almost nothing, so log the action with its context instead. Good examples are product_added_to_cart with the product ID and price, filter_applied with the filters chosen, or share_tapped with the content type. Log from the component's onPress handler, so one tap produces one event no matter how often the component renders.

Forms and inputs

Forms are where React Native apps lose people quietly. Track when a form starts, which fields trigger validation errors, which steps users skip and whether the submit succeeds. Never log what users type: the field name and the error type are enough to find the problem.

Gestures and lists

Lists, swipeable cards, pull-to-refresh and long presses are core interactions in many React Native apps. They're also easy to miss in an event plan. Pick the ones that signal intent, such as swiping a card away or pulling to refresh an empty feed, and log those. Tools with autocapture, UXCam among them, record taps, swipes and scrolls on every screen without extra code. That leaves your hand-written events for the moments with business meaning.

Onboarding and permissions

Map each onboarding step as a screen or an event. Log the outcome of every permission request, such as notifications, location, camera and tracking. A permission denied in step two often explains a feature that looks unused months later.

Funnel-critical actions

Instrument each step of the flows that pay the bills. That might be product list, product detail, cart, checkout and order confirmed, or signup, first project and first share. If a step can fail, log the failure with a reason, such as payment_failed with the error code, so your funnel shows where users drop off and why.

JavaScript errors

The React Native runtime handles uncaught JavaScript exceptions, not the native crash handlers most SDKs install, so these errors often go missing from crash reports. Log them as events instead, as shown below, and they sit on the same timeline as everything else the user did.

Plan your tracking before you write code

A tracking plan keeps your analytics useful as the app grows. Without one, screens get tracked one by one and you end up with five names for the same event. A short planning pass saves months of cleanup.

Start with the three to five journeys that matter most, such as onboarding to activation, browse to purchase or invite to first collaboration, and instrument those paths first.

Then agree on naming: a simple object_action pattern in snake_case, such as checkout_started or payment_failed, works well across platforms and query tools. UXCam treats event names and property keys as case sensitive, so Purchase and purchase show up as two events. Keep dynamic values out of event names and put them in properties.

Make platform a dimension from the start. Most analytics tools, UXCam included, record device, OS and app version with every session. That means you can compare iOS and Android without logging the platform yourself. Do decide early which flows differ by platform, so you know what to compare.

Treat personal data as off limits. Identify users by your internal user ID, not an email address or phone number. Keep names, emails and free-text input out of events and user properties. UXCam requires a data processing agreement before you send personal data, and the safer default is not to send it at all.

Finally, write the plan down. List every event, its properties, where it fires and who owns it. A shared plan keeps new screens consistent and shows you when an event stops firing after a refactor. Keep event names in a constants module, too, so TypeScript autocompletes them and catches typos at compile time.

How to implement analytics in React Native

The steps below use UXCam's API names, since that's the tool this guide covers, but the structure works with any provider. Initialize once, track screens from your navigation library and log events from handlers. Then identify users and test on both platforms.

1. Choose an analytics provider

Several analytics tools have solid React Native SDKs. Firebase Analytics is free and fits teams already in Google's ecosystem. Most apps add it through React Native Firebase, and our React Native Firebase Analytics guide covers the setup. Mixpanel and Amplitude focus on event analytics, segmentation and cohorts, and both depend on the events you instrument.

UXCam starts from a different place. Its React Native SDK records sessions and captures taps, swipes, scrolls and screens automatically, and the events you log add detail on top.

So you get session replay, heatmaps, funnels, journeys and crash context from one integration, and you can answer questions you never planned events for. Some teams run UXCam alongside an event-only tool, while others use it as their main product analytics platform.

2. Install the SDK and initialize it once

UXCam's React Native SDK is the react-native-ux-cam package. It needs React Native 0.68 or later, or Expo SDK 47 or later. Your app also needs an iOS deployment target of 12.0 and an Android minSdkVersion of 21 or higher. Install it with npm install react-native-ux-cam or yarn add react-native-ux-cam, then run pod install in your ios folder. On Expo, add the package and create a development build with EAS, as UXCam's Expo installation guide describes.

Start UXCam once, in a useEffect in your root App component. That way recording starts with the app, not with one particular screen. First turn on screen recording with RNUxcam.optIntoVideoRecording(), which both iOS and Android need. Then call RNUxcam.startWithConfiguration() with a configuration object.

The configuration object needs three settings. Set userAppKey to the app key from your UXCam dashboard. Set enableAutomaticScreenNameTagging to false, because you'll tag screens yourself in the next step. And set enableImprovedScreenCapture to true, as the docs recommend.

Use separate app keys for development and production, and load them from environment variables instead of committing them to the repository. That keeps test sessions out of your production data from day one. The React Native integration guide lists every configuration option.

3. Track screens from your navigation library

With React Navigation, the simplest pattern is a focus effect in each screen. Inside a useFocusEffect callback wrapped in useCallback, call RNUxcam.tagScreenName() with the screen's name. Focus effects run whenever a screen comes into view, including when a user comes back to it. A plain mount effect would miss those returns. Many teams wrap this in a small useScreenTracking hook, so every screen tags itself in one line.

You can also keep all screen tracking in one place. Use the onStateChange callback of your NavigationContainer and read the current route name from a navigation ref with getCurrentRoute(). Compare it with the last name you tagged, and tag only when it changes. That check matters, because onStateChange also fires for changes that don't change the visible screen.

Tabs and modals need their own tags. Tag each tab screen separately, for example Home Tab and Search Tab, so your analytics don't fold every tab into one screen. Tag modals when they become visible.

Other navigators follow the same idea with different hooks. On Expo Router, tag from your root layout with the useSegments hook and skip route groups in parentheses. On Wix's navigation, use componentDidAppear or a componentDidAppear listener. The React Navigation and Wix guide has examples for each pattern, including how to debounce tab switches less than 300 milliseconds apart.

4. Log events from handlers, not from renders

Log events with RNUxcam.logEvent(), passing the event name and an optional object of properties, such as product_added_to_cart with product_id, category and price. Call it from onPress handlers, form submit callbacks and other places where the user acts. Each event can carry up to 20 properties, with string, number or boolean values of up to 512 characters each, as the events guide explains.

You don't need to log rage taps or UI freezes. UXCam detects both and adds them to the session as events, so you can filter for frustrated users without writing any code.

5. Identify users and describe sessions

By default, UXCam gives each user a random alias based on the install. Replace it as soon as someone logs in by passing your internal user ID to RNUxcam.setUserIdentity(). All of that person's sessions, on every device, then link to one identity your support and product teams can look up.

Add attributes such as plan, role or acquisition source with RNUxcam.setUserProperty(). You can define up to 100 user property keys per app, so plan them like events. The user properties guide has the details.

Some context belongs to a single session, not to a user. The A/B test variant someone saw, the build flavor and a flag for internal QA sessions all belong in RNUxcam.setSessionProperty(). Here's a simple rule of thumb: events describe what the user did, user properties describe who they are, and session properties describe this visit.

6. Capture JavaScript errors as events

UXCam captures native iOS and Android crashes automatically, along with ANRs and UI freezes, and links each one to the session replay. JavaScript exceptions are different. The React Native runtime handles them, so they never reach native crash handlers, and the React Native SDK has no dedicated call for reporting them.

UXCam's crash and ANR guide gives a workaround: wrap React Native's global error handler. Read the existing handler with ErrorUtils.getGlobalHandler(), then set a new one with ErrorUtils.setGlobalHandler(). The new handler logs a js_error event with the error name, a trimmed message and whether it was fatal, and then calls the previous handler.

The same logEvent call works in an error boundary's componentDidCatch and in catch blocks around network requests. Filter sessions by js_error, and you'll see what users did before each error.

7. Test on iOS and Android before you ship

Turn on integration logging in development builds; setting enableIntegrationLogging to __DEV__ does this automatically. Then watch the native logs: Xcode's console on iOS and Logcat in Android Studio on Android. They won't show up in Metro, VS Code or Cursor.

Look for "Verification successful" when the SDK starts. After you send the app to the background, which ends the session and starts the upload, look for "Session uploaded".

Next, open the session in your dashboard. Every screen should appear once with a duration above zero seconds; a screen with 0s usually means it was tagged twice in the same frame. Check that your events carry the properties you expect.

Finally, walk through the platform-specific paths. The Android back button and the iOS swipe-back gesture should log the same navigation.

Protect user privacy while you track

Session-based analytics records what's on screen, so privacy belongs in the implementation from the start. UXCam masks password fields that use secureTextEntry and standard credit card inputs automatically. Everything else appears in replays until you mask it. Masking happens on the device, so hidden content never reaches UXCam's servers.

The fastest option needs no code. In the UXCam dashboard, under Settings and Video Recording Privacy, you can record, occlude or blur all screens or chosen ones.

In code, you have three tools. Add overlay or blur rules for named screens to the occlusions list in your configuration. Hide a single component by passing its ref to RNUxcam.occludeSensitiveView(), or wrap a sensitive part of the layout in the UXCamOccludedView component.

WebViews need extra care. For a WebView that shows payment or health data, occlude the whole WebView rather than elements inside it. The occlusion guide explains each option and the order in which rules apply.

Consent works the same way on both platforms. UXCam records by default. If your app asks users first, call RNUxcam.optOutOverall() for people who decline and optInOverall() for those who agree. Store the choice yourself, because it resets when the app is reinstalled. The opt-in and opt-out guide shows a complete consent flow.

How UXCam turns React Native data into answers

Implementation is half the job; the other half is noticing what the data says. UXCam is a product intelligence and analytics platform for mobile apps and the web. It's built to bring the important findings to you, instead of waiting for the right query.

It starts with autocapture: the SDK records every tap, swipe and screen, so Tara, UXCam's AI analyst, can look across all of your sessions. Tara surfaces what changed before anyone thinks to ask. That might be a checkout step that started leaking after a release, or a screen where rage taps are climbing.

Questions you didn't plan for are covered, too. With smart events, you define a new event from interactions UXCam has already captured and apply it to past data. There's no new tracking code to ship and no wait while data comes in.

From there, the rest of the platform helps you see and measure:

• Screen tracking that matches your navigation: The names from your useFocusEffect or onStateChange tagging split every session into screens. You see time on each screen and the path between them.

• Session replay: Watch what users saw and did. Taps, swipes, events and errors are marked on the timeline, so you can confirm what the numbers suggest.

• Heatmaps: See where users tap on each tagged screen, and where they tap again and again without a response.

• Funnels and user journeys: Find the step where users drop off and the routes they take instead. Then jump straight to the sessions behind each drop-off.

• Retention: Compare how cohorts come back over time. Split them by platform, app version or any user property you send.

• Issue analytics: Track native crashes, ANRs and UI freezes by app version and device. Each one links to the replay that shows what led up to it.

If your team also works in AI assistants, UXCam's MCP server brings the same data into tools like Claude. You can then ask questions about your React Native app in plain language.

Example: How Inspire Fitness used UXCam in its React Native app

Inspire Fitness offers live and on-demand workout classes through its mobile app. As demand grew, the product team could see top-line numbers such as daily and monthly active users. What they couldn't answer were the questions that shaped the roadmap. Which content should they publish next, and which instructors kept people training?

The team set up its events in two hours with UXCam's React Native SDK. Session recordings showed how members onboarded, started workouts and moved around the app. Event analytics became the place to measure the most active customers, the top workouts and the instructors leading the most popular classes. Issue analytics sent real-time alerts for crashes and freezes, with the affected sessions attached. The team also began answering negative app store reviews by filtering sessions by device and app version.

According to the case study, new user sign-ups rose 181%, app sessions grew 415% and time spent in the app went up 460%. Total app crashes fell 40%, and rage taps dropped 56%. Setting up events is now part of every feature release.

We wanted to make data-driven decisions on what content to push out next and evaluate how our instructors are doing. With UXCam, we get a holistic picture of the top performing content within the app and the instructors that drive the highest user engagement.

- Neil Jain, Product Manager, Inspire Fitness

Common React Native analytics pitfalls

Most broken React Native analytics comes from a handful of mistakes. Nearly all of them are habits that work fine in web or native apps.

• Logging in render or in effects that re-run: These events fire on every re-render and double in development under StrictMode. Log from handlers and focus callbacks instead.

• Relying on automatic screen tagging: Native auto-tracking can't see screens that a JavaScript navigator switches, so you get missing or generic names. Turn it off and tag screens from your navigation library.

• Tagging the same screen twice: Tagging in both a focus effect and a global onStateChange handler produces screens with 0s duration, and so does tagging on every render. Pick one approach and debounce rapid tab switches.

• Putting IDs in names: Dynamic values in screen or event names split your data into thousands of rows, so put IDs in properties instead.

• Testing in Expo Go or reading the wrong logs: Native analytics SDKs don't load in Expo Go, and their logs only appear in Xcode and Logcat. Test in a development build and check the native logs.

• Sending personal data: Emails, phone numbers and free-text input don't belong in events or user properties. Use internal IDs and mask sensitive views.

• Running two crash reporters: Two SDKs that both install native crash handlers, such as Firebase Crashlytics and UXCam, can conflict. Decide at app start which one owns crashes, and turn crash handling off in the other.

Get clearer React Native analytics with UXCam

React Native gives you one codebase for two platforms, but it also moves the signals analytics depends on into JavaScript. Screens live in your navigation library, renders aren't actions, and errors don't always reach native crash handlers. Track screens from your navigator, log events from handlers and capture errors as events, and you'll have data you can trust on both iOS and Android.

UXCam adds the context events alone can't give you. Autocapture records every session, Tara points you to what changed, and replays, heatmaps and funnels show you why, with no wait for the next release.

To get that view of your React Native app, get started with UXCam. The React Native quick start gets your first session recorded in a few minutes.

You might also be interested in these:

How to set up the React Native SDK

Session replay for React Native apps

Heatmaps for React Native apps

React Native crash reporting: tools and techniques

React Native Firebase Analytics setup guide

Mobile app event tracking

Top mobile app analytics tools