The behaviour you describe is by design.
It’s really important that our event streams look the same across the platforms.
I would consider this a requirement of your business logic. The trackers are built to send an unopinonated event stream to the pipeline, which makes no assumptions about the business logic. The data needs to be as exact a representation as possible of what’s being measured for this model to work - this is what atomic data is.
As Rob suggests above, your business logic and assumptions can be built into a data model which runs over atomic data to produce a derived output. If there is ever a question, doubt or change of opinion about the model logic, then you have a log of the atomic data to test those assumptions and recompute the logic if required.
The specific requirement in question here could be done with some simple SQL, for example, using a coalesce statement.
If it is very important to you that the data you send incorporates your assumptions then, you can generate session ids yourself and send them as custom contexts. You can potentially also utilise server-side tracking to achieve something similar.
What would be ideal is if the session sid and vid were set and the above “client_session” context could also be added. “client_session” is quite large and adds quite significantly to the size of the payload.
So, the string you’ve sent over should be less than one kb added to the payload. To date, across all of our users on mobile, that’s not been raised as a problematic amount of data to attach to events. However, we’re aware that there are certain verticals that have specific requirements around minimal payloads, and it’s a topic that’s worth exploring.
Perhaps you can provide a bit more information on your use case and why the payload size is a concern for you? It may well be that we have come across something similar before and can recommend an approach.