Collecting more information from CiviCRM installs ..
- Not Just a Contact Database
-
These optional components give you more power to connect and engage your supporters.

civiCONTRIBUTE
Online fundraising and donor management.

civiEVENT
Online event registration and participant tracking.

civiMEMBER
Online signup and membership management.

civiMAIL
Personalized email blasts and newsletters.
- Recent Blog and Forum Posts
-
Recent Blog Posts
- NTEN 2008 Donor Management Software Satisfaction Survey Results
- New in 2.2: Token hooks and Smarty templates for CiviMail
- CiviCRM 2.1.2 and CiviCRM 2.0.7 released
- REST API updates
- New in 2.2: State-Country widget, customizing event registration amounts for members
- Join Us at the 2008 Nonprofit Software Development Summit Next Week
- Billing Information Improvements for 2.2
- In the thick of CiviCase pre-alpha
- CiviCase Progress Report
- Mailing list subscription forms in Drupal blocks
Recent Forum Posts
Make your Voice Heard
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.
- lobo's blog
- Login or register to post comments






Go for it
Makes perfect sense. Definitely go for it. It would be interesting to share with the community the stats you gather.
Just do it!
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.
Good idea
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
This is great
It would be great info for admins and developers to see too. If payment processor X is only being used by 5 sites, then maybe it needs a bit more testing before I'm comfortable using it on my site.
--
Dave Hansen-Lange
Web Developer
Advomatic LLC
http://advomatic.com
Hong Kong office