I created a custom report to track the conversion rate for three goals. Everything looks good, except that if I view by week, conversion rates show zero for all weeks that spans two months (e.g. 24 Feb - 01 Mar, or 30 Dec - 05 Feb). If I change the report to show the days in question (day report for 01 Mar), all days in that week show a positive conversion rate.
So I wonder if there’s a math error somewhere in the report.
A similar report showing conversions (numbers rather than rates) seems to calculate correctly over the same periods. (Well, non-zero, at least. )
I hadn’t noticed it, but there are a couple CLI errors appearing one the “About Matomo” page:
WARNING: /var/www/matomo.example.com/piwik/core/Piwik.php(138): Notice - A non well formed numeric value encountered - Matomo 3.13.4 - Please report this message in the Matomo forums: https://forum.matomo.org (please do a search first as it might have been reported already) (Module: CustomReports, Action: getCustomReport, In CLI mode: false)
We’re having the exact same issue. Using 3.13.5 and 3.1.26. It only affects reports created within the last few months as older reports don’t show this behavior. Have tried invalidating reports on all affected sites with affected reports.
We also had this issue recently. After deleting (invalidating was not enough) the month/year archives and reprocessing, everything was correct again. Since it’s a production environment, I didn’t experiment further with it. This issue is a bit frustrating, because a lot of departments receive the reports and get back to the analysts with plausibility concerns. That should not happen (too often) because it destroys trust in the reported numbers.
We were running the (undocumented) console command customreport:archive (to process the reports for the past x days). I suspect that this breaks the archives somehow and overwrites existing reports with wrong calculations. In our case, goals were reported with 0, as well. This was obviously wrong, because when checked with a simple segmentation, goals were reported correctly for the same timeframe (segmentation is calculcated on the fly based on raw data).
Did you use the customreports:archive command as well?
We still see it occurring and invalidating (as you mentioned) doesn’t fix the issue. We haven’t run the customreports:archive command on affected data/archives but have run it in the past. We have never been able to get it to calculate anything but zeros for goals but I believe that’s because it isn’t fully implemented yet. We’d love to be able to run customreports:archive commands to repopulate a new report vs. having to fully invalidate things, but most of our custom reports contain goal calcs.
Hopefully there will be a fix for this soon or some movement as it wouldn’t be an option for us to delete the affected archives as our prod environment is multi-client and traffic is too high/processing time to recover would be too long. Out of curiosity, how large was a month and your January archive (roughly) that you deleted?
We installed the update and invalidated the reports for the affected weeks and the archive process is still running (after 2 days on a high traffic site). Consequently, the archiver isn’t processing new visits to reports and we get a message that a new archive command stops because the site/period is already in progress. Is there a way to manually (through query) to set an invalidated archive to “done” so that we can invalidate again in smaller date chunks so as not to impact go forward reporting? Or if not, will it eventually “catch up”? Thanks.
)