Adobe Experience Platform Data Collection

ericb17371700 · 5/19/21

Hi there,

I have a rather specific question when it comes to activating BackdateSessionInfo.

"When the hits are enabled, the Adobe SDK backdates the session info hit to 1 second after the final hit in the previous session. This means that crash and session data will correlate with the correct date on which they occurred. One side effect is that the SDK might create a visit for the backdated hit. One hit is backdated on every new launch of the application."

-Source: https://experienceleague.adobe.com/docs/mobile-services/ios/config-ios/json-config.html?lang=en

With backdateSessionInfo activated I will have additional hits for “SessionInfo” and “Crashes” and they are not send together with the “Launch Event”.

The very first assumption is, that the Crash and the SessionInfo hit will arrive inside Adobe as standard "s.tl" - "trackAction" hits and will hence count into the session and hit count. Is this understanding correct?

Question 1:

Are both hits "SessionInfo" and "Crashes" always attached to the previous visit and e.g., the visit length, hit depth ect.., is recalculated within the adobe backend? (So a visit which had 3 hits, now due to a crash has 4 hits)

I’m also thinking about a case, where a user opens an app from the background after one hour (a launch event should fire, but let’s assume the app crashes before the launch event can fire)Now the backdating puts the crash 1 second after the last hit. So the timing for this kind of unlikely edgecase would be not correct.

2. Is this the case?

In the documentation above it says: "One side effect is that the SDK might create a visit for the backdated hit." ->

In which case does adobe create a visit?

I hope you can help me to get a better understanding of the effects of the BackdateSessionInfo.

Thanks in advance and best

Eric

steve_benedick · 5/19/21

Hey @ericb17371700 -

Sorry for confusion caused by the old documentation. It used to be true that backdating session info hits could cause an extra visit (if more time than your Analytics visit timeout had passed since the user re-launched the app), but this behavior has been fixed on the backend so that backdated session info hits will no longer trigger a new visit.

> The very first assumption is, that the Crash and the SessionInfo hit will arrive inside Adobe as standard "s.tl" - "trackAction" hits

This is correct - SessionInfo is an SDK controlled type of "trackAction" hit.

> Are both hits "SessionInfo" and "Crashes" always attached to the previous visit

If backdateSessionInfo is enabled, yes.

> I’m also thinking about a case, where a user opens an app from the background after one hour (a launch event should fire, but let’s assume the app crashes before the launch event can fire)Now the backdating puts the crash 1 second after the last hit. So the timing for this kind of unlikely edgecase would be not correct.

As with most edge cases, the correct answer here is "it depends". On startup, the SDK is doing lifecycle calculations, updating values in local storage, and attempting to queue necessary hits in its database. The processing of those hits (e.g. - hit is sent to the Analytics data collection server) is independent from their creation. Depending on timing of a crash during startup, you may end up with unsent hits in the database (which would be processed on a subsequent launch), or the SDK may not have reach that point in its initialization. It all depends on the timing of the crash.

> I hope you can help me to get a better understanding of the effects of the BackdateSessionInfo.

The basic purpose of this setting is to ensure that all your data which cannot be calculated during the current session gets properly attributed back to the session in which it actually occurred.

The two specific examples are crashes and session length.

Crashes cannot be reported in the current session because the app is no longer running.
Session length cannot be reported in the current session because it cannot be fully calculated until the next session begins.

Here is a link to another similar post which may also help your understanding. https://experienceleaguecommunities.adobe.com/t5/adobe-analytics-questions/backdate-session-hits/qaq...

Hope this helps!

-steveb

View solution in original post

steve_benedick · 5/19/21

Hey @ericb17371700 -

Sorry for confusion caused by the old documentation. It used to be true that backdating session info hits could cause an extra visit (if more time than your Analytics visit timeout had passed since the user re-launched the app), but this behavior has been fixed on the backend so that backdated session info hits will no longer trigger a new visit.

> The very first assumption is, that the Crash and the SessionInfo hit will arrive inside Adobe as standard "s.tl" - "trackAction" hits

This is correct - SessionInfo is an SDK controlled type of "trackAction" hit.

> Are both hits "SessionInfo" and "Crashes" always attached to the previous visit

If backdateSessionInfo is enabled, yes.

> I’m also thinking about a case, where a user opens an app from the background after one hour (a launch event should fire, but let’s assume the app crashes before the launch event can fire)Now the backdating puts the crash 1 second after the last hit. So the timing for this kind of unlikely edgecase would be not correct.

As with most edge cases, the correct answer here is "it depends". On startup, the SDK is doing lifecycle calculations, updating values in local storage, and attempting to queue necessary hits in its database. The processing of those hits (e.g. - hit is sent to the Analytics data collection server) is independent from their creation. Depending on timing of a crash during startup, you may end up with unsent hits in the database (which would be processed on a subsequent launch), or the SDK may not have reach that point in its initialization. It all depends on the timing of the crash.

> I hope you can help me to get a better understanding of the effects of the BackdateSessionInfo.

The basic purpose of this setting is to ensure that all your data which cannot be calculated during the current session gets properly attributed back to the session in which it actually occurred.

The two specific examples are crashes and session length.

Crashes cannot be reported in the current session because the app is no longer running.
Session length cannot be reported in the current session because it cannot be fully calculated until the next session begins.

Here is a link to another similar post which may also help your understanding. https://experienceleaguecommunities.adobe.com/t5/adobe-analytics-questions/backdate-session-hits/qaq...

Hope this helps!

-steveb