Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Learning analytics #15

derega opened this issue Oct 7, 2015 · 0 comments

Learning analytics #15

derega opened this issue Oct 7, 2015 · 0 comments


Copy link

derega commented Oct 7, 2015

Story about feedback loops needs data. Data can be collected automatically by the systems. These metrics are describing how the user is using the services. This is of course specific to each service and they define their own metrics.

There can be common metrics between systems and these can be documented in this standard.

Collection of data happens by the services. But the data must be accessible for services which are analyzing the data. This can be the same service of course, but it would be much better to share the data system wide. This way all services can see how the user is moving between services in the whole system. This data could even be open.

Different methods and other thoughts:

Each service collects and stores the data themselves and then periodically publishes the data to central repository. Data is then queried back from central repository to services which need it. Central repository behaves like a cache for the data and it is stored there for only certain amount of time.

Each service collects the data and pushes it to central repository in realtime. Central repository works as a publish/subscribe message bus and publishes the data to all listening parties. Data is not stored in the repository.

Each service has common API which everyone else can use to query for data. There would be retention policies how long the data must be accessible in the API.

As a personal opinion I like all of them. They are not mutually exclusive and we could define the central repository to:

  • must have a database which stores the data for certain period
  • must have REST API to query the data (with public and open part)
  • must have publish/subscribe API for realtime message passing
  • must have an API to register services and then it must query periodically the data and publish it in the publish/subscribe API on behalf of the service


  • may connect to the publish/subscribe API
  • may have common API for querying metrics and register to the repository
  • must either connect to the publish/subscribe API or have the common API
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
None yet
None yet

No branches or pull requests

1 participant