Inconsistencies in Visits Report


I am writing to bring to your attention several inconsistencies I have discovered in the visits report of of matomo. The reported number of visits seems to be inaccurate and conflicting across different time periods.

  1. Monthly Visits Discrepancy: The visits report indicates a decrease in the number of visits, suggesting an approximate count of 300,000 visits per month. However, when I directly query the database using the provided SQL statement, it returns a significantly higher count of 1.5 million visits per month. Please refer to the attached screenshots for reference
    You can find the request I made at the end of the post.

  2. Weekly Visits Discrepancy: Furthermore, when examining the same report at the weekly level, it displays an approximate count of 300,000 visits per week. It is illogical for the number of visits per month to match the number of visits per week, indicating a clear discrepancy. Kindly refer to the attached screenshot for reference

Considering these inconsistencies, it appears that there might be a problem in the aggregation calculation that affects the accuracy of the reported visit numbers.

Thank you for your attention to this issue. I look forward to receiving an update on the investigation and a resolution plan to address the inconsistencies in the visits report.

Request used : SELECT
date_format(visit_first_action_time, ‘%Y-%m’),
idsite = 9
and visit_first_action_time >= ‘2023-01-01’
group by
date_format(visit_first_action_time, ‘%Y-%m’);

Hi @Adeline_DEPAEPE
Which Matomo version do you run?
Can you check in the system check (in Matomo admin section):
You can try to invalidate past archived data in order to re-archive them (in case you still have raw data for selected periods):

You ca use the &cascadeDown=1 parameter if possible.

Hello, thank you for your answer.

I have Matomo 4.4.1 >> My team are not very available to update it right now.
I still have raw data

As my team is not very available, do you advice to start by updating matomo or invalidate the historical data?
Maybe is it better to test the invalidation in a specific segment?

More info : The behavior I’ve described happens since last january.

Hi @Adeline_DEPAEPE
I would suggest first you invalidate past historical reports.
Do you know how the data archive is run? (by CRON or by browser request?)

Thanks for the advice.
I see that the invalidation is quite simple.
It is run by cron.

1 Like