What am I able to do with the SDK setting "backdate session hits"? Does anyone have an example when this is important and how it works?
what happens with launches and crashes?
Solved! Go to Solution.
Views
Replies
Total Likes
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).
Views
Replies
Total Likes
Hi laetizia_w,
We have the backdate session support documented in our public GitBook: Adobe Analytics - Adobe Experience Platform SDKs
Let us know if this helps or if you have additional questions.
Emilia Dobrin
Sr. Mobile Engineer
Views
Replies
Total Likes
Thanks for the link but I am still not 100% sure if I understand it right.
My main goal is to see crashes and pages together in workspace. so the last page before a crash as happened so that I can see which page might have been affected of the crash.
when utrning on backdate session that would mean that if a crash occured it would go back 1 second to the previous hit instead of waiting until the next hit occures or a next launch occures, right?
For example:
User A --> page a --> page b--> crash --> comes back after 3 days
then crash would be counted after 3 days without backdate session turned on, right?
but if turned on it would be counted after page b, right?
how could I include now that the crash occured after page B so page b was the last seen page before the crash?
I have also read that backdate session could also create some extra servercalls. how would that be possible?
Another example:
user a -->launch 1 -->page a-->page b--> crash-->launch 2
without turning it on it would count the crash in launch 2, right?
If it would be turned on it would be counted for launch 1. If I create a crash metric with last touch it would also count crash for page b because it was the last value, right?
how can backdate session create a new visit (launch or real visit?) and an extra servercall?
I hope you are able to help me out on that!
Views
Replies
Total Likes
Hi laetizia_2018 - I'm moving this topic the analytics forum to hopefully answer your questions on how the backdate session options would affect server calls.
Views
Replies
Total Likes
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).
Views
Replies
Total Likes
thanks for your great explaination. it helped me a lot.
But what if my user opens the app gets an launch-->crash-->opens app again and sees page A
How would the crash be counted now? to the previous launch or the same one plus how can I combine the page to that crash when no screenwiew was completed?
Couldnt I include into launches page? and would this information exist only when a new launch get created or on every hit by then?
Views
Replies
Total Likes
It would be attributed to the previous launch, though the data wouldn't make it to Adobe until after the user launches the app again.
Views
Replies
Total Likes
Views
Likes
Replies
Views
Likes
Replies