Solved

When shoudl you use flat list of event properties vs object arrays?

  • 12 March 2023
  • 7 replies
  • 1059 views
T
Rank
Userlevel 3
Badge +2

Amplitude supports object arrays as event properties as described here

https://help.amplitude.com/hc/en-us/articles/9623000954907-Cart-analysis-Use-object-arrays-to-drive-behavioral-insights#terms-and-concepts

 

that combined with property splitting seems powerful.  However I’m unclear when it’s best to use this vs a flat list of properties. Is it strictly when you need to represent multiple objects and thus would have repeating of properties forcing you to come up with creative naming to avoid collisions?

in our case, say you only even have one subscription plan in a purchase.  Each plan say has a name, term length and price. Also given customers can change plans, we’d want to know the previous plan they are coming from. 
 

is it just better to model event properties like:

Event: Plan Purchased

  • plan_name: silver
  • plan_price: 19.99
  • plan_months: 1
  • plan_name_previous: gold

or is it better to do:

Event: Plan Purchased

  • plan: { [ name: “silver”, price: 19.99, months: 1 ] }
  • plan_name_previous: gold

I assume the first way is best because it’s less complex and the object array is unnecessary since there’s only ever one plan purchased. 
 

I was surprised not to find more specific advice in the help center. So hoping someone here has advice. 

icon

Best answer by dangrainger 13 March 2023, 11:13

View original

7 replies

dangrainger
Rank
Userlevel 5
Badge +9

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.

T
Rank
Userlevel 3
Badge +2

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: [{
        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: [{
        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?

T
Rank
Userlevel 3
Badge +2

@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.

 

dangrainger
Rank
Userlevel 5
Badge +9

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.

T
Rank
Userlevel 3
Badge +2

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

dangrainger
Rank
Userlevel 5
Badge +9

You could put that to Amplitude as a feature request…

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

T
Rank
Userlevel 3
Badge +2

You could put that to Amplitude as a feature request…

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

Way ahead of you 😉

Reply


Terms & ConditionsCookie settings