Core: add in-client sessionization

[alexanderdean]

This ticket should track the implementation done here: snowplow/snowplow-ios-tracker#83

[n-belokopytov]

@alexanderdean will there ever be a way of setting a session index on Android?

[alexanderdean]

Hi @n-belokopytov - yes it will be done, not yet scheduled however.

[alexanderdean]

Depends on snowplow/iglu-central#180

[jbeemster]

Hey @alexanderdean so just to make sure I understand what needs to be done here. We want a custom context included with each event that includes the userId, a session id, the previous session id and the session index.

The session should be created along with Tracker creation and the session should be incremented at a configurable timed interval after an event: so if an event has not been sent in say 15 minutes update the session.

I also presume that the userId in the session needs to match the userId currently in the Subject; should we then only make a session if the userId has already been set in the Subject so there is something to match against?

[alexanderdean]

Hey Josh, that's a good summary:

We want a custom context included with each event that includes the userId, a session id, the previous session id and the session index.

Yes, pending confirmation from @yalisassoon and @bogaert on the exact fields.

The session should be created along with Tracker creation and the session should be incremented at a configurable timed interval after an event: so if an event has not been sent in say 15 minutes update the session.

Correct, although if you look at the sister iOS ticket, session termination will likely also include something around application backgrounding/foregrounding.

I also presume that the userId in the session needs to match the userId currently in the Subject

No, these are orthogonal. The userId in the Subject is developer-created, whereas this userId is automatically generated by the tracker. The userId in the session is meant to be equivalent to the JS Tracker's domainUserId.

[jbeemster]

Okay cool! So the UserId should be created once per Tracker creation for X amount of sessions?

[alexanderdean]

Yes the userId should be common across all sessions, same as the domainUserId.

[jbeemster]

No worries, and with the backgrounding/foregrounding; should that be an instant new session if the app is brought back into focus or is there a timer for that as well?

[alexanderdean]

I think that should be time based too...

[yalisassoon]

Sorry - only just seen this ticket so apologies for not jumping in earlier.

In terms of the fields we want to generate and capture, having the session
ID is great. Having the previous session ID is a bonus.

What's the user ID in this context? Is it a new ID that we're generating?
Is it one of the device IDs that is currently captured in the
mobile_context?

On Tue, Jul 7, 2015 at 3:45 PM, Alexander Dean [email protected]
wrote:

I think that should be time based too...

—
Reply to this email directly or view it on GitHub
#37 (comment)
.

Co-founder
Snowplow Analytics http://snowplowanalytics.com/
The Roma Building, 32-38 Scrutton Street, London EC2A 4RQ, United Kingdom
+44 (0)203 589 6116
+44 7841 954 117
@yalisassoon https://twitter.com/yalisassoon
https://twitter.com/yalisassoon

[alexanderdean]

For the mobile trackers, the userId is a new synthetic ID completely owned
by the tracker and with the exact same storage characteristics as the
session vars. So it should be fairly easy to reason about.

When the JS Tracker starts using this context, this userId will be
populated by current duid...
On 10 Jul 2015 9:07 am, "Yali" [email protected] wrote:

Sorry - only just seen this ticket so apologies for not jumping in earlier.

In terms of the fields we want to generate and capture, having the session
ID is great. Having the previous session ID is a bonus.

What's the user ID in this context? Is it a new ID that we're generating?
Is it one of the device IDs that is currently captured in the
mobile_context?

On Tue, Jul 7, 2015 at 3:45 PM, Alexander Dean [email protected]
wrote:

I think that should be time based too...

—
Reply to this email directly or view it on GitHub
<
#37 (comment)

.

Co-founder
Snowplow Analytics http://snowplowanalytics.com/
The Roma Building, 32-38 Scrutton Street, London EC2A 4RQ, United Kingdom
+44 (0)203 589 6116
+44 7841 954 117
@yalisassoon https://twitter.com/yalisassoon
https://twitter.com/yalisassoon

—
Reply to this email directly or view it on GitHub
#37 (comment)
.

[yalisassoon]

That's really cool. From a data modeling perspective it'll be nice having a single user ID field, generated by different Snowplow trackers that can be used for off-the-shelf queries.

[bogaert]

Agreed. This will make it much easier to have a single model that does both web and mobile.

[alexanderdean]

Great!

[jbeemster]

With the userId.. should this be persistent for the life of the application being installed on a device? Currently if the user were to close the app and re-open it there would be a new userId for any session contexts sent from that device. Not sure if this is something we want but I think it could be nice to stitch user sessions across multiple open and closes of an app?

[alexanderdean]

Hey @jbeemster - yes definitely, the userId should persist as long as is possible (i.e. forever barring app uninstall or other storage deletion), certainly across app restarts...

[jbeemster]

Okay I will figure out a way to add in some level of persistent storage linked to the application.

[alexanderdean]

We have persistent storage for the event queue already no?

[jbeemster]

We do yes. But potentially a DB table is a bit of overkill for a few kV pairs. I am instead going to store it as a file in the internal storage. This gets wiped if you uninstall the app. Should do the trick!

[alexanderdean]

Sounds good @jbeemster !