@atom-box isn't it a custom dimension at the action level?

We have the exact same requirement in my company. We have very complex products and SKU is not enough to track properly them. We absolutely need to have more custom dimensions that we could use to build finer reports.
Action or Visit scope is definitively not enough

@gorfo66 thank you but could you give a use case example? because in Matomo you can extend the number of custom dimensions at the action level. For example 50. How does custom dimension at the action level would differ from defining it at the product level?
Without this, I guess that we cannot visualize the final result.

@gorfo66 thank you but could you give a use case example? because in Matomo you can extend the number of custom dimensions at the action level. For example 50. How does custom dimension at the action level would differ from defining it at the product level? Without this, I guess that we cannot visualize the final result.

Unless I'm wrong, Action variables are defined from the URL of the browser. I don't understand how we could apply this approach to the product scope.

We are building ticket retailing applications. We are already massively using product SKU in order to aggregate some info, but we need more flexibility to be able to capture things like advance purchase, date, time, type of ticket, rows, etc.

I can see that we are not the only ones to request such a flexibility.
This is something that is really blocking us from getting out of Google analytics.

@gorfo66 thank you for the details. In fact, custom dimensions at the action level are defined for the action, so it can be linked to any actions: url, event, form, search etc. I didn't test it, but to me, an order is an action, so you can defined your custom dimension to it.
In GA, you don't have this concept of action, Matomo has, so my guess here, you can achieve what you expect here, date is a custom dimension at the action level, type of ticket same thing etc.

@gorfo66 thank you for the details. In fact, custom dimensions at the action level are defined for the action, so it can be linked to any actions: url, event, form, search etc. I didn't test it, but to me, an order is an action, so you can defined your custom dimension to it. In GA, you don't have this concept of action, Matomo has, so my guess here, you can achieve what you expect here, date is a custom dimension at the action level, type of ticket same thing etc.

GA4 is event based. The concept of action is the foundation of their new system. Everything is action because everything is event.

One order contains several products and for each product could have various values for the same dimension.

I'm really not convinced by the concept of dimension at action level for this specific usecase.
It would be a hacky workaround and not a sustainable solution.

Ah, we may are reaching a point here "various values for the same dimension", do you mean multiple values for the same dimension?
Like, coupon code dimension could store multiple values "AUTUMNSALES, VIPPERSON" am I correct? (so to say a list of values.

Ah, we may are reaching a point here "various values for the same dimension", do you mean multiple values for the same dimension? Like, coupon code dimension could store multiple values "AUTUMNSALES, VIPPERSON" am I correct? (so to say a list of values.

Think about product dimension as the brand.
You can purchase at the same time a t-shirt Nike and shoes Adidas.
At the end end of the day, you will want to build reports regarding how many Nike products were purchased.
Ok, you can merge all that into the product SKU (and this is what we are doing to some extends) but this merge approach has some limits.

Ah, I am starting to see it, an order is an action, but an order can have multiple items within it, and items are not action based.
So that's why one would need custom dimensions at the item level am I right @gorfo66 ?

Ah, I am starting to see it, an order is an action, but an order can have multiple items within it, and items are not action based. So that's why one would need custom dimensions at the item level am I right @gorfo66 ?

Yes exactly.

Perfect, legitimate ticket for sure.

I got another understanding of this feature today.
In fact when an order is placed within Matomo, the purchase is an action, BUT, an order can include several products, for example, two t-shirts of different colors (one is white the other is black).
Here, one would need to create a custom dimension at the product level, named color, otherwise it is impossible to track it.

Hello team, thanks for the discussion on the issue and for the suggestion of custom dimensions at product level. I'm relatively new to Matomo myself, but I was wondering whether MTM DataLayer could be the solution here? https://developer.matomo.org/guides/tagmanager/datalayer
My understanding of the mechanism is that you can submit the order data this way to your events in MTM. What I'm not sure and can't see in the documentation is whether this mechanism supports arrays of data, not just scalar variables.

@michalkleiner hi,

no it does not. A product is neither a visit nor an interaction, it is something else.

It would be great to get an understanding from the community how many extra dimensions would be needed to solve this problem. For example, is 5 enough, 7, 10, 15, ...?
Obviously the amount will be different for different users, but it'd be good to know that 90% of customers would be helped by having x custom dimensions.

Alternatively, we could perhaps have a look at allowing people to add as many new custom dimensions as they want.
Note: I imagine this could have implications on performance, in which case we'd potentially not want to make it extremely easy in the UI to add a large number of new custom dimensions.

Generally speaking, between 5 and 10 custom dimensions may suffice. However, for sectors heavily reliant on product configurations (such as travel, or businesses based on product rentals with multiple options), this number may sometimes need to be higher.

Furthermore, would it be possible to have an estimate of the timing associated with the deployment of this feature? This would help me determine if I need to find workaround solutions in the coming months

Thanks for the info @David-sfx , this is helpful for future planning and implementation. Our development team is working on a number of other scheduled features at the moment, so we're unlikely to pick up this request in the short term. However we always appreciate community participation and if someone were to submit a pull request then this feature could be made available a lot sooner.