Is _sp_id cookie a valid alternative to the client_session context?

For engineers Enrichment
1

Hi everybody,

Questions regarding the client_session context for the browser tracker:

We want to avoid redundant information in the payload to keep the request size low. Almost all properties from the client_session context are already covered in the _sp_id cookie (or the respective custom cookie name + domain hash):

{domainUserId}.{createdTime}.{visitCount}.{nowTime}.{lastVisitTime}.{sessionId}.{previousSessionId}.{firstEventId}.{firstEventTsInMs}.{eventIndex}

Therefore my idea was to use the _sp_id cookie in the Cookie Enrichment and parse the information e.g. via JS enrichment or in the data model. The obvious downside is, that it would only work for storageMechanism: COOKIE_1, but in our case the amount of sessions without cookie support (br_cookies = false) is low.

According to a first test it works and the cookie is already present on the very first event of a session. Am I missing something or is the mentioned approach with the Cookie Enrichment a valid solution ?

Thanks for your feedback.
David

2

@davidher_mann,

We want to avoid redundant information in the payload to keep the request size low.

The client_session is optional for the Javascript tracker. When it is on, it will be added as a context (entity) to each event. You can turn it of. You can read about the correlation between the values of the client-side cookie and client_session entity in this document.

Mind you, there is a difference in the values captured in client_session when it comes to a mobile application. You can read more about it in User and session identification.

Therefore my idea was to use the _sp_id cookie in the Cookie Enrichment and parse the information e.g. via JS enrichment or in the data model.

Why use Cookie and JavaScript Enrichments for this cookie if the cookie values are captured regardless as atomic values (not all though if client_session is not enabled, see “Mapping Values to Tracker Protocol” section)? Enabling these enrichments would add the redundancy you are trying to avoid. It also adds an extra processing need to the pipeline. The final outcome will be the same.

Does the size of the HTTP request payload really that much affected with client_session on? even with encodeBase64 set to true?

3

To @davidher_mann’s point, the client_session context entity does contain more information than would be otherwise tracked in the atomic event properties (such as the previous session ID, first event ID, first event timestamp and event index).

If the goal is reduce the size of the payload, I think it’s a valid solution to parse this cookie in the enrichment and produce the client_session context entity there. I don’t see any problems with that (only in some edge cases where you have multiple trackers on the page or on other subdomains, make sure that you are parsing the correct _sp_id cookie).

1 Like
4

Thanks for your feedback @matus and thanks @ihor for pointing me to the docs, as always RTFM :wink:

Important downside of the client_session context I just came across in the docs is, that “Anonymous tracking has to be disabled for the session context entities to be added to events”.

Depending how anonymous tracking is configured, the _sp_id cookie is present if anonymous is enabled so capturing e.g. the eventIndex would be possible for anonymous sessions which the _sp_id cookie enrichment approach.

@matus When I took a closer look at the topic, I came across the following “bug”:

Tracker setup:

      // anonymizes the network user id and the domain user id but strill tracks the session
      anonymousTracking: {
        withServerAnonymisation: true,
        withSessionTracking: true
      }

Data collection without domain_userid and network_userid works as expected, but according to my test the previousSessionId is written into the cookie, although withServerAnonymisation and withSessionTracking are true. That should not be the case from my perspective. Here is why:

Technically, the _sp_id cookie is part of the request and therefore the previousSessionId as well. IMO the whole point of anonymous tracking with activated domain_sessionId is, that there is no way to stich multiple session from the same user/client together. Technically that would be possible in case the _sp_id cookie is used in an cookie enrichment.

So I think it would make sense not to set the previousSessionId in case of activated anonymous tracking. Curious about your thoughts…

5

Agreed! The previousSessionId reference can be used to reconstruct the user journey and thus should not be tracked if anonymous user tracking is enabled. In our mobile trackers, we omit the previousSessionId reference from the client_session entity in case anonymous tracking is enabled. We should also not set it in the JS tracker cookies.

I have created an issue for us to address this. Thanks for reporting this @davidher_mann!

1 Like