Hi @sandin78, it would be nice to be able to look back further for config_id matches, but it seems like there may be issues with daily archiving accuracy if the config_id doesn't rotate every 24hrs.

Disabling the create_new_visit_after_midnight = 1 config setting would prevent the use of a 24hr finger print salt, but the config setting comes with the warning ONLY CHANGE THIS VALUE WHEN YOU DO NOT USE MATOMO ARCHIVING, SINCE THIS COULD CAUSE PARTIALLY MISSING ARCHIVE DATA so clearly isn't recommended.

@tsteur, @sgiehl Do you have any insight into why there is a 24hr maximum for the config_id?

It was restricted to 24 hours for privacy reasons. Usually, cookies or some similar technology can be used to track users over a long period and if they can't or shouldn't be used then we restrict to 24 hours as otherwise you could see the config_id as fingerprinting.

An option to change this behaviour could be possible though 👍

Yes. I understand the benefit of having this restriction and the selling point for the Matomo user is "i can't change it even if I wanted to". I guess there's a whole bunch of Matomo settings that helps the Matomo admin to comply with various privacy laws, but they can be configured in a non-compliant way. So it's up to the Matomo admin to comply, and I think it would be the same regarding this setting. Default should be 24h.

Disabling the create_new_visit_after_midnight = 1 config setting would prevent the use of a 24hr finger print salt, but the config setting comes with the warning ONLY CHANGE THIS VALUE WHEN YOU DO NOT USE MATOMO ARCHIVING, SINCE THIS COULD CAUSE PARTIALLY MISSING ARCHIVE DATA so clearly isn't recommended.

Hm, obviously I don't know why this could be, but it would be great to get some insight.
Is it because otherwise an ongoing visit would not be attributed to the new date? I mean if the visit started on 23:50 and continued over midnight.

If I were to test setting create_new_visit_after_midnight = 0 , this would mean that the limit to finding config_id has would be truly limited by the window_look_back_for_visitor which was what I originally had hoped.

Okay I dug a little and found https://github.com/matomo-org/matomo/issues/9156
In fact it seems that actions logged after midnight, from a visit that began before midnight, will be lost. I assume this is because the actions would belong to the visit but the report is already archived for the previous day and will not update.

I guess the way the archiving is designed, it runs each day separately. I mean of course there is no limit for how long visits could last, but it would be possible to regenerate day1 if finding actions on day2 belonging to day1.
But of course, this opens more problems, for instance if day2 is in a new week, or a new month.

I will test this. It will be interesting to see if the actions of each day add up to the weekly :).
Not sure if this setting is the way forward, but atleast I'm thankful that you opted in the end to have this as config, and not default for all users. I will have to do a test and then weigh the pros and cons.

But I think that this issue could be closed! There's no need to set a limit for this when the limit can already be removed and timelimited then by another setting.

Thanks for posting your findings @sandin78, this information might be useful for other people wanting to try the same thing and can help inform any future improvements made to this part of Matomo 👍

This issue has been mentioned on Matomo forums. There might be relevant details there:

https://forum.matomo.org/t/change-config-id-settings-possible/48338/2