search

OpenCMISS / website

Source for the OpenCMISS website.
http://opencmiss.org
0 stars 7 forks source link

Add analytics to pages and downloads #3

Closed inkybutton closed 8 years ago

inkybutton commented 8 years ago

(Copied from https://github.com/OpenCMISS/documentation/issues/31 ) Currently analytics and usage information is not being captured on the website. They should be.

Considerations:

Need to be able to identify which files - stable binaries, development releases, tarballs - are being downloaded. They are presented on a Javascript-driven downloads page, would the analytics package be able to capture that? Access to the data by people involved in the project - should it be public or private? Who should get access to the analytics. Privacy - the right for users of the website to not be identified and/or tracked on an individual basis by the Physiome Project and analytics vendors. (anything else?)

Possible candidates are:

Google analytics - there's an existing GA account for the physiome website. It is possible to anonymise IP addresses stored by Google, thus respecting right to not be individually identified? https://support.google.com/analytics/answer/2763052?hl=en GA requires a privacy policy: https://termsfeed.com/blog/privacy-policy-google-analytics/ Piwik - https://piwik.org/ OWA - http://www.openwebanalytics.com/ (any others?)

inkybutton commented 8 years ago

General tracking and analytics has been implemented using GA (see #2 ) Tracking activity on downloads page needs more work. To track a click on the download button, we will need to add code that sends an "event" to GA's server when the user clicks on the button. GA supports sending up to three fields/pieces of information in the event object. However, a download has four fields:

GA's UI is designed around viewing three fields. We can concatenate two of those fields together to fit this so I propose to send the information like this:

This way it's possible to find out total downloads, total downloads per platform or project, as well as downloads per project per software version + format of download. However it won't be possible to find out how many downloads are there per version regardless of the format downloaded, and vice versa. We can download the data and manually split the fields out, but that will be more time-consuming.

Is that a good tradeoff?

hsorby commented 8 years ago

I think so, the format is of the least importance of the four fields and can fit in ok with the version information.

inkybutton commented 8 years ago

Thanks @hsorby , thoughts from others? eg. @chrispbradley

chrispbradley commented 8 years ago

Except that the version number will be the same regardless of software name (and component name is somewhat irrelevant and we need to encourage people to download just OpenCMISS - yes, individual components can be downloaded but these are specialist cases and should not be overt) and so name and version are the two least significant bits of information and thus should be combined so as to maximise information "bandwidth".

rchristie commented 8 years ago

Each component has its own version number & it's highly relevant as we will have multiple historical versions. Component name is also relevant; we want to know what has actually been downloaded. This is only going to get more important once Cmgui, OpenCMISS-Osmium and OpenCOR are added.

chrispbradley commented 8 years ago

In a sense what is combined to form the three GA tokens is a little moot as I assume we will just get a string of a concatenated with b? If so then all four pieces of information can be easily extracted so which two items are concatenated is a bit irrelevant? Now, with regard to the comments above then the policy is that the component names are purely internal and should not be visible to the user. As far as the user is concerned they are just using OpenCMISS. Thus for the OpenCMISS components there is only one version number that can be visible to the user. Now the version number is just a label/tag and the only two things that matter for these tags are 1) that they are unique so that different versions can be differentiated from each other and, possibly important, 2) that there is some implied order so that one version can be deemed newer than another version. Hence what is important is that for a given release all the source across all the components that are included in that release are tagged with the one version that is visible to the user. There may be additional secondary tags and these secondary tags may be different between the different component source repositories. These secondary tags are, however, just that - secondary. They are redundant for identifying what is in a particular release. The most straightforward versioning is to have an OpenCMISS version number that is incremented whenever there is a new release. Everything in a release should be tagged with this version number. Anything else just adds extra redundant complexity. If that causes a clash with existing branch names then those older historic branches can be renamed. Again, it doesn't matter what they are called just that they are unique. We can add this to the agenda for Friday if required.

nickerso commented 8 years ago

I would suggest concatenating the platform and the format as that seems the most logical to me :) i.e., ubuntu-deb, ubuntu-targz, win32-msi, win32-zip...

rchristie commented 8 years ago

I like Andre's idea.

inkybutton commented 8 years ago

During today's OpenCMISS meeting @nickerso's idea was accepted.

nickerso commented 8 years ago

7 and #8 resolved this issue and it can be closed now?