On this page
Mobile recordings bring navigation, interactions and available screenshots together. Use them to see the steps people take and the context around a problem. The data you see depends on your SDK, UI framework and configuration.
Understand the different kinds of data
- Navigation describes movement between recognized screens or destinations.
- Interactions provide evidence of actions such as taps and long presses.
- Screenshots show captured visual states when screenshot collection is available and enabled.
- Device and lifecycle information gives context such as the app's foreground/background state and device configuration.
- Custom events describe outcomes your app explicitly sends.
These signals serve different purposes. A screenshot is not proof that every element was seen. A tap is not proof that the requested action succeeded.
Check your platform's collection path
| Integration | Navigation and visual context |
|---|---|
| Android 1.2.0 | Automatic Activity/Fragment tracking, Compose navigation registration, optional screen labels and configuration-dependent screenshots |
| iOS 1.1.11 | Native view-controller tracking, SwiftUI screen naming and configuration-dependent screenshots |
| React Native 1.0.22 | Native collectors plus React Navigation integration; React Native route names require the navigation helper or explicit calls |
| Flutter 0.0.27 | AnalyticsWidget, navigation observer/listener and optional named destination widgets |
Use the Android, iOS, React Native or Flutter guide for the actual setup. Do not apply an Android-specific capture list to every platform.
Separate screen names from implementation names
Technical names such as an Activity class or controller name may not describe a screen in terms your product team recognizes. Add meaningful names through the API for your SDK.
Native Android 1.2.0 uses screen() to label the current visible screen or state. React Native's CUX.screen() sends a screen event through its bridge. Similar method names do not mean identical behavior.
Know what a recording cannot establish
Native Android 1.2.0 does not activate the new native scroll analytics or deferred campaign attribution. Scroll-related capture work should not be presented as a released scroll-depth metric.
Element identifiers and monitorExpandedContent() do not establish element impressions or exposure rates. Optional preview stitching cannot recover content that was never captured.
Screenshot timing depends on configuration and capture conditions. Do not expect a screenshot after every interaction or a complete frame-by-frame recording.
Check your own journey
Run a short test with navigation, a tap, a long press where relevant, a background/foreground transition and a sensitive screen. Compare the actions you performed with the data in CUX.
Check unavailable or missing signals individually. Start with configuration and your platform's integration instructions rather than assuming all collection has failed.