Background: In #6986 I recommended to add the following to config to make Ecommerce reports faster:

[General]
browser_archiving_disabled_enforce = 1

[Segments]
Segments[]="visitorType==new"
Segments[]="visitorType==returning,visitorType==returningCustomer"

At the beginning I thought this bug is not related to this change but I do now. The VisitFrequency plugin uses the visitorType==returning,visitorType==returningCustomer segment to calculate returning visitors which should be pre-archived because of above configuration. Apparently it is not.

There could be some problems with this:

• When you add this config the first time, and there are archives for let's say the last 50 days but not for those segments, would it archive the segments for the last 50 days or not? If not, it would explain why it shows 0. This would also mean in the next days there should be values visible.
• As browser_archiving_disabled_enforce is set as well - which is needed to make UI fast I think - and we decide to use another fixed segment at some point in Piwik, we will display 0 values as well. Meaning we would have to announce such things in Changelog etc but even this will result in errors as most people won't see this.
• When browser_archiving_disabled_enforce=1 we should not allow in UI to create segments that will be processed in "Real time" as it would not work I presume. This shows there is something wrong.

I think if browser_archiving_disabled_enforce=1 we should maybe automatically archive all Segments used by core? Or maybe another config entry for this? But this would make it only more confusing! Maybe we can clean up those config entries around browser archiving. Having a better naming convention see eg enable_browser_archiving_triggering vs browser_archiving_disabled_enforce etc. There could be maybe also a new section [Archiving]. At the same step we should cleanup all Segment related config entries. Eg there is the [Segment] section which contains only above entries but then there are many other entries such as pivot_by_filter_enable_fetch_by_segment, anonymous_user_enable_use_segments_API, enable_create_realtime_segments, enable_segment_suggested_values, ... This is also related to #6609.

@Guite do you mind setting browser_archiving_disabled_enforce = 0 in config just for a test, then reload this widget and see if it displays values afterwards? The config PHP file might be cached by your webserver and might need a webserver restart or so.

I tried that, but it didn't change anything.

The values are displayed some sites, but not for others. Going to observe that within the next days.

The values are shown correctly for February (day, week, month), so it seems the problem affects only dates in the past (e.g. January).

FYI by default, if core:archive is setup and running once a day, then the Frequency metrics should be pre-processed automatically, because the core:archive command calls the API.get API which calls all .get APIs of all plugins. This includes VisitFrequency.get which pre-processes its data by calling VisitsSummary.get with the segment "visitorType==returning,visitorType==returningCustomer".

If you see that VisitFrequency metrics are not pre-processed by the core:archive then it's a bug.

I assume it did not pre-process the segments for archives in the past where it did already create a normal (non-segment related) archive

FYI:

It took me a while but I think I can reproduce it. I took the following steps:

Archived as usual, browser archiving and enforcing browser archiving enabled (=0, not really relevant I think). Everything - including VisitsSummary with returning segment - was archived and worked fine.

Then I enabled

[Segments]
Segments[]="visitorType==new"
Segments[]="visitorType==returning,visitorType==returningCustomer"

which we recommended to do in this case to make sure the Goals returning and new visit metrics will be pre-archived (see #6986).

Afterwards I ended up seeing always 0 returning visits in VisitsFrequency which is usually not the case.

FYI: The following is happening:

We end up having done flags like donefea44bece172bc9696ae57c26888bf8a and donefea44bece172bc9696ae57c26888bf8a.VisitsSummary. In my case only the latter one had actually idarchives / data but the plugin looks for the first done flag because of https://github.com/piwik/piwik/blob/2.13.0-rc1/core/ArchiveProcessor/Rules.php#L50-L56 .
It thinks that segment is prepocessed, which it kinda should, but it isn't.

TBD: Why is there no data for the first done flag.

When not archiving VisitsFrequency.get but only the predefined Segments in config it works. So somehow it might think that a segment is already prearchived because donefea44bece172bc9696ae57c26888bf8a.VisitsSummary exists when trying to archive donefea44bece172bc9696ae57c26888bf8a

It is as I presumed. When archiving VisitsFrequency.get it looks for donefea44bece172bc9696ae57c26888bf8a.VisitsSummary and donefea44bece172bc9696ae57c26888bf8a here https://github.com/piwik/piwik/blob/2.13.0-rc1/core/DataAccess/ArchiveSelector.php#L76-L80 .

It finds a value for donefea44bece172bc9696ae57c26888bf8a.VisitsSummary so it doesn't archive donefea44bece172bc9696ae57c26888bf8a as it has an $idArchive here https://github.com/piwik/piwik/blob/2.13.0-rc1/core/ArchiveProcessor/Loader.php#L68. But when reading the archive it only looks for the latter one that was not archived here https://github.com/piwik/piwik/blob/2.13.0-rc1/core/ArchiveProcessor/Rules.php#L50-L56

Not sure how to fix it best.

@tsteur feel free to move this one out to mid term as it's maybe too complex to solve for now

I will. It is anything else but easy to solve. Easiest way to solve it will be probably during the Archiver refactor in #7470.

@Guite as mentioned in #6986 (comment) starting from Piwik 2.13 you should be able to remove those config entries and VisitFrequency should work again in all sites.

Hi @Guite I believe we fixed this bug a few versions ago - it seems to work on demo but i'm not sure if i'm testing correctly. Could you confirm whether this works (or not) for you in Piwik 2.14.3? thx

Yes, it does.

Great to hear and kuddos for @tsteur as this was a very very tricky one!