Bump

yes this would be really helpful, to have the ecommerce product catgeorie in segment editor, since one can not always use elements from url to identify product's category because in some systems like Magento there are several urls for same product:

• domain.com/product.html
• domain.com/category1/product.html
• domain.com/catalog/product/view/id/1/
• domain.com/catalog/product/view/id/1/category/1/

but with this code one could set "category 1" directly to the product
no matter which url is used to show it:

// all parameters are optional, but we recommend to set at minimum productSKU and productName
_paq.push(['setEcommerceView',
"9780786706211", // (required) SKU: Product unique identifier
"Endurance: Shackleton's Incredible Voyage", // (optional) Product name
"Adventure Books", // (optional) Product category, or array of up to 5 categories
20.11 // (optional) Product Price as displayed on the page
]);
_paq.push(['trackPageView']);
[...]
source:
https://piwik.org/docs/ecommerce-analytics/

e.g. standard piwik-magento connection
http://www.magentocommerce.com/magento-connect/piwik-ecommerce.html
already includes this code

just opened a more general version of this ticket:
segment editor: make segments from direct values of ecommerce tracking #9172

While implementing segmentation by Product category we should also implement:

New segments to add ideally

• Segment by Product Category,
• Segment by Product name,
• Segment by Product SKU,
• Segment by Product prices
• Abandoned a cart Yes/No
• Ordered Yes/No

See also:

• segment editor: make ecommerce actions acessible #9175
• segment 'ecommerceOrderId' to select a particular Ecommerce Order ID New segment 'ecommerceOrderId' to select a particular Ecommerce Order ID #9981

same data should be also accessible for goal definition, see #9756

+1

@mattab Is there a way to speed this one up. I was blown away when I realized this is not already a feature, I had given it for granted. Maybe we could sponsor it? Where should I get in touch at?

Hi @Facens

good to see you are also very interested in ecommerce + piwik :-)

If you want to get a fast overview, just have a look in this one which gives a kind of summary of current state:
Better ecommerce reporting in Piwik #6177

@Facens maybe you can help on dicussion and voting for it...

@hpvd Actually we're a SaaS, so we're dealing with a whole range of different tracking needs (e.g. renewals), which piwik doesn't have a place for. I think that piwik should have more attention toward that segment of piwik users who are running a business (e-commerce and SaaS in particular), as these are the customers more likely to opt for a piwik pro subscription or to fund piwik in general (cc @mattab). Since we're going out of topic, though, I would just be happy to understand if there is a way for our company to speed up development of this feature, which seems honestly basic compared to the whole refactor of E-commerce tracking, and not finding it was a bad surprise.

I think that piwik should have more attention toward that segment of piwik users who are running a business (e-commerce and SaaS in particular), as these are the customers more likely to opt for a piwik pro subscription or to fund piwik in general

yes, we think the same way - would be good chance for piwik.
see my comment:
#8920 (comment)

sadly ecommerce seems not to be on the goals list at all:
https://piwik.org/roadmap/

although when filtering issues by "ecommerce" there are - 75 open issues - from 18 different authors..

hmm what to do when liking piwik but working in ecommerce???

what to do when liking piwik but working in ecommerce???

Agreed @hpvd - Piwik is used a lot by Ecommerce websites and we could make many improvements to Ecommerce tracking and reporting in general. If any of you has resources to sponsor or improve Piwik ecommerce reporting, please get in touch with the team at http://piwik.org/contact/ - some team members will be able to improve / develop new Piwik ecommerce capabilities.

Is there a way to speed this one up. I was blown away when I realized this is not already a feature, I had given it for granted. Maybe we could sponsor it? Where should I get in touch at?

@Facens the team of core Piwik engineers have just launched our Custom Development services. Contact us here: https://piwik.org/development/ - we certainly would be happy to work on this feature and release it in the Piwik open platform! 👍

Opened this issue on Jan 14, 2014

Happy birthday! This feature request is 3 years old.

I've been looking into this. A few basic changes seem to expose product name & SKU in the segment editor:

diff --git a/core/Tracker/TableLogAction.php b/core/Tracker/TableLogAction.php
index 96dace6..275ca42 100644
--- a/core/Tracker/TableLogAction.php
+++ b/core/Tracker/TableLogAction.php
@@ -225,6 +225,8 @@ class TableLogAction
             'contentTarget'      => Action::TYPE_CONTENT_TARGET,
             'contentName'        => Action::TYPE_CONTENT_NAME,
             'contentInteraction' => Action::TYPE_CONTENT_INTERACTION,
+            'productSku'         => Action::TYPE_ECOMMERCE_ITEM_SKU,
+            'productName'        => Action::TYPE_ECOMMERCE_ITEM_NAME
         );
 
         if (!empty($exactMatch[$segmentName])) {
diff --git a/plugins/Ecommerce/Columns/ProductName.php b/plugins/Ecommerce/Columns/ProductName.php
index ab7033a..09874c8 100644
--- a/plugins/Ecommerce/Columns/ProductName.php
+++ b/plugins/Ecommerce/Columns/ProductName.php
@@ -22,6 +22,9 @@ class ProductName extends Dimension
     protected $namePlural = 'Goals_ProductNames';
     protected $category = 'Goals_Ecommerce';
 
+    protected $segmentName = 'productName';
+    protected $sqlFilter = '\\Piwik\\Tracker\\TableLogAction::getIdActionFromSegment';
+
     public function getDbColumnJoin()
     {
         return new ActionNameJoin();
diff --git a/plugins/Ecommerce/Columns/ProductSku.php b/plugins/Ecommerce/Columns/ProductSku.php
index 2bd97b4..43c28c1 100644
--- a/plugins/Ecommerce/Columns/ProductSku.php
+++ b/plugins/Ecommerce/Columns/ProductSku.php
@@ -22,6 +22,9 @@ class ProductSku extends Dimension
     protected $namePlural = 'Goals_ProductSKUs';
     protected $category = 'Goals_Ecommerce';
 
+    protected $segmentName = 'productSku';
+    protected $sqlFilter = '\\Piwik\\Tracker\\TableLogAction::getIdActionFromSegment';
+
     public function getDbColumnJoin()
     {
         return new ActionNameJoin();
~

I'm using this right now and everything appears to be functioning properly. Am I missing something or is it really this simple and should I send a merge request? :)

In theory the segment definition is that easy. However, I wouldn't be surprised that if there were multiple products purchased, or the same product appears multiple times in the cart, that it would count some metrics multiple times depending on which report you view. This would need to be checked and likely it would need some adjustments in the LogQueryBuilder etc.

Fair enough. For me the "default" implementation works just fine, but I don't know about all possible reports that this would affect.

As far as I can see, in almost all cases there's no real ambiguity. The segment acts as a filter and will select all actions or visits where the user ordered at least one of the selected product name/SKU. The report behavior shouldn't be different from any other action-level segment; especially since almost data for the order's "first item" and the order's "second item" will be identical.

Where it gets more complicated is reports about order quantity or revenue. Say a user places an order with two items: A and B; and you create a segment for product A. One could expect that the "total revenue" will only show the revenue for the segmented product. Instead, the segment behaves like it does everywhere else and selects all orders that contain at least product A, then sums the total revenue for all those orders.

I don't think it's likely that a product name/SKU segment would be used in such a way, because if you want (quantity/revenue) data grouped by product, you can simply use the "Products" report instead. The most likely use case for product segments are referer reports: which sources drove the sales for a specific product? No ambiguity there, so I think this behavior is acceptable if documented properly.

fyi since fixing #11900 in #14761 these segments should be EASY to add since we no longer need to worry about the joins it generates, that group by's might be wrong and therefore may report way too high numbers etc.