> ## Documentation Index
> Fetch the complete documentation index at: https://test-8ad8522e-feat-ai-sre.mintlify.site/llms.txt
> Use this file to discover all available pages before exploring further.
# Native
> Learn about the Flashduty Native (Android/iOS) RUM Insights dashboard core features for mobile app performance monitoring, error tracking, and resource analysis
Flashduty Native RUM Insights dashboard provides out-of-the-box visualization dashboards that automatically collect and analyze multi-dimensional data including user sessions, app performance, crash errors, and network requests. This helps you gain comprehensive insights into your mobile app's real-world performance, quickly identify performance bottlenecks and issues, and continuously optimize user experience.
The Insights dashboard includes 4 core analysis dimensions: **Overview**, **Performance Analysis**, **Error Analysis**, **Resource Analysis**
**Platform Differences**
The Native dashboard applies to Android, iOS, HarmonyOS, Flutter, and React Native apps, with the following platform-specific differences:
* **Flutter / React Native**: A single Flutter or React Native app spans both Android and iOS, so the filter bar additionally pins the `os_name` filter to let you slice metrics by device OS. In the Overview and Error Analysis, the **ANR Rate** (from Android devices) and **Unresponsive Time Rate** (from App Hangs on iOS devices) cards are displayed side by side.
* **HarmonyOS**: The SDK does not report performance or hang metrics yet, so hang-related cards are hidden and the "Performance" tab is not available.
* **Electron**: Does not use the Native dashboard — Electron apps reuse the **Web Insights dashboard**, but UV is keyed on the anonymous ID (the Electron SDK does not report `usr_id`). See "Metrics Reference" below.
## Overview — Key Metrics at a Glance
The Overview module focuses on core metrics across multiple dimensions for mobile apps:
* **Traffic Metrics** - Monitor UV (Unique Visitors) and sessions to understand overall user activity trends
* **Core Health Metrics** - Highlight three key mobile app metrics: crash count, crash-free rate, and unresponsive time rate for quick identification of stability issues
* **User Access Trends** - Track UV and Session trends over time through time-series charts to understand user activity patterns
* **User Distribution** - Analyze user sources by geographic location to understand regional user activity
* **Session Analysis** - Track average session duration distribution trends to evaluate user engagement and usage depth
* **Version Distribution** - Monitor user distribution across different system versions (Android/iOS) and app versions to support compatibility optimization and version iteration
## Performance Analysis — Comprehensive App Experience Monitoring
The Performance Analysis module focuses on full-chain monitoring of core experience metrics including app startup, page rendering, and interaction smoothness.
#### Core Performance Metrics
The top section displays P75 percentile values for four key performance metrics:
* **App Startup Time (P75)**: Monitor the P75 percentile of app startup duration to evaluate startup performance. Startup time directly impacts user first impressions and willingness to use the app.
* **Frame Rate (P75)**: Display the P75 percentile of runtime frame rate to measure visual smoothness. Target is 60fps; higher values indicate smoother interactions. The SDKs normalize per-frame samples from high-refresh-rate screens (ProMotion, 120Hz Android devices) to a 60fps baseline and cap them at 60, so this metric reflects relative smoothness rather than the display's physical refresh rate.
* **CPU Usage (P75)**: Track the P75 percentile of CPU utilization to identify compute-intensive operations. High CPU usage leads to device heating and increased battery drain.
* **Memory Usage (P75)**: Monitor the P75 percentile of app memory usage to detect memory leaks or abnormal growth early.
* **JS Thread Frame Rate (P75)**: Monitor the P75 percentile of the React Native JS thread's frame rate (FPS). Compared with the native frame rate, it reflects jank caused by business JavaScript more directly (re-renders, synchronous work on the bridge). Reported only by the React Native SDK.
#### App Startup Time Analysis
* **Startup Time Trend Chart**: Shows how app startup time changes over time, helping you evaluate optimization effectiveness and detect performance regressions.
* **Sample Distribution Histogram**: Statistics of startup duration distribution by time intervals (e.g., 0.9425s-0.9642s, 1.1162s-1.1379s), providing insights into real user startup experience distribution and identifying long-tail performance issues.
#### View Performance Details
Performance metrics by view name (Page/Activity/ViewController):
* **Visit Count**: Shows visit volume for each view to identify high-frequency core pages.
* **Startup Time**: Monitor loading duration for each view to locate slow-loading pages.
* **Frame Rate**: Track runtime frame rate performance for each view to identify rendering issues.
* **JS Thread Frame Rate**: Track each view's React Native JS thread frame rate (FPS) to spot business-JavaScript jank; reported only by the React Native SDK, so this column is empty for other platforms' views.
* **CPU Usage**: Statistics of CPU utilization for each view to optimize compute-intensive pages.
* **Memory Usage**: Monitor memory usage for each view to detect memory leak risks.
#### Smoothness Analysis
App smoothness metrics by view name:
* **Slow Frame Share**: Share of the measured time spent on slow frames. A slow frame is one that exceeds the display's frame budget (about 16.67ms at 60fps, less on high-refresh screens) without reaching the frozen-frame threshold. The higher this value, the more stuttering users perceive. Mobile SDKs report only this share, not a slow-frame count.
* **Frozen Frames**: Count of single main-thread tasks running longer than 700ms, which leave the UI completely stuck and unresponsive.
* **Long Tasks**: Count of main-thread tasks running past the threshold (100ms by default on both Android and iOS, configurable), used to locate performance bottlenecks. Long tasks block user interactions and UI updates.
* **Freeze Frequency**: Frozen frames per second of view time (frozen frames / time spent), evaluating overall smoothness performance.
* **JS Frame Rate (Average)**: The average JS-thread frame rate across that view's updates; highlighted below 50 FPS. Reported only by the React Native SDK.
* **JS Frame Rate (Minimum)**: The lowest JS-thread frame rate recorded in any single update of that view — the worst jank a user encountered; highlighted below 30 FPS. Reported only by the React Native SDK.
**Frozen Frames, Long Tasks and Freeze Frequency all come from one source.** On mobile, frozen frames are not counted from rendered frames — they are the subset of long tasks running past 700ms, and Freeze Frequency is derived from the frozen-frame count. So once long-task collection is disabled in the SDK, all three columns sit at **0 at the same time** — meaning "not measured", not "no freezes".
Slow Frame Share travels a separate path and is unaffected. A table showing a Slow Frame Share alongside three zeroed columns is therefore the expected result of disabling long-task collection, not missing data.
If you disabled long-task collection to reduce event volume, raising the threshold is a better option than turning it off — see [Android performance impact](/en/rum/sdk/android/performance-impact).
**Slow Frame Share is not comparable across platforms.** The numerator is slow-frame time on both, but the denominator differs: Android divides by total frame render time, iOS by view duration. The same user experience usually scores much higher on Android, because a static screen produces almost no frames — a small denominator — while the first frame is by definition a slow one. Compare values within a single platform over time.
#### Memory Analysis
Memory usage details by view name:
* **Average Memory**: Shows average memory usage for each view to understand typical memory consumption levels.
* **Peak Memory**: Records peak memory usage during view runtime to identify memory pressure peaks and prevent system termination due to insufficient memory (OOM).
* **P75 Memory**: Shows the P75 percentile of memory usage, reflecting memory usage for most users, more representative of real experience than averages.
## Error Analysis — Quick Error Identification and Diagnosis
The Error Analysis module provides comprehensive error monitoring and diagnosis capabilities.
#### Core Stability Metrics
* **Crash Count**: Monitor total crash occurrences and trends to detect abnormal spikes early. Crashes force app termination and severely impact user experience.
* **Crash-free Rate**: Track the percentage of crash-free sessions to evaluate overall app stability. Industry standard recommends maintaining crash-free rate above 99.5%.
* **ANR Rate**: Statistics of Android Application Not Responding occurrence rate. ANR indicates the app's main thread has been blocked for more than 5 seconds, causing users to see the "App Not Responding" dialog.
* **Unresponsive Time Rate**: Seconds the main thread was unresponsive per hour of view time (seconds/hour), averaged by view time and counted only over views the SDK finished measuring. **This card is shown for iOS and Flutter apps only**; Android-only apps show the ANR Rate above instead. See "How to reduce unresponsive time rate?" below.
#### Error Statistics
* **Error Count**: Shows total error count and time-series trends to understand overall app health changes.
* **Error Type Distribution Trend Chart**: Stacked bar chart showing distribution changes of crash errors (crash\_count) and non-crash errors (non\_crash\_count) over time, quickly identifying abnormal periods and error type change trends.
* **Crash Errors (crash\_count)**: Severe errors causing forced app termination
* **Non-crash Errors (non\_crash\_count)**: Caught exceptions where the app can continue running but functionality may be affected
#### Page Crash Ranking (Top 10)
Lists pages or view controllers with the most crashes, each record containing:
* **Error Type**: Exception type of the crash (e.g., java.lang.RuntimeException, SIGTRAP, etc.)
* **Error Message**: Detailed error description to help quickly locate the issue
* **Error Count**: Total occurrences of this error on this page
* **Session Count**: Number of sessions (user visits) affected by this error
This ranking helps you prioritize the most impactful page crash issues.
#### Top Issues (Top 10)
Shows ranking of issues affecting the most users. Each Issue is an aggregated collection of errors containing:
* **Error Type**: Primary error type of the Issue (e.g., java.lang.RuntimeException, TypeError, ReferenceError, etc.)
* **Error Message**: Typical error description of the Issue; click to view detailed stack traces and session information
* **Error Count**: Total error occurrences in this Issue
* **Session Count**: Number of sessions affected by this Issue
**Note**: An Issue may aggregate multiple errors with the same root cause. For Issue aggregation strategy, see [Error Grouping](/en/rum/error-tracking/error-aggregation).
#### Error Type Distribution
* **Error Type Proportion (Pie Chart)**: Shows proportion of different error types (e.g., ReferenceError, java.lang.RuntimeException, etc.) to quickly identify main error sources.
* **Error Type Distribution Trend (Stacked Bar Chart)**: Monitor changes in each error type over time to detect new error types or abnormal growth of certain errors.
#### Version Crash Distribution
* **Version Crash Distribution (Pie Chart)**: Statistics of crash distribution across different app versions to identify high-risk versions.
* **Version Crash Distribution Trend (Stacked Bar Chart)**: Monitor crash changes across versions over time to evaluate new version quality and perform hotfixes or rollbacks when necessary.
#### System Version Error Distribution
* **System Version Error Distribution (Pie Chart)**: Statistics of error distribution across different OS versions (e.g., Android 11, Android 12, iOS 15, etc.) to identify system compatibility issues.
* **System Version Error Trend (Stacked Bar Chart)**: Monitor error changes across system versions over time to support system compatibility optimization.
For in-depth analysis of specific errors, see [Error Tracking](/en/rum/error-tracking/overview) to learn how to investigate critical errors, view error stacks, track new error occurrences, and verify fixes.
## Resource Analysis — Fine-grained Network Performance Optimization
The Resource Analysis module helps you gain deep insights into your app's network request performance and identify optimization opportunities:
* **Request Count**: Monitor network request volume trends to understand app network activity.
* **Request Success Rate**: Track successful request percentage to detect network anomalies early.
* **Median Request Time**: Shows median request duration changes (e.g., p50, p75, p95) to evaluate overall network performance levels.
* **Slow Requests**: Statistics of slow request trends exceeding response time thresholds to locate performance bottlenecks.
* **Failed Requests**: Monitor occurrence of failed or error requests to quickly identify API issues.
* **Resource Request Status Distribution**:
* **Request Status Code Proportion**: Pie chart showing distribution of different HTTP status codes (e.g., 200, 404, 500) to identify abnormal request types.
* **Request Status Code Trend**: Monitor status code changes over time to detect abnormal spikes.
* **Request Method Distribution**:
* **Request Method Proportion**: Shows usage distribution of different HTTP methods (GET, POST, etc.).
* **Request Method Trend**: Analyze time-series changes of each request method.
* **Static Resources**:
* **Static Resource Call Ranking**: Lists most frequently called static resources (e.g., images, fonts, config files) to understand resource usage popularity.
* **Static Resource Response Ranking**: Identifies slowest responding static resources to optimize resource loading performance.
* **Network Call Ranking**:
* **Host Ranking**: Statistics of request count by source (Host) to identify main dependent service endpoints.
* **Resource Timing Ranking**: Lists longest-duration network requests with timing details (DNS resolution, TCP connection, SSL handshake, time to first byte, response time, etc.) for precise performance bottleneck identification.
## FAQ
Status code 0 is typically caused by:
* **Request Cancelled** - User left the page or cancelled the operation before the request completed, causing request interruption
* **Network Interruption or Timeout** - Request encountered network interruption, timeout, or other anomalies during transmission, potentially preventing normal status code return
* **Certificate Validation Failed** - HTTPS request SSL certificate validation failed, connection interrupted before establishment
* **SDK Compatibility** - In rare cases, specific system versions or devices may have compatibility issues causing incomplete data collection
* **Error Count** - Total count of raw error events, including every error occurrence record
* **Issue Count** - Count of aggregated issues. Flashduty aggregates similar errors into the same Issue based on error stack, error type, occurrence location, and other information
**Example:**
```
Total Errors: 100
Issue Count: 5
```
This means 100 errors were aggregated into 5 different Issues, each potentially caused by different root causes.
Benefits of aggregation:
* Easier root cause identification: Errors with the same root cause are grouped into one Issue, avoiding duplicate handling
* Priority ranking: Identify issues most needing fixes through impact scope (error count, session count)
* Track fix effectiveness: After fixing an Issue, observe whether all errors under that Issue disappear
Learn more about [Error Grouping](/en/rum/error-tracking/error-aggregation).
Use "Page Crash Ranking" and "Top Issues" to quickly locate the most impactful crash issues.
Click on specific Issues to view detailed error stacks and user environment information for precise problem code location.
Use "System Version Crash Distribution" to identify compatibility issues with specific system versions.
Use "Version Crash Distribution" to evaluate new version quality and perform hotfixes or rollbacks when necessary.
Use try-catch and global exception handlers appropriately to prevent uncaught exceptions from causing crashes.
Percentiles are important statistical indicators for measuring data distribution:
| Percentile | Meaning |
| ---------------- | ------------------------------------------------------------------- |
| **P50 (Median)** | 50% of users have better experience than this value, 50% have worse |
| **P75** | 75% of users have better experience than this value, 25% have worse |
| **P90** | 90% of users have better experience than this value, 10% have worse |
| **P95** | 95% of users have better experience than this value, 5% have worse |
**Why use P75 instead of average?**
* Averages are easily skewed by extreme values and may not represent most users' real experience
* P75 better reflects the experience of most users and is an industry-standard performance evaluation metric
* Google recommends using P75 as a core performance metric
**Example:**
```
App Startup Time P75 = 1.7s
→ 75% of users have startup time within 1.7s, 25% exceed 1.7s
Memory Usage P75 = 233MB
→ 75% of scenarios have memory usage within 233MB
```
These are important metrics for measuring app smoothness:
| Metric Type | Threshold | User Experience Impact | Priority |
| ---------------- | --------------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------- | ----------------------------------------------------- |
| **Slow Frame** | Render overruns the frame budget without reaching the frozen-frame threshold (> \~16.67ms at 60fps, less on high-refresh screens) | Minor jank | Occasional is acceptable, frequent needs optimization |
| **Frozen Frame** | Single main-thread task > 700ms | Complete UI freeze, user cannot interact | Severely impacts experience, must fix |
| **Long Task** | Main thread execution past the threshold (100ms by default, configurable) | Blocks user interaction and UI updates | Needs optimization |
**Common causes of long tasks:**
* Complex calculations
* Large data processing
* Synchronous I/O operations
**Optimization suggestions:**
* Move time-consuming operations to background threads
* Process large amounts of data in batches
* Optimize algorithm complexity
* Avoid synchronous network requests or disk I/O on the main thread
Use "Page Loading Time Ranking" to identify the slowest loading pages and prioritize optimization.
* Use pagination or virtual list techniques to avoid loading large amounts of data at once
* Use data preloading and caching strategies to reduce wait times
* Optimize network requests and merge API calls
* Reduce view hierarchy nesting to lower layout calculation complexity
* Avoid overuse of transparent views and rounded corner effects
* Lazy load non-first-screen content
* Use appropriate image formats and sizes
* Use progressive loading or placeholder images
* Compress and cache images
Move complex view rendering operations to background threads.
**ANR (Application Not Responding)** is Android's app unresponsive mechanism:
* When the app's main thread is blocked for more than 5 seconds, the system displays an "App Not Responding" dialog
* Users can choose "Wait" or "Close App"
* ANR severely impacts user experience and may lead to app uninstallation
Common ANR causes:
* **Main thread executing time-consuming operations**: Synchronous network requests, large file I/O, complex calculations, database operations
* **Main thread waiting for locks**: Multi-thread deadlocks, waiting for other threads to release locks
* **Insufficient system resources**: CPU occupied by other apps, insufficient memory causing frequent GC
**Methods to reduce ANR rate:**
1. **Avoid main thread blocking** - Move time-consuming operations to background threads (using AsyncTask, Coroutines, RxJava, etc.)
2. **Optimize lock usage** - Reduce lock hold time, avoid nested locks, use lock-free data structures
3. **Optimize lifecycle methods** - onCreate/onResume and other methods should return quickly
4. **Monitor and analyze** - Use StrictMode to detect main thread violations, use RUM dashboard to locate issues
Use "Long Task Monitoring" and "Freeze Duration Distribution" to identify specific code causing freezes.
Move time-consuming operations (network requests, database I/O, complex calculations, large file I/O) to background threads.
* Reduce view hierarchy to lower layout complexity
* Avoid complex view calculations on the main thread
* Use RecyclerView (Android) or UITableView/UICollectionView (iOS) optimization techniques
* Use hardware acceleration appropriately
* Implement view recycling mechanisms
* Optimize item layout complexity
* Avoid time-consuming operations during item binding
Combine performance Insights dashboard with system tools (Android Profiler, Xcode Instruments) to locate specific freeze code.
The data source and threshold differ per platform:
* **iOS**: Sourced from App Hangs, controlled by the SDK's `appHangThreshold`. This option **defaults to `nil`, meaning detection is off** — it must be set explicitly before any data is produced. A value of 0.25–0.5 seconds is recommended. See [iOS advanced configuration](/en/rum/sdk/ios/advanced-config).
* **Android**: Sourced from main-thread freezes, counted only once a main-thread task reaches 5 seconds. The threshold is fixed and cannot be configured. Android-only apps do not show this metric — use the ANR Rate instead.
* **Flutter**: One app spans both OSes, so ANR Rate and Unresponsive Time Rate appear side by side. Their thresholds differ, so do not compare them directly.
**Logged-in User Identification**
For apps requiring user login (e.g., e-commerce, social, finance), you can call the SDK's user identification method after user login:
* Android: See [Android User Session Configuration](/en/rum/sdk/android/advanced-config#enrich-user-sessions)
* iOS: See [iOS User Session Configuration](/en/rum/sdk/ios/advanced-config#enrich-user-sessions)
**Device Fingerprint Identification**
For apps without login state, we recommend generating stable device fingerprints based on device information and reporting them as user identifiers:
| Platform | Available Identifiers |
| ----------- | ---------------------------------------------------------------- |
| **Android** | Android ID, IMEI (requires permission), Advertising ID |
| **iOS** | IDFV (Identifier for Vendor), IDFA (requires user authorization) |
Use "Resource Timing Ranking" to locate APIs with the longest response times.
Review DNS resolution, TCP connection, SSL handshake, time to first byte, and other phase durations to precisely locate bottlenecks.
| Optimization Area | Specific Measures |
| --------------------------- | ------------------------------------------------------------------ |
| **DNS Optimization** | Use DNS caching, HTTPDNS |
| **Connection Optimization** | Enable HTTP/2, connection reuse, reduce redirects |
| **Transfer Optimization** | Enable GZIP compression, optimize data format, reduce request size |
| **API Optimization** | Optimize backend API performance, use CDN for static resources |
* Review "App Startup Time (P75)" metric to understand most users' startup experience
* Use "Startup Time Trend Chart" to evaluate optimization effectiveness and detect performance regressions
* Review "Sample Distribution Histogram" to identify long-tail issues
Delay non-essential initialization operations until after first screen rendering to reduce startup time.
Reduce third-party SDKs and libraries loaded during startup, adopt lazy loading strategies.
Reduce home page view hierarchy complexity to decrease first render time.
* **Android**: Use App Startup Library to manage component initialization order
* **iOS**: Use Lazy Initialization to delay initialization of non-critical components
Flashduty RUM typically completes data collection and display within **1-3 minutes** after data generation. Under good network conditions, most data can achieve near real-time updates.
## Metrics Reference
### Overview Metrics
| Metric | Collection Field | Description |
| -------------------- | ---------------------------- | --------------------------------------------------------------- |
| UV | usr\_anonymous\_id / usr\_id | Total deduplicated users, see the note below for the definition |
| Session Count | session\_id | Total sessions when app is opened and used |
| Avg Session Duration | - | Total session duration divided by total sessions |
| Session Frequency | - | Total sessions divided by active users |
**UV definition**: On the Native (Android/iOS/HarmonyOS/Flutter) dashboard and app cards, UV is keyed on the device-stable anonymous ID, i.e. `COUNT(DISTINCT COALESCE(NULLIF(usr_anonymous_id, ''), NULLIF(usr_id, '')))`. The anonymous ID persists across login, so an anonymous session and the same person's later logged-in session count as one user; when anonymous user tracking is disabled, it falls back to `usr_id`. Web (browser) and Mini Program dashboards keep the `usr_id` definition unchanged; **Electron apps also use the Web dashboard, but their UV is keyed on the anonymous ID like the Native dashboard** — the Electron SDK does not report `usr_id` (it is always empty), and the stable identifier is injected by the main process as `usr_anonymous_id`.
### Performance Metric Thresholds
| Metric | Collection Field | Good | Moderate | Poor |
| -------------------- | -------------------------------------------------------------------------- | ---------------- | ---------------- | ------------------- |
| App Startup Time | vital\_duration (vital\_type=app\_launch, vital\_app\_launch\_metric=ttid) | Within 2s | Within 4s | Over 4s |
| Frame Rate | view\_refresh\_rate\_average | 55 FPS or above | 50 FPS or above | Below 50 FPS |
| CPU Usage | view\_cpu\_ticks\_per\_second | Below 40 ticks/s | Below 60 ticks/s | 60 ticks/s or above |
| Memory Usage | view\_memory\_average | Below 200 MB | Below 400 MB | 400 MB or above |
| Peak Memory | view\_memory\_max | Below 200 MB | Below 400 MB | 400 MB or above |
| JS Thread Frame Rate | view\_js\_refresh\_rate\_avg | 55 FPS or above | 50 FPS or above | Below 50 FPS |
### Smoothness Metrics
| Metric | Definition | Collection Field |
| ----------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------------------------- |
| Slow Frame Share | Share of the measured time spent on slow frames (Android divides by total frame render time, iOS by view duration — not comparable across platforms) | view\_slow\_frames\_rate |
| Frozen Frames | Count of single main-thread tasks over 700ms; stays 0 when long-task collection is disabled | view\_frozen\_frame\_count |
| Long Tasks | Count of main-thread tasks past the threshold (100ms by default, configurable) | view\_long\_task\_count |
| Freeze Frequency | Frozen frames divided by view time, i.e. average freezes per second | - |
| JS Frame Rate (Average) | The average JS-thread frame rate across that view's updates; highlighted below 50 FPS; reported only by the React Native SDK | view\_js\_refresh\_rate\_avg |
| JS Frame Rate (Minimum) | The lowest JS-thread frame rate recorded in any single update of that view, i.e. the worst jank a user encountered; highlighted below 30 FPS; reported only by the React Native SDK | view\_js\_refresh\_rate\_min |
### Stability Metrics
| Metric | Calculation | Description |
| ---------------------- | ----------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------- |
| Crash Count | Direct count | Total crashes caused by unhandled exceptions or signals |
| Crash-free Rate | Session-based: 1 minus (sessions with at least one crash / total sessions) | Recommended to maintain above 99%; a session that crashes several times still counts once. Android ANRs are not crashes and do not affect this metric |
| ANR Rate | ANR sessions divided by total sessions | Triggered when UI thread blocked over 5 seconds (Android) |
| Unresponsive Time Rate | Total unresponsive main-thread time divided by total view time, expressed as seconds/hour | iOS counts App Hangs and requires `appHangThreshold`; Android counts main-thread freezes that reach 5 seconds |
## Further Reading
### SDK Integration and Configuration
Learn how to integrate RUM SDK in Android apps
Learn how to integrate RUM SDK in iOS apps
Configure advanced Android RUM SDK features
Configure advanced iOS RUM SDK features
Learn about data types collected by Android RUM SDK
Learn about data types collected by iOS RUM SDK
### Data Analysis and Monitoring
Learn how to use RUM Explorer for in-depth data analysis
Master error tracking and debugging techniques
Understand error grouping mechanisms