Meta: Page access statistics

[svenseeberg]

Motivation

Municipalities may want to find out which pages are being accessed most/least. We already collect this information in Matomo. This should be accessible to content managers.

Proposed Solution

• The page based statistics should be in the same page as the overall statistics (see v3 in Figma)
• Show a collapsed list of pages, which can be expanded like the page tree.
• A bar is shown to the right of the page title. All bars of all pages have the same width (which is not shown correctly in the design).
• Colors in the bar indicate the distribution of page access statistics per language.
• If a (sub-)tree is collapsed, it will show the sum of all sub pages and its own page access statistics.
• If a tree is expanded, the parent node no longer shows the sum but only its own direct access statistics.
• The time range should be freely selectable
• Monthly, Weekly, Daily should be available as intervals and should be the same filters as for the existing statistics.
• A modal should be shown when opening the page for the first time with some basic explanation and a link to the wiki. The modal should also be available with a help button.
• The checkboxes in the design should only be relevant for the export, not the displayed data in the page.
• The API calls to Matomo should be sent after each other, not at the same time. This will reduce the load on the Matomo server and also reduce the waiting time for the first visible data for the user.
• If possible the language selection across the existing and new graphs should be unified in the side bar.

Tasks

• [ ] #3130
• [x] #3131
• [ ] #3132
• [x] #3133
• [ ] #3134

Design Requirements

Design proposal (v3): https://www.figma.com/file/6U7R7Xj4wL7sbjxKRmOG9D/CMS-Project?node-id=1179-830

User Stories: I, as a manager, want to see want to see page access statistics to identify and remove irrelevant content

[dkehne]

@hauf-toni just a rough idea how i could imagine the page access overeview.

[hauf-toni]

Design proposal can be found here. @MizukiTemma @osmers feel free to leave feedback & possible questions via figma comment. we can also discuss the design proposal in the upcoming service team x cms x ui/ux call.

[hauf-toni]

perhaps there is a need for discussion here: should the "page access statistics" page appear in the sidebar as a single item under "analysis" (same emphasis as e.g. "feedback" or "translation report") or as a sub-item under the current access figures as a new box?

imo, a more prominent placement would increase visibility, facilitate access, encourage monitoring, and demonstrate the value of the feature. on the other hand, users might overestimate the importance of the data presented and draw the wrong conclusions (access numbers are not synonymous with importance). of course, this problem could possibly be solved by training the communities to interpret the presented data in the right way.

💬 are there opinions on this that you would like to share?

[osmers]

@hauf-toni I think it would make sense to not show it as a tab at all but to enable users to get to this specific view from the statistics page itself... If that is not prefered, then I think we should have one tab for overall statistics and one for page specific stats - i would not work with sub-tabs as it makes the menu more complex.

[svenseeberg]

I think there are a couple of caveats:

• What is the relevance of a list of the most read pages? That the content is good? That does not provide any actionable information.
• Should we provide a list of pages with the worst performing pages with only 1 or 2 hits per month (even zero in probably quite a lot of instances)? What would be the actionable information here? Does it mean that the pages are irrelevant and can be deleted? Or are they just containing the wrong keywords?

I think we need to define the goals first. Then the implementation will probably be easy to derive.

Just another totally wild idea: maybe it would be better to use the Google Search Console API to provide information about Google searches to content editors?

[osmers]

Google Searches would be interesting as well :) could be another issue/feature Regarding the actionable items - the plan is to write a guide for the municipalities on how to interpret the page statistics. Quite a few Kommunen ask regarding this information and since we collect it, it makes sense to share it. Actionable input should never be to delete pages, bcs just bcs they are not accessed often, does not mean, that they are irrelevant. It can be helpful information for municipalities to then go into further discussions with the users about what they need

[svenseeberg]

the plan is to write a guide for the municipalities on how to interpret the page statistics.

So what is it going to tell? Then we can derive a good presentation of the data. I think we also need to differentiate interpretation of data from actionable information.

[svenseeberg]

So what is it going to tell? Then we can derive a good presentation of the data. I think we also need to differentiate interpretation of data from actionable information.

We can recommend to use the data as a starting point for further questions, for example "Why does a page receive so few/many visitors?"

[osmers]

@hauf-toni ich hab mit Sven gesprochen und wir haben es fertig definiert - hast du morgen Zeit, um die Infos einmal durchzugehen? :)

[osmers]

@hauf-toni und wir sollten nochmal besprechen, wie es für die Nutzer:innen am besten ist, bzgl der Einstellungen für offline und WebApp Zugriffe, da es diese Unterscheidung ja bei den Seitenbasierten Zugriffen nicht gibt.

[hauf-toni]

an updated design proposal can be found 📌 here

[osmers]

@svenseeberg could you update the description to say that V3 is the right version in Figma? Whether online and offline access can be moved to the side column, is something the CMS Team needs to determine. If it is techincally possible I think it makes sense to solve it the way Toni proposed.

[dkehne]

@MizukiTemma as https://github.com/digitalfabrik/integreat-cms/issues/1436 is more important for imaoact (and it was moved to 24Q2 milestone), i would suggest to move this issue to 24Q3.

[charludo]

• The API calls to Matomo should be sent after each other, not at the same time. This will reduce the load on the Matomo server and also reduce the waiting time for the first visible data for the user.

• If a (sub-)tree is collapsed, it will show the sum of all sub pages and its own page access statistics.

These two things appear to be mutually exclusive. Edit: unless the sum can be requested directly from matomo?

• If a (sub-)tree is collapsed, it will show the sum of all sub pages and its own page access statistics.

• If a tree is expanded, the parent node no longer shows the sum but only its own direct access statistics.

It might be a bit confusing for users if expanding the parent changes its shown statistic. Maybe the sum could instead be shown as an additional row once the parent has been expanded?