Move xwiki-platform-statistics to XWiki Attic

[mleduc]

Hi devs,

I’d like to propose a vote to move xwiki-platform-statistics to XWiki Attic.

Rationale:

• Old, unmaintained, no bug fix or improvement since a long time
• Has performance issues
• We suggest to use the Matomo Extension instead

Rationale for Attic vs Contrib:

• If one day we find that we need to have it in contrib and release it, we can always do it

Here is my +1.

Please cast your vote.

Thanks

PS: Given the number of people in vacation in the following weeks, I propose to keep this vote open until January 10, 2024

[tmortagne]

xwiki-platform-statistics is a very small part of what makes the statistics (and not the problematic one with which most jira issues are associated). Any plan regarding the rest ?

Do you plan to first release an installable version of it before moving it to the attic ? Note that it might not be very easy as it’s a bit mixed with other stuff in oldcore.

Otherwise, it’s more a vote to delete it without any way to get it back than just a move to the attic.

[vmassol]

What about all the multiple places where stats are in the API and used in xwiki classes? Any plan?

Slightly related: Re: [xwiki-devs] [VOTE] Stop bundling the Statistics Application by default in XE

+1 in general but it would also be nice to also legacify the stats code (and not just the stats app - ie stats UI).

Same question as Thomas.

[mleduc]

@vmassol

What about all the multiple places where stats are in the API and used in xwiki classes? Any plan?

Ok, I wasn’t aware of how much of the stats are part of xwiki-platform-oldcore. Removing xwiki-platform-statistics alone does not make sense.
From my current understanding, removing the statistics related part of XWiki would be a breaking change (for the hypothetical users of this feature).

Si I guess we have two option 1

Option 1

1. move xwiki-platform-statistics to the attic
2. remove all the code related to statistics from xwiki-platform-oldcore to legacy (if it’s possible, I’m not entirely sure for the part related to the database).

Option 2
Remove all the code related to statistics without a way to get it back.

imo option 2 is only acceptable if we have a plan for a new statistics design which would not force us to alter xwiki-platform-oldcore

[tmortagne]

@mleduc

I’m not entirely sure for the part related to the database

It’s not a problem for the mapping, since we already have a few modules which inject it dynamically and are not relying on xwiki.hbm.xml.

[surli]

@mleduc

Option 1

1. move xwiki-platform-statistics to the attic
2. remove all the code related to statistics from xwiki-platform-oldcore to legacy (if it’s possible, I’m not entirely sure for the part related to the database).

Option 2
Remove all the code related to statistics without a way to get it back.

imo option 2 is only acceptable if we have a plan for a new statistics design which would not force us to alter xwiki-platform-oldcore

For me there’s a third option:
Option 3

• Bundle xwiki-platform-statistics, the DB mapping and the aspects to injects the API in oldcore in the attic

but maybe it’s not good because we cannot have those aspects applied on top of the aspects we already do in legacy?

[tmortagne]

@surli

but maybe it’s not good because we cannot have those aspects applied on top of the aspects we already do in legacy?

I don’t think this is a problem, but it’s not clear to me what you are proposing the users, “if you want the statistic module, change oldcore version in the pom, build this custom legacy-oldcore JAR and replace the one in WEB-INF/lib” ?

[surli]

@tmortagne

“if you want the statistic module, change oldcore version in the pom, build this custom legacy-oldcore JAR and replace the one in WEB-INF/lib”

yes, not much other option I think with this solution. The idea here is just to avoid keeping in legacy too much stuff related to statistics. Now it’s probably not really harmful.

[tmortagne]

@surli

not much other option I think with this solution

Honestly, it’s extremely close to just remove it in practice

[vmassol]

I agree with Thomas that doing this is the same as saying that the statistics feature is removed (and moved to the attic), ie it’s not usable any more.

Generally speaking, I think it’s interesting to have a statistics module in XWiki and that we need one. We need it for several reasons:

• To be able to have fine-grained stats that cannot be obtained using Matomo or the like. One example is number of users viewing pages belonging to a given extension, but there are plenty more.
• To be able to have features in XWiki needing stats. For example, imagine an extension that would allow some access to a feature of the wiki based on the level of contribution of the user.

So one idea would be to:

• Remove the current stats modules/code (xwiki-attic) and explain how to get it back for users who absolutely need it.
• Create a design page to imagine a next-generation stats feature (using a NoSQL DB most likely, and extensible so that extensions can add new stats to it). As part of the UCs, we could list the need to count the usage of a given feature of XWiki (how many times a feature is used).
• Then find some time to work on it…

WDYT?

[tmortagne]

@vmassol

To be able to have fine-grained stats that cannot be obtained using Matomo or the like. One example is number of users viewing pages belonging to a given extension, but there are plenty more.

Are you sure this is not possible ? You can give a lot of custom metadata to Matomo (and others, I assume), for example a metadata giving the identifier of the current page’s extension.

[vmassol]

@tmortagne

Are you sure this is not possible ? You can give a lot of custom metadata to Matomo (and others, I assume), for example a metadata giving the identifier of the current page’s extension.

How would you give Matomo the list of pages belonging to an extension for example? More generally, how does this work (how can XWiki give metadata to Matomo)? Or do you mean indirectly, by having to modify the HTML renderer to ouptut metadata in the generated HTML, which can then be extracted by Matomo?

Note that even if this worked, there are stats other than page-based stats (like when using an extension, and this extension does’t have wiki pages).

[vmassol]

ok it seems they have a java tracker too: Java Tracker: API Reference - Matomo Analytics (formerly Piwik Analytics) - Developer Docs - v5

That’s nice (didn’t know about it). The problem is now deciding that Matomo becomes our stats api. This looks risky. I’d prefer something more agnostic library (or our own api).

The alternative is providing proper extension points in XWiki so that various extensions can implement their trackers. This would mean a Matomo extension for XWiki, plugging into these extension points to call its tracking apis, vs an XWiki tracking api with a bridge for Matomo (and other tools).

[vmassol]

@vmassol

I’d prefer something more agnostic library (or our own api).

Something like GitHub - segmentio/analytics-java: The hassle-free way to integrate analytics into any java application. but open source (segment doesn’t seem to be).

EDIT: A long time ago, I had researched Home | Metrics but I don’t know if it’s still relevant (probably not). EDIT2: it’s old: Release Notes | Metrics

[tmortagne]

@vmassol

Or do you mean indirectly, by having to modify the HTML renderer to ouptut metadata in the generated HTML, which can then be extracted by Matomo?

Matomo does not extract anything from the HTML, we use the javascript API to sent it metadata (that’s basically how all tools like this works), some are standard Matomo metadata and some are custom.

[mleduc]

@vmassol

• Remove the current stats modules/code (xwiki-attic) and explain how to get it back for users who absolutely need it.
• Create a design page to imagine a next-generation stats feature (using a NoSQL DB most likely, and extensible so that extensions can add new stats to it). As part of the UCs, we could list the need to count the usage of a given feature of XWiki (how many times a feature is used).
• Then find some time to work on it…

+1 for that plan. Thanks

[vmassol]

Note that while waiting for a potential new stats feature for XWiki, users should rely on external apps like Matomo. XWiki provides such an integration at https://extensions.xwiki.org/xwiki/bin/view/Extension/Piwiki%20Integration

This integration can be pushed further. Some ideas:

• Use the Matomo analytics API to display stats inside XWiki pages.
• Embed Matomo widgets into XWiki pages.
• Provide additional XWiki data to Matomo using the Tracking API. See also GitHub - matomo-org/matomo-java-tracker: Official Java implementation of the Matomo Tracking HTTP API.. This allows to track almost anything using setPageCustomVariable(). For example:

  PiwikRequest request = new MatomoRequest(1, new URL("https://my-site.com/action"));
  request.setActionName("myAction"); request.setPageCustomVariable("key", "value");
  PiwikTracker tracker = new PiwikTracker("http://your-piwik-domain.tld/piwik.php"); 
  HttpResponse response = tracker.sendRequest(request);
  

[lucaa]

Hello all,

I’m fine with dropping the stats features & modules, as they’re currently implemented.

Most of the times, client side usage stats are configured and used with XWiki (e.g. Matomo or GA or equivalent) and this is enough to do the job in most cases, especially as they also provide specialized analysis features.

Now, the main difference between these tools and the server side statistics registration is the fact that for the client side-based stats it is possible to access the content without logging access stats (using blockers etc), while this is not possible for server side logged stats. Thus, the 2 solutions are not perfectly equivalent.

However, for the purposes of audience analysis, they are equivalent.

Concerning server-side access stats (that can still be interesting when client-side tracking is incomplete or unreliable), there are alternatives that can / should replace the current stats implementation:

• frontal server access logs - however, the information at this level may not be enough or correctly shaped on the XWiki data model, so the analysis may be limited at this level
• usage stats based on the events stream store / custom events. From my point of view, there is a certain redundancy between the current stats implementation and the events store used for notifications, as they cover somewhat the same need: being able to know what happened on the wiki. In case of the stats it’s an aggregated information that is needed (counts) while for notifications the information is needed individually for each event, but it’s globally the same thing and the same data source should / could be used.

Thus, it’s a +0 from me.

@vmassol

Create a design page to imagine a next-generation stats feature (using a NoSQL DB most likely, and extensible so that extensions can add new stats to it). As part of the UCs, we could list the need to count the usage of a given feature of XWiki (how many times a feature is used).

As explained above, for me the next generation stats should be based on the events stream.

Thanks,
Anca

[vmassol]

@lucaa

I’m fine with dropping the stats features & modules, as they’re currently implemented.

Thanks for the feedback.

@lucaa

Concerning server-side access stats (that can still be interesting when client-side tracking is incomplete or unreliable),

As I’ve mentioned in previous replies in this thread, I think there are ways to always have complete tracking of anything, by improving the Matomo integration. Namely we can register XWiki server-side components (or any extension points) to push any type of data to Matomo.

@lucaa

As explained above, for me the next generation stats should be based on the events stream.

I agree we’d need to evaluate that and that it’s an interesting source. My only worry is that I’m not sure it’s performant enough for very large event volumes. And for that we might need asynchronous queuing systems and stores not on the same machine. But it could probably be refactored to support that somehow.

For the moment the event stream contains incomplete data for statistics. Here are 2 examples:

• Event stream doesn’t log page views
• Event stream doesn’t log feature usage (something we’ll want to support)

Now, ofc we could push new events to the event stream to capture more data. If we do this, we’ll also need to add the concept of event categories so that we can filter out events when displaying the Notifications events for example. Users would not want to see their page views or other user’s page views in their notification tray.

Another option is to not even try to implement a stats store in XWiki and instead push all the data captured to Matomo (for example). I don’t have enough experience with Matomo to know if all the use cases would be filled, if it’s performant/scalable enough (but I’d expect any serious such tool to propose options for scalability), etc. Note that the implementation could be quite generic and work for any analytics tool that offer an API to push custom data to it.

Thx

[vmassol]

So far the consensus is:

• +1 from Thomas, Manuel, Simon, Vincent to drop the Stats feature. And +0 from Anca. So we have enough feedback to act on this and consider that the conclusion is that we want to remove the stats feature from XWiki.
• The remaining question is more about how to perform the removal. It’s not yet clear if it could be done with a combination of code refactoring + aspects or if we need to just drop the idea of being able to explain to users how to put it back.

As a consequence, I’m going to close all issues related to the stats feature as Won’t fix.

@mleduc we could do a session to brainstorm about how we do the removal if you want.