Mobile monitoring best practices guide

First, add a new app in New Relic's user interface (full steps):

1. Go to one.newrelic.com > All capabilities > Mobile.

2. From the list of monitored apps, select Add more.

3. Select the relevant platform.

4. Type a name for your mobile app, and select Continue.

   Use one app and the associated app token for the development releases of your iOS app, another app and its associated app token for the production releases of that iOS app, and another pair of app tokens for development and production releases of your Android app. You'll be able to compare data from across the four app tokens using our query builder.

Next, install and configure the mobile agent:

1. Download the latest version of New Relic's SDK for iOS or Android, and add it to your mobile app. (Full steps for iOS and Android)
2. Configure your installation as needed. For example:
3. Enable the feature flag to capture MobileRequest events to use our full network analysis capabilities for iOS or Android.
4. Automate dSYM uploads for your production builds.
5. To avoid surprises, follow the standard pattern of where you start our mobile agent. In addition, start our agent before you initiate any other SDKs. For more information, see our documentation for Android installation and configuration and for iOS installation and configuration.
6. Deploy a new release of your application.

Find the cause of crashes so you can fix them. Then, uncover trends behind crashes so you can prevent them:

1. From the summary UI page for a monitored mobile app, click Crash analysis.

2. Analyze crash data so you can see and fix the most impactful crashes.

   Follow the breadcrumbs in the crash event trail to fix crashes and resolve critical errors more easily:

3. From your mobile app's Crash analysis page in the UI, select a Crash type.

4. From the crash type's Summary page, select the Crash trail tab.

Create custom breadcrumbs to monitor key workflows (such as your app's login or checkout process), track user clicks, optimize timing, and identify crash locations for faster MTTR.

Borrow from our example queries to:

• See how much of your user base has upgraded to your latest app version.
• Track adoption over time.
• Get a count of new installs as compared to upgrades from an earlier version.
• See the distribution of usage across geographical locations, carriers, ASN owners (wi-fi providers), devices, connection types, and more.

Use our metric-based alerts and mobile monitoring UI:

• Ensure that key members of your mobile team have opted in to receive emails for new crashes. These emails will take you to the crash type in the UI page for your mobile app.

• Create an alert for your crash rate threshold that key members of your team can view in Slack or any other alerts notification channel you choose.

  Your alert notification will include a link to our UI, where you can examine a chart with the exceeded threshold. From there, a link will take you to the relevant mobile monitoring page, where you can get additional details.

Combine the metric-based workflow with event-based alerts and ダッシュボード specific to your mobile app and system.

1. Create your NRQL alert that focuses on crashes of your most recently released production version.
2. Create an additional NRQL alert that focuses on the percentage of users impacted by crashes in your latest app version (to check the overall impact on your user base).

Crashes are an inevitable part of running mobile applications at scale. We provide tools to help you understand your highest-impact crashes. Use the Crash analysis UI to see which crashes are occurring most often, the percentage of crash-free users, which files and methods are associated with perhaps 80 percent of your crashes, which crashes a particular user just experienced, and more.

Go after high-impact crashes with crash analysis:

1. Add custom attributes to categorize the highest-value customers, and then use them to segment crashes according to your most valuable audiences.
2. Add breadcrumbs and custom events to produce a detailed trail of events leading up to every crash occurrence (over the last 90 days). Then, view this crash event trail in our mobile monitoring UI.
3. Use our mobile monitoring's Versions trends page to make sure you're improving the crash rate over subsequent releases and avoiding regressions.

Use breadcrumbs and custom attributes to better reproduce and debug crashes. For example, use our recordBreadrumb API to track mid-session changes in state that can help debug crashes, such as:

• Change of connection type
• Change of orientation
• CPU and memory state at key points in the app code

Add custom attributes to existing events, so you can ask even more precise questions of your mobile app. Add dimensions such as:

• User ID: Use to react to specific user concerns and to better understand which customers and segments are most impacted.

• Store ID: Use to address problems with out-of-date devices, bad wi-fi, and so on.

• User segments: Use to better understand which customers and segments are most impacted; for example, logged in vs. non-logged in.

• Money in the cart at session end

• Origin or attribution of entry into the app

  Standardize custom attribute names across your mobile apps, and align with your website (if you're using our ブラウザ監視), so that you can compare and contrast performance across end-user channels. The mobile agents track the last interaction of crashed and non-crashed sessions to provide visibility into what the user viewed before exiting your app (either intentionally or due to a crash).

Use custom events to track feature use. For example:

• Use custom events to track user flow between app and website.

• Use custom events or mobile breadcrumbs to optimize the performance of key user flows (log in, shopping cart, etc.).

• use custom events to provide faster, contextualized support experiences for your digital customers.

• Use the recordCustomEvent API. Then compare the use of different features using:

  SELECT count(*) FROM MyNewMobileEventType FACET name

  コピー

Use custom events to measure page load time:

1. Create an app-launch timer to measure the time that elapses between a user-tap to launch your app and the point in your app code where the first screen is available. Record the timer value in New Relic using something like the following:

   recordCustomEvent(<myMobileTimers>, <appLaunch>, {attributes})

   コピー

2. Define start and stop timers to measure spinner durations, and then record this time in New Relic using something like the following:

   recordCustomEvent(<myMobileTimers>, <spinnerOnScreenA>, {attributes})

   コピー

3. Track specific user actions or funnel steps in the app (like "add to cart"), and include the price as an attribute on that event.

4. Measure flows through the application by viewing the related funnel steps with custom events. For example, create a timer to track the start and end times of a subflow or an entire flow across multiple funnel steps to understand how long it took users to get through the process.

Use custom interactions to see traces associated with the same webpages.

1. Use the agent API to disable default interactions, and focus on custom interactions so that you can review the page loads that are most crucial to your primary funnel.

2. Define the start and stop times of these custom interactions to trace activities associated with individual steps of that funnel (for example, a specific user action or a page load).

3. Track the last interactions of crashed and non-crashed sessions so that you can see what the user viewed before exiting your app (either intentionally or from a crash).

   Example query for non-crashed sessions:

   SELECT count(*) FROM Mobile WHERE sessionCrashed IS NULL FACET lastInteraction SINCE 90 days ago

   コピー

   Example query for crashed sessions:

   SELECT count(*) FROM Mobile WHERE sessionCrashed = true FACET lastInteraction SINCE 90 days ago

   コピー