hey there, Matt! Thanks for posting.
The short answer is - while you can do this - we don't recommend it. In accordance with our spec - we encourage customers to pass individual key-value pairs for each trait.
With regards to passing nested traits or properties (be they in arrays or nested objects) - the downstream behavior depends on your use-case and on each individual destination.
In Segment's case - when we ingest nested properties or objects - we will flatten and stringify them for the purposes of our internal logs (your raw data) and, depending on the warehouse destination you may have connected, try our best to load them into a given warehouse column. Here's an excerpt from our destination documentation concerning Redshift:
Note: If you send us an array, we will stringify it in Redshift. That way you don’t end up having to pollute your events. It won’t work perfectly if you have a lot of array elements but should work decently to store and query those. We also flatten nested objects.
Outside warehouses, when sending data downstream to a given destination - the outcome depends on how that individual destination treats such properties. Heap, for example, does not accept them. The same goes for Braze, CleverTap and many others. Conversely - the Sherlock destination accepts nested objects but not nested arrays.
To sum up - I would highly encourage reading through our spec, and implementing your Segment tracking calls with best practices in mind. If your business use case must rely on nesting traits or objects, and you can't code around that, I would experiment and run some tests in a sandbox environment to see how these calls behave. Be sure to read up on destination documentation for the individual destinations you intend to pass this data shape to.
I hope this helps! Please let us know - or if you have more granular questions, or ones specific to your account or implementation - feel free to submit a support ticket here.Reply