New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
E-Commerce Reports should not aggregate data to "-1" #3116
Comments
Attachment: piwik csv export example data |
In your example, you created 102 tracker objects, with 101 instances each trying to send an asynchronous request to the server. Due to request pipelining, the browser may restrict the number of concurrent requests causing some to be queued up, others to timeout, etc. Also, if your server is processing concurrent requests for the same visitor, there may be race conditions when aggregating because the scripts run in separate threads of execution. So, try making only 1 call to:
|
Thanks for your response. The code was just an example. We can see this aggregation to "-1" in our production environment as well when using the Piwik tracker as intended. I'm also sending the requests and then viewing it in the UI (e.g. one hour later) so I don't think the behaviour is related to a race condition. It's also correct that the requests are sent asynchronously according to the database, but when viewing their data in UI they are aggregated and ordered - everything from id_book1 to id_book51 is visible, everything afterwards and in between missing. IMO something should be changed. I don't know how aggregation is intended to work but at least ecommerce data should not be aggregated by alphabet. We are missing bad performing products. I was really surprised that "datatable_archiving_maximum_rows_subtable_referers" helped me out (no documentation on the website) but I don't know anything about its side-effects. |
Thanks for the report. The fact that ecommerce data are truncated and that datatable_archiving_maximum_rows_subtable_referers works (which as you point out is "surprising") is because of the implementation: ecommerce uses Custom Variables report to get the number of views on ecommerce product pages. Therefore we will never truncate ecommerce products which have sold at least once, however we will truncate products which were seen but not bought. Still we can make things better:
|
@matt, I think it might be possible to increase the limit for ecommerce-specific reports, but it would take a while for me to figure out what the code is doing. |
…riables reports to 1,000 rows. Limit to 50,000 instead.
We are using the ecommerce feature of Piwik for our websites and have noticed that items are aggregated to "-1". This occurs in both UI and API for "Product SKU" and "Product Name" reports.
This piece of code simulates just some product views and a purchase so that the ecommerce report shows up in the UI:
The data attached in the CSV has been generated using the code above. As you can see, some product views are missing, e.g. everything after id_book52 as well as id_book6 to id_book9. The information itself is correctly in the database.
The huge negative impact of this aggregation is not visible: There are 10 visits in sum to id_book60, but it also aggregates to "-1" and does not show up in the report. So you cannot see products which are converting bad if you have a lot of products in your store.
If the config value "datatable_archiving_maximum_rows_subtable_referers" is set higher than 50, data is no longer aggregated and we see all product views correctly. However I assume raising this value might affect the UI in other views in a negative way.
Would it be possible to implement one of the following options?
Keywords: ecommerce, aggregation, -1
The text was updated successfully, but these errors were encountered: