IOS (objective C) Sessionid and index change way more than set in timeout

For engineers Tracking SDKs
1

Hi all,

Had a question with regards to the snowplow Objective-C SDK (we use this SDK by mapping the values through to swift, not sure if that’s relevant). We are currently tracking data from the IOS app with this SDK, but are finding that the sessioncontext (the mechanism that tracks whether or not a new sessionid should be initialized) is acting strange. Apparently, new session id’s and indices are initialized way sooner than what we setup (within a couple of seconds). As far as we know this has been the case since we started, but since we’re now actively using the data this issue came up.

Example data from the collector_tstamp and part of contexts (because there’s a lot in there):

  • collector_tstamp: 2019-12-16 13:53:40
  • part of contexts: …“sessionId”:“bfc1ede0-1b28-4bc5-a574-98f716e0ff99”,“userId”:“41cf4536-3a99-428d-9c14-2f1e929c53a1”,“sessionIndex”:303,…
  • collector_tstamp: 2019-12-16 13:53:41
  • part of contexts: …“sessionId”:“38b5b260-da97-49a9-b1ae-9c98c18daed0”,“userId”:“41cf4536-3a99-428d-9c14-2f1e929c53a1”,“sessionIndex”:306…

We doublechecked if other timestamps could say something different but they all say roughly the same.

We’ve set the fore- and background timeout to both 1800 seconds, to make sure timeout’s only happen after 30 minutes of inactivity, but this does not seem to have large effect. We also tried changing it to 18000 to doublecheck if we were dealing with milliseconds, but nothing significantly changed here.

I’m currently working on defining the sessions from SQL side as temporary fix, but ideally we would not have to do this. Does anyone have a suggestion we can try from the app code’s perspective?

Versions:
Swift 5, iOS 13.2.3, Snowplow 1.1.5 ( we updated from 1.0.4 to see if we could fix the issue with that, but that proved to not have any effect)

2

Hi,

Thanks for getting in contact with us.
The behaviour you reported is weird, there are few reasons that can cause a reset of the session context:

  • Crash of the app, or force restart. The session index doesn’t change if the user just switch or put the app in background.
  • Multiple calls of setSessionContext with different settings.
  • Multiple instances of the tracker running concurrently.

You reported the collector_tstamp that is the timestamp set in the collector. Events could have been hours apart but sent together on re-connecting.

As you said…

Consider that the dtm is the timestamp set by the device and it can explain the gap of a couple of seconds you initially reported.
If the gap between the session index changes is bigger than few seconds (considering the dtm) it could explain the weird behaviour as caused by app crashes or restart.
A good proof is to check if the a new session index is sent by events sent usually on app start up.

I hope it can be helpful, but let us know further details in case it’s not.

1 Like
3

Hi Alex,

Thanks for your reply.

This got us thinking that the IOS app initializes the snowplow tracker with every new screen. We checked with the Android dev’s (where snowplow does work correctly) and they only initialize once and then reference the global class when using it. This therefore seems like a likely suspect.

We’re going to try and test this hopefully this week, will update here on how it worked out.

4

The above indeed turned out to be the solution to the problem! Thanks @Alex_Benini for helping us out!

1 Like