Introduces a new core metric,
nb_profilable calculated with VisitsSummary metrics as the sum of visits that are profilable. If less than 1% of visits for a period are not profilable features that depend on profilable data are hidden or disabled. This includes:
wondering generally instead of removing some reports to maybe rather show a notice like "This report won't show any data because no profilable visitors" (would need to word it better).
:+1: this makes sense to me. It would be strange to just click a report and suddenly not be able to see a report. I'll make this change?
I'll make this change?
@mattab can you provide a UI review + look at the comments on the review and provide your thoughts?
@tsteur looked over this pr again. In it I'm adding nb_profilable as a core metric, but it is saved even if the value is 0. This is so we can tell when it was never computed. An alternative is to not save if 0 like every other metric, but in that case also save
has_computed_profilable=1 as another metric. Do you think this is a better approach?
@diosmosis thought about it for a while and I reckon we can simply always store the column and no other column needed. Meaning we treat the values before it was not tracked as not profilable. It be worse if it was the other way around and by default it would assume a visitor was profilable.
@diosmosis is this ready for a review? I know it has the label but not sure when it was added.
I'll review this later today
profilableelement in the response of
Live.getLastVisitsDetails- it would be helpful to troubleshoot which visit is profilable or not, for example to validate value of
<nb_profilable>, or to notice why the API output may not include some elements such as
The following error just broke Matomo (v4.4.1): Call to a member function isRequiresProfilableData() on null on /home/matt/dev/matomo/core/Plugin/Report.php(1013)at URL
Returning Visits Over Timeand the
Frequency Overvieware correctly hidden, but the
Visits by Visit Numberand
Visits by Days Since Last Visitare still displayed (expected them not to be displayed in this case?)
This report requires profilable data, but the current period of 2021-08-27 does not have any, so this report will not have useful information and should not be relied upon.(see screenshot above)
This report is inaccurate should not be relied upon. This report requires profilable data (tracking cookies enabled), but none of the visits did in the current period of 2021-08-27.
Segments are removed in the UI but nowhere else. We can also disable them and provide a tooltip saying why it doesn't make sense to use them on the current period. But when creating the segment, the period is arbitrary (eg, maybe they want it to be applied to a period w/ profilable data). Seems odd to see it greyed out and realize you have to change the period to be able to use it.
Could we leave the segments available, and not change the Segment Editor UI, but whenever they apply / use a segment that doesn't make in cookie-less (so when they are viewing the reports), then we could display a Warning notification explaining that the segment relies on data that is inaccurate because visits are not profilable?
in the original issue only unique visitors is requested. I'm not sure if there are others we'd also want to remove. Fingerprints could be useful. Can user IDs be specified without a visitor ID?
Here is the full list of reports we need to disable or warn about inaccurate data:
Unique Visitors and New VS Returning visitors metrics will be inaccurate
The whole engagement sparklines widget is disabled so no need to specify _returning specifically.
Goals and Ecommerce conversions will be attributed to the channel used in the visit that converts
Added a warning to goals & ecommerce pages.
Multi Attribution and Cohort reports won’t show data
Created PRs for this.
Other reports are marked as requiring profile data.
@mattab was this one reviewed and good to merge once tests pass?
Not yet, I will review it as soon as possible (hopefully this week)