Basic built-in statistics in Opencast (specification/proposal)

[LukasKalbertodt]

Hi everyone!

It took a while, but I finally worked out a proposal for basic built-in statistics in Opencast:

https://hackmd.io/__ThjezpQbymmacJipBDCQ?view

While "basic" in the title sounds like simplicity, the 9000 words in the proposal suggest otherwise. Designing this system took quite some effort and I wrote down most interesting design decisions in the "discussions" or "alternatives" sections so that everyone can follow why decisions were made the way they were and what I already considered. But be assured that I tried to keep it as short as possible given the information that it contains. Also, none of the text is AI slop.

The "Discussions" sections contains some introductory things, especially about hashing and pseudonymization. Read those first to understand related points in the proposal.

Of course, we want to give the community the opportunity to comment on this before starting implementation.
That's what this post is for!
However, to avoid this lingering for too long, I'd ask you to comment before the end of May!
And while you don't necessarily have to read everything, please check whether your concern/topic is already addressed, e.g. in the "alternatives" section.

Try commenting here for bigger/general topics and use the HackMD comment function for small/localized comments. If you comment here with two or more bigger topics, it's useful if you write one comment per topic so that threaded-discussions work better.

I don't have any specific questions for the community, but any feedback and relevant information is appreciated!

Proposal Changelog

• 2026-04-28: initial proposal
• 2026-04-30:
  • Added "Raw event producers" section. This was not explicitly mentioned before as part of this proposal.
  • List a few specific privacy laws instead of just "privacy laws".
  • Edit "Data completeness" section to remove the need for remembering when raw event types were first seen. Also remove paragraph about "one could also store aggregation version per event". The removed stuff likely just added complexity without significant advantage.

Details

[snoesberger]

Thank you very much for your detailed specification, @LukasKalbertodt ! I’ve added some comments directly in the document.

A common request from our users is for the distinction to be made between views of the live stream and views of the recording. Live stream views aren't mentioned in your specification, but I believe they could be tracked in the same way as views of recordings. Maybe it is worth mentioning it in the specification? (And maybe something more is to consider regarding live streams?)
However, to cover this use case, it would be useful if the API offered an option to query live stream or recording views/watch time specifically (although one could also get all the data for an event and compare it with the scheduling information, it would be nice to be able to get it with one single API call).