Collecting more information from CiviCRM installs ..

Most of you are aware that CiviCRM collects version, CMS and an MD5 hash of the base url from a CiviCRM install. We discussed this feature in the blog post: Extending the Version Check Mechanism in CiviCRM 2.0. The CiviCRM admin can decide not to participate in the ping back mechanism. Here are some useful stats that we've collected using this feature: We've got close to 4000 installs running CiviCRM v2.0. Approx 66% are Drupal, 34% are Joomla. We have 133 installs testing various versions of 2.1 alpha, 98 Drupal / 35 Joomla. We are currently trying to figure out what our focus for the 2.2 release should be. We get a lot of feedback from folks on the forums, blog and uservoice. However we do not have any idea of what features are being used with CiviCRM installs out there. For e.g. we have absolutely no idea how many folks are using CiviMember out there. If we knew that there were a few hundred installs using it, would help us decide on putting in more resources to improve it in 2.2. We'd like to collect some more information of what are some of the components people are using. We will be collecting total counts only and no specific information. Here are a few things that we think will be good to know:

• Total count of contacts, contributions, memberships, participants, pledges, mailings
• Total count of contribution pages and event registration pages and type of payment processors being used in those pages.

I have filed an issue for this here. This will be an extension to the ping back feature and can be turned off by a CiviCRM Admin. These stats are collected periodically when the admin visits the CiviCRM Administer Page. We'd like to hear your thoughts and comments on this. We do want to make sure that folks are fine with the concept and it being part of the core code along with the option of choosing not to participate. Update: In the end, for CiviCRM 2.1 we gather the following information on version checks: CiviCRM version, versions of PHP, MySQL and framework (Drupal/Joomla/standalone), default language, as well as the counts (but no actual data) of the following: contacts, activities, cases, relationships, contributions, contribution pages, contribution products, contribution widgets, discounts, price sets, profiles, events, participants, tell-a-friends, grants, mailings, memberships, memebership blocks, pledges, pledge blocks and active payment processor types.

Comments

Since the info is anonymous I'm all for it.

Have you though of adding specific release info though? (Apache,MySQL, PHP, Drupal/Joomla) it could give you a feel for who actually keeps up with their maint, and how many could handle an upgraded PHP/mysql requirement (like we had with 1.9). Also some other internal things I don't think you track would be counts for, custom fields, price sets, saved searches, tags, groups etc.

And then maybe as an opt-in only (since the data may be considered more sensitive) Payment processor used, recurring billing and server time zone to figure out where in the world we are :-)

http://www.SunflowerChildren.org/ Helping children around the world

Definitely do this! Capturing actual usage data is key to moving forward. One caveat - if a component has a low usage count, that could be a reason to enhance it too.

Makes perfect sense. Definitely go for it. It would be interesting to share with the community the stats you gather.