@anonymous-piwik-user opened this Issue on January 14th 2014

I use this pattern.

?module=API&method=Goals.getItemsName 
&idSite=1 
&period=day 
&date=today 
&format=JSON 
&token_auth=xxxxxx 
&segment=ProductCategory==electronic 

See the bold text, I try to use the segment to filter ProductCategory in ecomerce but fail.

Thanks a lot.
Keywords: ecommerce

@uacode commented on November 19th 2014

Bump

@hpvd commented on November 5th 2015

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

@hpvd commented on November 5th 2015

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

@mattab commented on December 23rd 2015 Member

While implementing segmentation by Product category we should also implement:

  • Segment by Product Category,
  • Segment by Product name,
  • Segment by Product SKU,
  • Segment by Product prices
  • segment 'ecommerceOrderId' to select a particular Ecommerce Order ID #9981

See also: https://github.com/piwik/piwik/issues/9175

@hpvd commented on February 11th 2016

same data should be also accessible for goal definition, see https://github.com/piwik/piwik/issues/9756

@mattab commented on March 31st 2016 Member

@hpvd suggested in #9756 that it could look like this:

2016-02-11_15h32_55

@Facens commented on May 3rd 2016

+1

@Facens commented on May 3rd 2016

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

@hpvd commented on May 3rd 2016

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 https://github.com/piwik/piwik/issues/6177

@hpvd commented on May 3rd 2016

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

@Facens commented on May 3rd 2016

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

@hpvd commented on July 15th 2016

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:
https://github.com/piwik/piwik/issues/8920#issuecomment-182489873

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???

@mattab commented on July 18th 2016 Member

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.

@mattab commented on September 6th 2016 Member

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! :+1:

@s1awa commented on February 6th 2017

Opened this issue on Jan 14, 2014

Happy birthday! This feature request is 3 years old.

@laszlovl commented on October 3rd 2018

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? :)

@tsteur commented on October 3rd 2018 Member

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.

@laszlovl commented on October 23rd 2018

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.

Powered by GitHub Issue Mirror