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):
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.
We want to avoid redundant information in the payload to keep the request size low.
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.
Does the size of the HTTP request payload really that much affected with client_session on? even with
encodeBase64 set to true?
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
Thanks for your feedback @matus and thanks @ihor for pointing me to the docs, as always RTFM
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”:
// anonymizes the network user id and the domain user id but strill tracks the session
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…
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!