Data Analysis

Anomaly Diagnosis

App Device Performance Analysis

Automatically match AE preset fields across the four performance scenarios of device compatibility, frame-rate stutter, page loading, and crashes, pinpoint performance bottlenecks, and output technical optimization recommendations.

IndustriesGamesUtility apps

Agent · Skills Live

skill · loadedindustry+100

Run this Skill on my data

Anomaly detected

vs baseline

Analysis readyevidence attached

App Device Performance Analysis is a technical-analysis capability in ThinkingAI's industry Skill library. It helps engineering teams automatically match device-performance preset fields in AE, complete a full performance analysis across device compatibility, frame-rate stutter, page loading, and crashes, pinpoint bottlenecks, and output actionable technical optimizations. This is ThinkingAI's decade of industry experience, packaged into ready-to-use Skills.

Live walkthrough

AgentSave as AgentExport session

app-device-performance-analysis

After v3.2 shipped, the Android crash rate climbed to 5.2%, when it had been under 2% for a long time. The client team spent a week and only ruled out iOS; there are too many device models to sift through. Help me cross-locate it by device model and page.

Auto-match AE preset performance fields

#app_crashed, #app_crashed_reason, #device_model, #os, #app_version all available

Pull v3.2 crash rate by device series for a sample ARPG game DEMO

vivo Y series 12.1%, all other models combined 1.9%

Multi-dimensional cross drill-down: device model × OS version × page

vivo Y × Android 9.0 × battle-results page crash rate 25.3%

Cluster #app_crashed_reason crash-stack keywords

78.4% point to OpenGL render out-of-memory

Generate a downgraded-rendering recommendation and a canary validation plan

Located it, no need to keep sifting through every model: the crashes concentrate on a single combination, vivo Y series × Android 9.0 × battle-results page: roughly 32% of active Android devices contribute about 75% of the crash volume, and the root cause is OpenGL render out-of-memory.

1. By device tier: the problem is highly concentrated

v3.2 crash rate for major device series (Android)　Unit: %

The vivo Y series crash rate is 12.1%, more than 6x the combined figure for all other Android models (1.9%). That series is mostly low-to-mid-end phones with 4GB of RAM or less and makes up about 32% of the project's active Android devices: 30% of devices contribute about 75% of the crashes, which is why the overall rate jumped from under 2% to 5.2%.

2. Multi-dimensional cross: narrowing to the page level

Dimension combination	Crash rate	Note
Android overall (v3.2)	5.2%	2.6x the 2% alert line
vivo Y series (all)	12.1%	About 75% of total Android crashes
vivo Y × Android 9.0	19.8%	55.3% of this series' devices sit on Android 9.0
vivo Y × Android 9.0 × battle-results page	25.3%	The densest crash combination
All other Android models combined	1.9%	Below the alert line, no action needed

Crash-stack clustering result: 78.4% point to OpenGL render out-of-memory, triggered by the new full-screen particle effect added to the v3.2 battle-results page, where low-memory + old-OS devices get killed by the system right at the effect's load peak. It looks normal by device model alone and normal by page alone; the problem only surfaces once you cross them.

3. Fix recommendations

Downgrade rendering on low-memory devices: turn off the full-screen particle effect on the battle-results page and downsample textures (targeting devices with 4GB of RAM or less)

Switch results-effect assets to lazy loading to avoid stacking on top of the battle memory peak

Canary to 20% of vivo Y devices first, compare crash rates, then roll out fully

Conclusion

Based on comparable cases, once low-memory downgraded rendering ships, the vivo Y series crash rate can drop from 12.1% to around 1.5%, and the overall crash rate from 5.2% back to 1.8%, back within the alert line. During the canary, we'll keep comparing the recovery curve of #app_crashed event volume.

The multi-dimensional cross report is saved to the performance dashboard; the canary comparison task is configured and will produce a comparison conclusion automatically once v3.2.1 ships.

On your data

That was a simulated run

Leave your work email and we will run a live walkthrough on your real business data.

The problem

App performance problems hurt the user experience the most but are also the hardest to investigate systematically. Engineering teams average a 2 to 3 week investigation cycle, spend 80% of that time manually pulling data and finding field names, and locate the issue with multi-dimensional crossing less than 10% of the time. Unfamiliar with the AE field system, many teams can only dig through crash logs by hand and cannot pin down the hidden bottleneck in a specific version, device model, and page combination.

What it does

Automatic field matching: automatically match the fields needed for performance analysis based on AE official preset properties, with no manual lookup of field names and data types

Full coverage of four performance scenarios: device compatibility, frame-rate stutter, page loading, and crashes, each with a standard analysis flow and thresholds

Multi-dimensional crossing: cross device x OS x app version x page across four dimensions to pin down hidden bottlenecks that show no anomaly on any single dimension but appear in combination

When to use it

Locating the device model, version, or page when the app crash rate is abnormally high

Investigating frame-rate stutter and slow page loading on low-end devices

Performance compatibility validation after a new app version launches

Investigating adaptation problems on a specific device model or OS version

Collecting bottleneck data before page-loading performance optimization

In the field

Case

A game app · Android crash-rate location

The Android crash rate reached 5.2% and 2 weeks of investigation found nothing. The Skill automatically matched AE preset fields, and multi-dimensional crossing found that v3.2 had a 25% crash rate on the battle-result page on vivo Y series with Android 9.0, concentrated in OpenGL render memory overflow. After downgrading rendering for low-memory devices, the vivo Y series crash rate fell from 12% to 1.5% and the overall crash rate fell from 5.2% to 1.8%.

FAQ

What tracking does performance analysis need?

AE already presets device-info fields; crash analysis needs the #app_crashed event and #app_crashed_reason, while frame rate and page loading need additional tracking for the relevant events.

How are performance thresholds set?

Default thresholds flag anomalies such as frame rate below 50fps, page load over 3 seconds, or crash rate over 2%, and teams can adjust them for their product.

How does this differ from traditional crash-log analysis?

Traditional logs show the stack trace, while the Skill combines AE user behavior and device info to quantify the impact scope and pinpoint the concentrated devices.