I see in the web docs the following description:
By default, self-describing events and custom contexts are encoded into Base64 to ensure that no data is lost or corrupted. You can turn encoding on or off using the
encodeBase64field of the configuration object.
How would it ensure no data is lost or corrupted? Only case i can think of is encoding issues. But then the page field would probably also be affected.
It doesn’t really do much to prevent corruption but as you’ve mentioned it does prevent encoding issues (particularly with GET requests) that can sometimes result in malformed fields.
Yeah, it just seems a bit old school to handle encoding issues on that level.
I would love for the trackers to switch to base64 opt in.
The reason i’m looking into this is that snowplow events are getting heavy (1.5k json in normal scenarios and 5k+ in specific, like media). Removing base64 reduces weight a bit, but also improves compressibility (concluded based on a small test with 20ish events, both for gzip and brotli).