Explore optionality for certain fields in contexts

[bogaert]

Was: Make sending previous session ID optional

Some users have concerns about request size and would like to disable this field.

[jbeemster]

So the previousSessionId is a required field of the client_session context. This means that we would have to do a JsonSchema + Redshift DDL release to make this optional.

As well this field only adds 36 bytes to the event. Feels like a lot of work for such a small change?

[alexanderdean]

I hear you - @bogaert can you share the average event size for the users who have concerns about request size? I'd like to understand if 36 bytes is material to their event sizes, or if they should be looking for savings elsewhere...

[bogaert]

I agree that it's a lot of work for a small change. I don't think we need to action this particular ticket (given the amount of work), but it might nevertheless be a good thing to keep in mind when we add new fields in the future. Users that are concerned about total request size will keep asking whether it's possible to disable some or all the built-in non-essential fields they don't use, so making them optional might make sense. Thoughts?

[alexanderdean]

Right - I think the main point we need to stress is that users need to balance request size with the number of additional contexts they want to attach to each event. That's the calculus really...

[jbeemster]

There could also be some work around compressing POST requests by either moving duplicated event information to a common space where it can be reconstructed later or by compressing the data into gzip form for example.

[alexanderdean]

Ah yes - we've thought about these ideas before. I think a naive compression algorithm (e.g. gz) would be almost as effective as semantic compression (moving duplicated event information to a common space) - and would require much less work in the enrichment process, so definitely worth considering...

[jbeemster]

Agreed and would result in a lot less work for us I imagine. For Mobile and Web it feels like something we do need to consider.

We also need to understand the concern around large event sizes. On mobile with enough events we could be impacting data caps / overall bandwidth which I imagine could be a big driver behind application install churn.

Perhaps as an addition to this having an option to send only when we have WiFi could be a good option?

[alexanderdean]

Sounds good @jbeemster - can you create tickets in:

• Android Tracker
• Objective-C Tracker
• .NET Tracker
• JavaScript Tracker
• snowplow/snowplow

To explore compression of event payloads?

[bogaert]

That's indeed one of the reasons. iOS (and perhaps Android too) reports mobile data usage per app, so companies have an incentive to reduce data usage.

[AlexBenny]

Closing because it has been with no activity for a long time. Compression of data would be a solution but it seems a very low priority and not high in demand at the moment. Please, feel free to reopen or comment this issue, whether it's of your interest or you want to contribute on this.