SPIKE: Rec's - Requirements for storing user interaction data from recommendations.

[adonahue]

Need to incorporate here - or in the other stories - rules about storing user interaction data so we can analyze it later.

Logging user interactions on Rec’s will be useful for research: What they completed and when When it was displayed / seen.

[jaedoucette]

Consider using Google Analytics instead of dumping to MongoDB?

Maybe think about MongoDB.

[jaedoucette]

Conclusion

The best solution for now is:

• Currently, recommendations are generated by a function getRecommendations() that is called in the componentDidMount() function of the recommendations sub-component of the Dashboard.
• After this getRecommendations() function has been successfully called, the componentDidMount() function has local access to the current user's identifier, and to the list of recommendations.
• The recommendations should be filtered based on their shouldDisplay() methods.
• The filtered data should then be written to a new service in the riff-server MongoDB. This service should store:
  1. The id of the current user.
  2. A timestamp.
  3. A list of pairs, containing each of the recommendations' display texts (or something else that clearly identifies them?) and the boolean value produced by the isCompleted() method of each recommendation.

In the (far?) future, it may be preferable to refactor this as a Mattermost plugin. In that case, we would:

• We should insert a new kind of entry in the key/value store in the table in the Mattermost SQL database that is used for plugin data.
• Store the same data there instead.

Additional:

• Google Analytics was considered as well, but it seems to provide & collect a lot of information we don't need, and it is unclear that it would collect all the information we did want. It could collect nice extra information about what actions the users took as they navigated around our page, similar to the data we should be collecting through the OpenEdX api. We might want to consider introducing this as a separate issue.

[jaedoucette]

@adonahue This is ready for review.

If it looks good, I can create a separate card (probably for @jordanreedie) to implement this feature as written.

[adonahue]

@jaedoucette - this looks pretty clearly defined to me - thanks! Please go ahead and make a separate card for this and stick it at the top of the sprint backlog. I will close out the spike. Do you know if any of the remaining recommendation work is blocking this?

[jaedoucette]

@adonahue Great, I'll make another card. The existing recommendation work is not directly blocking this. However, we would need to build it on top of that work, which in turn is built on top of the network-graph work. Both of those are currently unreviewed and have not been merged into the main development branch.

When we build on top of unreviewed code, there will be extra overhead, because changes in the things we are building on top of will create problems in the things we build. This will make development somewhat slower. If we were willing to wait until code review of network graph, or of both network graph and the existing recommendation work, development would be somewhat faster.