The data and the discrepancy is due to the fact that data sources for the Mobile App Crashes Metric (EUM) and the Crash Events Count (Analytics) are different. The data for the Mobile App Crashes Metric is from EUM metrics stored in the Controller DB and the data in the Crash dashboards of Crash Analytics is from the Analytics Events Service Store.
Crashes tend to not be sent immediately (because the app crashed) so the data comes in late when the app is started back up. This could be minutes, hours, or days. When we receive a crash that happened yesterday, the metric gets incremented by 1 but you won't see the crash in Analytics unless you set a long time range.
EUM Crash Metrics on the Controller side get registered when the data arrives at EUM Server side for that minute, whereas, at the same time on Analytics side, the application crash event gets stored in the Events Service but mapped to a timeline when the crash actually occurred. This will based on eventTimestap, not pickupTimestamp.
Unfortunately, when the application crashes the agent does not get a chance to post the beacon because the application gets closed. We cannot control when the user will open the application next.
Metrics, by design, rely on current minute data that later gets rolled over. Therefore, the crash metrics from the past that are arriving in the current minute cannot be put in metrics from the past since those were already rolled over. Crash metrics need to be accounted for when they arrive.
Analytics events, by design, work on the raw data and are mapped on timescale by eventsTimestamp and not pickupTimestamp.
Therefore, the Mobile App Crashes Metric (EUM) and the Crash Events Count (Analytics) will mostly be different.
