search

ushahidi / platform

Ushahidi Platform API version 3+
http://ushahidi.com
Other
677 stars 506 forks source link

Collecting app metrics from deployments (which features are used, number of posts, etc) #585

Closed ushbot closed 8 years ago

ushbot commented 9 years ago

We need to integrate some kind of in-app analytics to collect data on what features/sections users are actually using and why. This will help us not have to depend on surveys, which are very subjective. @brianherbert, based on your experience, maybe you can lend some thoughts to this?

Created by dkobia on 2014-05-07 06:30:41.

Imported from https://phabricator.ushahidi.com/T236

ushbot commented 9 years ago

Comment by @brianherbert on 2014-05-12 16:42:37:

We're discussing providers via email, so perhaps we continue that discussion and report back here.

One of the other things is we need to make sure that the installer for v3 allows people to opt out sharing any data with us.

ushbot commented 9 years ago

Comment by @eyedol on 2014-05-12 21:04:19:

Maybe a setting to toggle it? In case a user installs without the web installer.

ushbot commented 9 years ago

Comment by Vidya on 2014-05-13 12:23:36:

Started a list of questions we want to answer/understand with the analytics: https://docs.google.com/a/ushahidi.com/document/d/1XA9QgdIM9TVpZHMnoTpWFRUoAwAp9Dgt5qQrfxpXgJk/edit#

What metrics can we collect that will provide insight into these questions?

ushbot commented 9 years ago

Comment by @brianherbert on 2014-05-13 18:36:54:

Regarding settings to toggle sharing metrics, in the case of Ushahidi in the Cloud (and Crowdmap Classic), we may want to control that for our users and make it something they cannot configure. This may bleed into some other features, but could there be a way that we could disable user modifiable settings from the code base? This stats issue is one case of that, where we may reserve the right to track deployments on our infrastructure, but other ones are more important, like disabling auto-upgrades.

ushbot commented 9 years ago

Comment by @rjmackay on 2014-05-14 21:34:36:

This is related to / part of T146

ushbot commented 9 years ago

Comment by shadowhand on 2014-05-21 06:48:21:

Linda, please work with Vidya and Brian on what these metrics should be. Initially, we will use these metrics for an Admin dashboard, but we also want to add an opt-in that sends anonymous usage data to our servers for analysis down the road.

ushbot commented 9 years ago

Comment by @brianherbert on 2014-05-21 18:04:58:

There has been some discussion about this. We may end up just using something like Google Analytics since we aren't currently running our own in house. Let's just assume that for now, which should make this pretty straight forward.

The only downside to this is it's difficult (impossible?) to pull these analytics out on a site by site basis for us to build the numbers into the admin dashboard.

Let's move forward assuming we'll use Google Analytics, then we can easily swap out their tracking code with a different one if we decide to roll our own before an official release.

ushbot commented 9 years ago

Comment by Vidya on 2014-05-22 05:12:47:

When do you need a finalized set of metrics by?

ushbot commented 9 years ago

Comment by @rjmackay on 2014-05-22 09:34:48:

Phone home stats is a separate issue: T146 ..

@brianherbert I don't quite understand the GA suggestion.. are you thinking for an aggregate set of stats for all deployments? or just GA integrations so deployment admins can add their own GA code?

For a stats dashboard.. this probably has a large cross over with T49 right? ie. showing reports counts over time, counts by category, reports by region.. An admin might want a few additional things like homepage views, most viewed posts, etc.. but we could farm that out to GA?

ushbot commented 9 years ago

Comment by @rjmackay on 2014-05-22 09:38:14:

◀ Merged tasks: T146.

ushbot commented 9 years ago

Comment by @rjmackay on 2014-05-22 09:39:35:

I'd like to see us use statsd (https://github.com/etsy/statsd) to collect some basic stats like # of reports. I think we could also breakdown stats by deployment just by creating a top level bucket for each deployment.. but that might end up being insane.

ushbot commented 9 years ago

Comment by @brianherbert on 2014-05-22 10:51:42:

statsd is all fine and good, but I was under the impression this ticket was concerning the global stat collection. If this is just for individual deployment stats saved on their own servers then I don't see a reason to have a switch to turn this off in the installer.

ushbot commented 9 years ago

Comment by @rjmackay on 2014-05-22 14:23:54:

Yea I was getting confused about what this ticket was for.. I'm suggesting statsd for global stat collection.. I was confused as to how GA would work for that?

ushbot commented 9 years ago

Comment by @brianherbert on 2014-05-22 14:34:12:

StatsD could also work. I think we decided on Google Analytics because @vidya is very familiar and it requires little to no effort to integrate. If we spin up statsd, we need to support a server for that and write our own reports (unless it's easier than that).

Looking at StatsD though for global collection, would this complicate setup (sending stats server to server, firewall rules, etc)? Just asking as a StatsD dummy.

ushbot commented 9 years ago

Comment by shadowhand on 2014-05-23 03:39:31:

Using statsd would involve creating a public API endpoint that deployments would hit to send us stats. The API endpoint would be backed by StatsD (or GA, or both!). We would have to write our own reports, but StatsD has a lot of powerful features built in for that. Combining both GA and StatsD would be ideal.