Expand my Community achievements bar.

Webinar: Adobe Customer Journey Analytics Product Innovations: A Quarterly Overview. Come learn for the Adobe Analytics Product team who will be covering AJO reporting, Graph-based Stitching, guided analysis for CJA, and more!
SOLVED

backdate session hits

Avatar

Level 5

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?

1 Accepted Solution

Avatar

Correct answer by
Level 4

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).

View solution in original post

6 Replies

Avatar

Employee

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

Adobe Experience Cloud

Avatar

Level 5

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!

Avatar

Employee Advisor

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.

Avatar

Correct answer by
Level 4

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).

Avatar

Level 5

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?

Avatar

Employee Advisor

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.