Hi laetizia_2018
Crashes are always a different record than the other activity. (think of a crash as a whole new trackAction or s.tl call). You're initial thought process is correct about enabling the "backdate option" -> the goal is to make that record of a crash part of the previous session. In this case: session literally means Launch Event to Launch Event. Different than the definition of a visit in analysis workspace, which I explain later below...
Adobe's documentation on the topics of session/visits is very contradictory/confusing, but it's in fact written correctly. The definition of a 'session/visit' is actually nuanced depending on where you are looking at reports (Mobile Services Reporting, vs Reports & Analytics or Analysis Workspace). 'Session' as a container does not have an equivalent in Analysis Workspace, but that's a different topic...
Aside from the fun stuff of sessions/visits in reporting -> when you look at the crash from the point of view of a single record, it'll make more sense. Let's say the following is our example case:
1. I launch the app (Launch is recorded)
2. I view 'Page 1 of my app' (s.t call of 'Page 1' is recorded)
3. I view 'Page 2 of my app' (s.t call of 'Page 2' is recorded)
4. The app crashes (nothing can be sent at the moment, the app crashed)
---unknown amount of time passes---
5. I launch the app again (Launch is recorded)
6. The application now knows a crash happened before, and needs to send that record (a crash record is recorded)
7. I view 'Page 1 of my app' (s.t call of 'Page 1' is recorded)
(disclaimer: I don't remember with 100% accuracy if a crash record send is really in that exact spot at all times, but nevertheless the processing explanation is true)
Without backdating turned on, you can easily see where this record of a crash would be stored (by the order that everything is sent in).
With backdate session option enabled: When Adobe's servers process the record they will 'magically' adjust the timestamp of the crash record to be the final record of the previous series (after #3 above), and then store it.
So the end result of your records of information in the report suite looks like this if you have backdating turned on:
1. Launch record
2. Page1 pageview
3. Page2 pageview
4. Crash record
---unknown amount of time passes---
5. Launch record
6. Page1 pageview
This is where it can get really fun. Analysis Workspace will define a visit as records of data with no more than a 30 minute gap in-between.
So if your "---unknown amount of time---" is 20 minutes then everything here is within the same visit. So your 1 Visit has 2 Launches, 3 PageViews, and 1 Crash.
if your "---unknown amount of time---" is 45 minutes, then you will have 2 Visits. Remember that your "crash record" was backdated, so it's in the group of the first visit. Thus, the result is 2 Visits:
Visit #1: 1 Launch, 2 PageViews, 1 Crash
Visit #2: 1 Launch, 1 PageView
So, technically, backdated crash records will not cause additional visits - it's treated more like moving the record manually to the timestamp it should be close to, putting it with the previous bunch of records (which does NOT always mean the 'previous visit' , which is so gosh darn confusing. See example above when that "---unknown time---" is short).
