A/B tests and Heatmaps plugins fails when 'range' inhibited

Hello,

We have been using A/B tests and Heatmaps plugins for some time without any issues.
We recently updated few settings to inhibit date range and improve overall performances (FYI, we run a cron every hour):

enable_browser_archiving_triggering = 0
browser_archiving_disabled_enforce = 1
archiving_range_force_on_browser_request = 0
enable_create_realtime_segments = 0
time_before_today_archive_considered_outdated = 2700
enabled_periods_UI = "day,week,month,year"
enabled_periods_API = "day,week,month,year"

Since this update, both A/B tests and Heatmaps are failing to display the overview page, and return this error:

Error: The period 'range' is not supported. Try any of the following instead: day, week, month, year

Even though we didn’t select any date range. The error occurs even when selecting a day, week or a month.
FYI, I can fix the issue by putting back ‘range’ in enabled_periods_API, but this is a short term workaround as I don’t want my user to think they can select date range in “compare to”

Could you please have a look?
Thanks

Hi there,

This range is required for these features to work. We could alter the message but you will still have the error. You will need to enable range for these plugins to work.

Thanks,

Hi,

Thanks for the inputs.
Could you please provide more information about why those plugins need range to work?
Atm, I’ve those settings:

enabled_periods_UI = "day,week,month,year"
enabled_periods_API = "day,week,month,year,range"

A/B tests plugin is working fine with them, even though this error appears on each report:

Error: Period must be one of: day, week, month, year

Which doesn’t prevent the report to be correctly displayed.

Hi there,

This is a technicial limitation. We have added this to our backlog for further development, I can’t offer a timeline for a solution at this stage.

Can you tell us the performance issues you are facing when range is added? It is quite unusual to have this disabled.

Thanks,

Hi,

We face some performances issues when our user select “range” for Goal plugin, as we can’t pre-generate those reports with our cron job.
We tried to increase the CPU of our App server, but the instance remains unavailable for other users for some time, when one of those report is being processed.

Note that even though we implemented master/slave for our DB, it didn’t help in this case, because those “range” reports seem to require processing on App server rather than DB server.

Thus, we decided to inhibit “range” reports, by adding those settings:

enable_browser_archiving_triggering = 0
browser_archiving_disabled_enforce = 1
archiving_range_force_on_browser_request = 0

And as advised on this file, we tried to remove “range” from enabled_periods_UI and enabled_periods_API.

Hi there,

You have executed all the recommendations here: https://matomo.org/docs/optimize-how-to/ what are your monthly pageviews?

Thanks,

Hi,
I’m not sure i can disclose the right amount, but the order of magnitude of pageviews is between 1 and 10 millions a month.

Hi there,

I recommend you purchase a support plan https://matomo.org/support-plans/ the support team will be best to help with this situation.

Thanks,