Similar to your other question on event property naming, I’m again seeing this one as an “it depends” answer. Sorry!

I’ve been wiring up this feature a lot in our setup and based on my experience I’m not really seeing a right or wrong here. I don’t know if you’re familiar with Google Analytics and its “Enhanced Ecommerce” feature...object arrays/ splitting in Amplitude are essentially the same as this, albeit better and more flexible. Given we’re migrating from GA, we’ve retained the logic of “data points for our products go in object arrays, otherwise use standard event props”. In practice this means data for product impressions, selections, purchases, etc, needs to be split, and appears in the Amplitude UI as, for example, “{} products”….the squiggly brackets are a nice giveaway to the ens user that this opens up to reveal this nested data.

To further this example we also grab a pile of “page” data from our website, things like domain, path, user agent, etc. We don’t pass these in an object array as when I first started the build of our project, this feature hadn’t been realeased. If I was to restart it to today, there’s no reason I can see that should stop me passing as an object array...I’ll be very happy for someone to tell me there is a downside, I’ve just not come across one yet, hence me saying originally this is an “it depends” answer as to a degree it feels like personal preference, what you think might suit your end users, etc.

Thanks Dan. The key question is indeed “what is the downside?” of using object arrays.  I think it’s very clear cut when you know there will be multiple objects within it. Otherwise it’s not possible to effectively model is with flat properties.  E.g

products: i{
        product_id: 1,
        name: 'Shirt',
        category: 'Clothing',
        price: 12.60,
      },
      {
        product_id: 99,
        name: 'Soap',
        category: 'Beauty',
        price: 1.99,
      }
]

The question as pointed out in my OP is when you know there will always be only one product/object in the event like

product: e{
        product_id: 1,
        name: 'Shirt',
        category: 'Clothing',
        price: 12.60,
      }
]

That said, I like your point you made:

...appears in the Amplitude UI as, for example, “{} products”….the squiggly brackets are a nice giveaway to the ens user that this opens up to reveal this nested data.

So without any downside, this seems like a great reason to do it.  In other analytics products that don’t support nested properties, I always hated needing to use property naming to assert their relationship. e.g.

        product_id: 1,
product_name: 'Shirt',
product_category: 'Clothing',
product_price: 12.60

While it works, it makes browsing properties a bit of a nightmare. 

Does anyone know of any downside in doing this?

@dangrainger Quick question on this.. what type do you set a property to be if you want it to be an object array?

I assume “array” but then what do you set the item to be?  String?  Definitely not intuitive.

I’ve just left that alone, it defaulted to “Any” as the Type for us. That property will grab the full string of the “plan” object array you create...but when you turn on the splitting it’ll create properties for the nested variables (so probably things like plan.id, plan.name, etc in your case)….it’s these variables where I’ve changed the Types to match the value format passed to them.

Thanks.  It’s so odd you can’t turn on property splitting from the onset and have to wait for data to come in. Since splitting isn’t retroactively applied it makes this to be a timing probkem

You could put that to Amplitude as a feature request…

https://help.amplitude.com/hc/en-us/requests/new

Way ahead of you