drush-ops/drush — pull request #115 by patcon (2013-09-18 13:54:43+00:00)
Title: Track feature usage metrics to know where to best focus development efforts

See: See https://github.com/bevry/docpad/issues/124 & https://github.com/bevry/docpad/issues/70

This idea was stolen from @balupton, the docpad maintainer, who in turn stole it from this Yeoman tool:

[`yeoman/insight`: Node.js module to help you understand how your tool is being used by anonymously reporting usage metrics to Google Analytics](https://github.com/yeoman/insight#readme)

The idea is that you use anonymous metrics and pipe them into an analytics tools, where you can do really in-depth work-up of your community usage patterns. This can be simple (see how often each command is used, and tracking active-use versions) or complex (seeing how often people are running remote commands with `@*.prod` aliases, etc etc.)

To imagine the benefits of this approach, imagine how development focus might chance if anyone in the community can link to the public stats that show that, "Hey, this issue that we've been bikeshedding for 2 weeks over 40 comments, is for feature X, which is only used on 0.3% of installs. Perhaps our efforts are best spent on resolving this other feature, which is for a feature used on 96% of installs on a daily basis?"

Stripped down example for Yeoman: http://insight-dashboard.herokuapp.com/

Hopefully you can see the exciting potential here. I'm hoping that drush maintainers might be interested in piloting this idea, perhaps using it as a PoC for similarly reimplementing usage stats in Drupal core.

Obviously, tracking certain metrics might raise eyebrows, so I would suggest we start simple, and go from there. Also, it would seem to be a worthy goal to publicize all data for the drupal community. Hopefully this would allow privacy conversation to happen publicly, among those who can see first-hand the benefit of the data.

With all the context out of the way, I would suggest using [segment.io](https://segment.io). They interface with lots of analytics engines, which would allow us to remain nimble, and choose the end-provider that best suits our needs based on privacy concerns, features, interface, and community support.

Segment.io PHP library: https://github.com/segmentio/analytics-php

Thoughts? As a pre-emptive measure, I've registered the drush namespace in segment.io, and I'm happy to add maintainers as collaborators so that they can poke around.

cc: @greggles @msonnabaum & segment.io php lib maintainer @calvinfo