Manually set the session_id

[colmsnowplow]

The tracker already supports manually setting the domain_userid - in a similar fashion it would be useful to be able to manually set the session_id.

This would make for a smoother process in projects that require both client and server-side tracking.

[alexanderdean]

Interesting idea colmsnowplow. Integrating client- and server-side sessions feels quite tricky but powerful if we can get it right...

[colmsnowplow]

Definitely. We already have the means to pass that information to the server-side via the getDomainUserInfo method, so if it was straightforward to have client-side tracking populate this cell in atomic.events then we'd take the heavy lifting out of data modeling.

[alexanderdean]

Can you ASCII-art out the dataflow you are imagining colmsnowplow? I am having trouble pinning it down...

[colmsnowplow]

I can certainly try - I'm also open to suggestions on how it could be done, but here's what I had in mind.

Let's imagine a use case where someone wants to track an account creation event server-side, as there's information associated with creating an account that isn't available client-side. Lets say they want a form submit event client-side, then an account create event server side.

They would pass the domain_userid and domain_sessionid to the server-side, then pass that to the Java tracker to populate these values for the account create event:

[js-tracker creates cookie] -- [form submit event]
                            -- [getDomainUserInfo + piece of code that sends this info server-side]
                                                                       ||
                                                                       ||
                                                     [Java tracker setDomainUserid/setSessionId method sets the relevant values] -- [account create event]

What I'm imagining is that the account create event shares a domain_sessionid with the form submit event.

If the setSessionId method sets the domain_sessionid for the server-side event, we don't need any SQL voodoo to model the create account event into our session-level analysis.

This might be a naive picture of what's possible though - are there issues I'm not seeing?

Having written it down one I can think of is that there are likeyl to be server-side events for which we don't want this value set - I don't know if it's possible to set this value within the actual track method for one event only, as opposed to within the subject?

[alexanderdean]

I think there are two options:

1. Generate the session ID server-side and render it out client-side for the JS Tracker to use
2. Generate the session ID client-side but use cookies to make it available in the back-end (via the HTTP request headers)

I haven't thought these through much further yet...

[colmsnowplow]

From where I stand, my opinion would be option 2), for two reasons:

1. Most implementation start by trying to measure user-behaviour and deliver benefit in the short term, rather than planning an integrated setup up-front. This is likely to begin with client-side tracking, and server-side is likely to be considered after that.

So in terms of pragmatics, it makes sense to send the client-side session ID to the server side.

2. This one's a little more high-level and potentially up for dispute, but I'm of the opinion that a good measurement is as simple and direct as possible - so if you're measuring a user interaction, you should measure it at the point that the user interacts, where possible. If you subscribe to this stance, it follows that any 'second level' (struggling for the right term here) information you take, like the session ID, should also be as close to the interaction as possible.

I am biased on this, but for me there's a good argument for a 'client-side first' approach, where possible.

[alexanderdean]

Makes sense. I don't think option 1 is particularly feasible anyway - as the session calculation logic isn't easily "shippable" to the server-side.

Option 2 is quite interesting and even exciting. It's inspired by:

https://github.com/simplybusiness/snowplow_ruby_duid/

[alexanderdean]

I think we are against manual overrides, closing.