Crashes and App Users - Adobe Mobile Analytics | Community
Skip to main content
E
eungyu_park
June 23, 2022
Solved

Crashes and App Users - Adobe Mobile Analytics

  • June 23, 2022
  • 1 reply
  • 4625 views

Hi everyone,

I am working on a mobile analytics project and would like to check how crashes impact other metrics like the App Users. 

In an Adobe document https://aep-sdks.gitbook.io/docs/using-mobile-extensions/adobe-analytics/analytics-event-reference , a Crash event is defined...

"If your application is terminated without having first been backgrounded, the SDK reports a crash the next time your app is launched. If the backdateSessionInfo flag is enabled in your configuration, this information is sent as an individual hit". 

Does this mean that whenever a crash happens, it increases the number of "App Users" metrics that consist of foreground hit and background hit? If so, does it increase the foreground hit or background hit?  For your information, I enabled the backdate previous session.

Also, does a crash impact any other metrics as well?

 

Any help/feedback would be greatly appreciated.

Thank you.

This post is no longer active and is closed to new replies. Need help? Start a new post to ask your question.
Best answer by Jennifer_Dungan

Hi,

 

Let's try and break this up into scenarios, but first, it must be noted that the Lifecycle metrics don't pause by default in this version of the SDK... Adobe provides a lot more "customization" by doing this, but it cause also cause a lot of confusion.

 

In order to properly record crashes, you must ensure that when the app is sent into the background, lifecycle metrics are paused and when the app is brought back to active status that the lifecycle metrics are re-enabled.

 

 

Scenario 1 - backdateSessionInfo NOT enabled

 

Basically what this does, is when the app crashes.. the information about the crash is "remembered" by the app. The next time the app is opened, the lifecycle metrics sees that there was a crash, and the "crashEvent" data will be appended to the LifeCycle metrics along with the launchEvent and everything else in that first call. The timestamp of the crash will be recorded at the same time as the launch.

 

Scenario 2 - backdateSessionInfo IS enabled

 

When the app crashes, the information about the crash is remembered... same as scenario 1. The difference is how the data is sent to Adobe. In this scenario, the next time the app is launched you will get 2 lifecycle calls. One will be the crashEvent, which will be back dated to when the crash was recorded. Then there will be a separate call for the rest of the Lifecycle metrics at the current timestamp for LaunchEvent and the rest of the normal start up Lifecycle metrics.

 

 

 

This doesn't inflate the "App Users"... it's just another tracking server call for the same user, but the timestamp is back dated to when the crash occurred.  Basically think of Lifecycle metrics like fancy trackActions... you are sending 2 actions with different timestamps, vs a single action combining all the metrics into a single call.

 

 

 

Now, the part I mentioned earlier, and pausing and un-pausing your lifecycle metrics is very very important. The reason for this is, when users close your app... users will send the app to the background, then swipe it "off" to close. If your lifecycle metrics haven't been paused, this action will register as a crash... so basically ever time a user returns to your app after closing it will record a crashEvent (which is not what you want). Pausing the lifecycle metrics when it goes to the background means that the app being swiped off won't unintentionally register as a crash... and equally important, if the app isn't closed, and the user brings it back to the foreground, you want your lifecycle metrics to resume... if the app was minimized and reopened outside of your session timeout, that new session will now be recorded, and if the app crashes later that will be caught as well.

1 reply

Jennifer_Dungan
Community Advisor and Adobe Champion
Jennifer_DunganCommunity Advisor and Adobe ChampionAccepted solution
Community Advisor and Adobe Champion
June 23, 2022

Hi,

 

Let's try and break this up into scenarios, but first, it must be noted that the Lifecycle metrics don't pause by default in this version of the SDK... Adobe provides a lot more "customization" by doing this, but it cause also cause a lot of confusion.

 

In order to properly record crashes, you must ensure that when the app is sent into the background, lifecycle metrics are paused and when the app is brought back to active status that the lifecycle metrics are re-enabled.

 

 

Scenario 1 - backdateSessionInfo NOT enabled

 

Basically what this does, is when the app crashes.. the information about the crash is "remembered" by the app. The next time the app is opened, the lifecycle metrics sees that there was a crash, and the "crashEvent" data will be appended to the LifeCycle metrics along with the launchEvent and everything else in that first call. The timestamp of the crash will be recorded at the same time as the launch.

 

Scenario 2 - backdateSessionInfo IS enabled

 

When the app crashes, the information about the crash is remembered... same as scenario 1. The difference is how the data is sent to Adobe. In this scenario, the next time the app is launched you will get 2 lifecycle calls. One will be the crashEvent, which will be back dated to when the crash was recorded. Then there will be a separate call for the rest of the Lifecycle metrics at the current timestamp for LaunchEvent and the rest of the normal start up Lifecycle metrics.

 

 

 

This doesn't inflate the "App Users"... it's just another tracking server call for the same user, but the timestamp is back dated to when the crash occurred.  Basically think of Lifecycle metrics like fancy trackActions... you are sending 2 actions with different timestamps, vs a single action combining all the metrics into a single call.

 

 

 

Now, the part I mentioned earlier, and pausing and un-pausing your lifecycle metrics is very very important. The reason for this is, when users close your app... users will send the app to the background, then swipe it "off" to close. If your lifecycle metrics haven't been paused, this action will register as a crash... so basically ever time a user returns to your app after closing it will record a crashEvent (which is not what you want). Pausing the lifecycle metrics when it goes to the background means that the app being swiped off won't unintentionally register as a crash... and equally important, if the app isn't closed, and the user brings it back to the foreground, you want your lifecycle metrics to resume... if the app was minimized and reopened outside of your session timeout, that new session will now be recorded, and if the app crashes later that will be caught as well.

    E
    eungyu_parkAuthor
    June 24, 2022

    Hi Jennifer,

    Thank you so much for the detailed information! Those were really helpful : )

    I have some additional questions regarding crashes. I saw most of the crashes happen in iOS 14 and iOS 15. When I researched online, I saw that Apple made a big privacy update in iOS 14 and iOS 15.

    Do you happen to know if the updates in iOS 14 and iOS 15 possibly cause more crashes? Also, if we use old extension versions in Launch (i.e. v2.2.12 for Adobe Analytics, v2.1.16 for Mobile core, and v2.0.1 for Profile) will that cause any crashes for iOS 14 & iOS 15 or it shouldn't matter?

    Thank you.

    E
    eungyu_parkAuthor
    June 27, 2022

    I hadn't specifically noticed more crashes related to iOS 14/15 in our own implementation.. I mean the numbers are higher.. but the usage on those versions is similarly higher.... the correlation could just be a side affect of "most people get the updated os, therefore the crashes experienced will also be higher due to volume"

     

    Do your developers have any sort of crash log system (something like crashlytics) that can provide them more details about the crashes and the cause?

     

    Adobe is good for getting the raw numbers, so that you can get a general health check on your system...

     

    I unfortunately am not a mobile app developer, so I work closely with my team but they do more of that kind of analysis... I can't see any obvious reasons why those analytics versions would cause instability... but it so hard to say without knowing the code base of your app and how it calls the analytics....

     

    However, I assume you have a QA team that should be testing the apps with multiple OS versions... if there was an instability in that combination I would expect them to have triggered it during their test cycles, and a ticket would have been raised already.


    Thank you so much for your feedback, Jennifer!

    Terms & ConditionsAccessibility statement

    Loading footer...