I had 2 goals and have deleted it. There are still no goals, but statistic data are published in the Goals Overview. I had it a little bit observed. The database tables log_conversion and goal are yet empty. How can this Goals Overview data be deleted?
Hi @melbao
I think the visit_goal_converted field of the matomo_log_visit table has also to be updated (manually)…
Also, in addition, I think you may:
- invalidate past data where these goals have to be removed
- wait for (or manually launch) the data archiving process…
But you have to be sure you still have raw data of this period…
complicated…
I have startet a manually cronjob in the SSH console like this:
php /path/to/matomo/console core:archive --url=https://matomo.example.com/ > /path/to/logfiles/matomo-archive.log
Yet, the Goals Overview graph is empty, only the little graph below right is not empty:
Evolution over the period: graph empty
[graph empty] - 0 conversions 0%
[graph filled] - 62.17% overall conversion rate (visits with a completed goal) +100%
Hi @melbao
My understanding is that the 1st mini-graph is computed (through data archiving) from goals tables, whereas the 2nd one from the visits tables («visits with a completed goal» → based on visits).
I think the same and have read it in the past somewhere. The big visits table has many columns and in one column are goal data saved and not removed by deleting a goal. This data must be perhabs manually deleted, when this is needed.
In my case, it’s more about the size of the database and less about the data. So the question is whether deleting the goal data in the visit table makes the database smaller or possibly larger if instead of a value a NULL or similar is entered.
Yet, i have startet this:
php /path/to/matomo/console core:invalidate-report-data --dates=2017-01-01,2020-12-31 --sites=11 > /path/to/logfiles/matomo-invalidate-report-data.log
the log looks like no data is touched?
e[32mINFO [2023-04-19 13:16:55] 93734 e[39m Invalidating day periods in 2017-01-01,2020-12-31 [segment = ]...
e[32mINFO [2023-04-19 13:17:00] 93734 e[39m Invalidating week periods in 2017-01-01,2020-12-31 [segment = ]...
e[32mINFO [2023-04-19 13:17:00] 93734 e[39m Invalidating month periods in 2017-01-01,2020-12-31 [segment = ]...
e[32mINFO [2023-04-19 13:17:00] 93734 e[39m Invalidating year periods in 2017-01-01,2020-12-31 [segment = ]...
The graph situation is after that the same.
Hi @melbao
About null values versus 0, I saw:
But in my database, I have only zeros, never null… And I think you won’t save lots of space here. you will save more by deleting raw visit data 
I don’t understand what you mean… 
Did you previously set 0 in visit_goal_converted?
Did you wait also data archiving has processed?
How can only delete the goal data in the raw data?
It looks like no data was touched with the core:invalidate-report-data command.
No.
Yes. completelly.
Hi @melbao
I think that if you want to have a 0 line in the 2nd graph, you should put 0 in visit_goal_converted:
UPDATE matomo_log_visit SET visit_goal_converted=0 WHERE visit_goal_converted <> 0
Then another data invalidation + data archiving
I think that if you deleted content of tables log_conversion and goal, then you deleted most of goal data… You deleted all goal data that take disk space. What I meant was : if you want to save more space, you have to delete raw data, including the ones not related to goals (then all visits, actions, etc.). It is advised to not keep more than 25 months of raw data
I think it doesn’t matter whether there is a 1 or a 0.
According to this, it is probably the case that individual data in the raw data cannot be deleted, but always only whole data sets?
Thanks for the support.
Hi @melbao
It was just to delete the information, not to save space
In your case, removing visit conversions is not really a data deletion, but just a data update…
i look in this moment in the database table goal and see a column named “deleted” … hahahahaha! Nothing is deleted! Greetings to big brother.
Hi @melbao
The goal table is just the goal definition. Then nothing very sensible in term of user privacy…
OK, so what… but this points in a: a delete don’t delete!
A delete is also only a database entry.
@deedstoke , my observation is from Apr 21, 2023 8:09 pm. At the Apr 19, 2023, an archiving core:archive was running few (30) times as cronjob and was complete. All other was before this date. A answer of your question is: yes.