CMS browser/os usage statistics

77 views
Skip to first unread message

Nedmas

unread,
Mar 4, 2016, 4:25:38 AM3/4/16
to SilverStripe Core Development
Hi everyone,

With the recent discussion about dropping browser support for SilverStripe 4, I was reflecting that it would be awesome to have better statistics on SilverStripe CMS browser/os usage. Then I thought well why don't we collect this information ourselves!

I propose we add a feature for collecting usage statistics to the CMS module for SilverStripe 3.x and up. I see this being an opt-out feature, that the first user to log into the CMS gets prompted to agree or opt-out and all admin users can change the setting in SiteConfig.

I'm happy to commit to building this feature, however I think that it would make most sense for SilverStripe Ltd. to collect and retain the data.

What do people think of this idea. Is it useful? Are there any problems with my suggestion? Would SilverStripe Ltd. be ok with collecting data?

Mark Muller

unread,
Mar 4, 2016, 10:00:12 AM3/4/16
to SilverStripe Core Development
Interesting, don't they ask to collect install data already?

Not sure some of my clients would be keen to know that some monitoring was going on in the background, how do you explain the need to abate their fears of data protection.

It would probably be a good module though and that is how I would prefer to install it. Where necessary or allowed even.

Patrick Nelson

unread,
Mar 4, 2016, 10:17:00 AM3/4/16
to silverst...@googlegroups.com
Also, if anyone is considering doing this, please be conscious of the possible incorporation of session data or "security tokens" in query strings which, if logging page loads, could slip into analyticis (albeit maybe not a high risk, but worth considering). I've seen redirects happen behind the scenes which will need to make use of these one-time-use tokens (I believe) and, since most requests to the back-end are via PJAX, anyone patching in an analytics layer may watch AJAX requests and log them as page views, so... something to potentially be mindful of (or to avoid completely, to be honest).


--
You received this message because you are subscribed to the Google Groups "SilverStripe Core Development" group.
To unsubscribe from this group and stop receiving emails from it, send an email to silverstripe-d...@googlegroups.com.
To post to this group, send email to silverst...@googlegroups.com.
Visit this group at https://groups.google.com/group/silverstripe-dev.
For more options, visit https://groups.google.com/d/optout.

Nedmas

unread,
Mar 4, 2016, 10:21:55 AM3/4/16
to SilverStripe Core Development
Interesting, don't they ask to collect install data already?

Yes they do indeed, however I believe this just covers server details (e.g. Apache, IIS, Nginx). I'm proposing we collect details of the Browsers/Operating Systems that people are using to access the CMS.
 

Not sure some of my clients would be keen to know that some monitoring was going on in the background, how do you explain the need to abate their fears of data protection.


Absolutely we need to clearly communicate to end users what we're doing and the benefits to them. I was thinking that all the data we collect would be anonymous so there wouldn't be any legal data protection issues.
 

It would probably be a good module though and that is how I would prefer to install it. Where necessary or allowed even.


Although this could be a module I'd argue it defeats the purpose. The purpose is to collect accurate real world usage stats to enable the community to make better informed decisions related to supporting browsers in the future. Such stats are effected by the quantity of data, the less we have the less accurate they are. So making it part of the CMS module would, hopefully, provide more accurate stats than making it a module.

Jonathon Menz

unread,
Mar 6, 2016, 10:28:44 AM3/6/16
to SilverStripe Core Development
This would be interesting information to know I think. Could be as simple as hot-linking an image within the CMS and collecting client stats from the image requests? Could maybe set the cache lifetime to 1 day to ensure we get repeat hits, but not too many. That could give us some basic browser info with hopefully limited concerns about security, and we could allow disabling via config.

I don't think we should allow per-user configuration for something like this, more likely to be an organisation level decision and in that case I think this should be a developer setting. We generally try to keep the CMS free of configuration so it's a safe space for content editors.

Ingo Schommer

unread,
Mar 6, 2016, 2:39:58 PM3/6/16
to silverst...@googlegroups.com
We collect information about your PHP version and installed SilverStripe version through install.php, but that's it - no browser stats.

I'm not sure if more accurate browser stats would greatly influence the discussion about SilverStripe 4 browser support though.
There's always going to be a small minority of legacy browser users, but those tend to be fairly significant clients for development agencies (enterprise!).

I see the main benefit in CMS analytics as insights into how SilverStripe is used, and guide our feature prioritisation.
For example, how many people use the batch system in admin/pages? How many pages are batch published on average?
How many pages, files and other objects does a project contain? Would be great to get anonymous quantitative data on that.

This is going to be a sensitive topic, particularly opt-out vs. opt-in, and per-user or per-installation.
We'd obviously need to restrict us to anonymous and sanitised data.

The setup of this won't be too hard, assuming we use an existing product like Google Analytics with custom events.

What do others expect to learn from this data collection?


--
You received this message because you are subscribed to the Google Groups "SilverStripe Core Development" group.
To unsubscribe from this group and stop receiving emails from it, send an email to silverstripe-d...@googlegroups.com.
To post to this group, send email to silverst...@googlegroups.com.
Visit this group at https://groups.google.com/group/silverstripe-dev.
For more options, visit https://groups.google.com/d/optout.



--
Ingo Schommer | Solutions Architect
SilverStripe (http://silverstripe.com)
Mobile: 0221601782
Skype: chillu23

Jonathon Menz

unread,
Mar 6, 2016, 2:57:44 PM3/6/16
to SilverStripe Core Development
I'm not sure if more accurate browser stats would greatly influence the discussion about SilverStripe 4 browser support

I wouldn't think so either - but it could help us to make informed decisions about SilverStripe 5 :) "The only stats that matter are your own" right? In the case of the CMS it would be great to have data specific to SilverStripe CMS use as opposed to relying on generic worldwide browser use stats as these could be wildly different. Particularly since as you've noted, the minority of legacy browser users could actually be a majority in this limited context where me may have a high number of users in corporate settings with restrictive IT policies.

I agree more in-depth insights would be great to have too, as long as it's safe, transparent and can be disabled.

Nicolaas Thiemen Francken - Sunny Side Up

unread,
Mar 6, 2016, 3:16:05 PM3/6/16
to silverstripe-dev
In order to get representative data, you don't need to collect "everything".  You could pick 30 dev companies at random and ask them to randomly pick three sites.  From there you could look at those sites for stats for a few days to get an idea of the world-wide picture of users of SS sites.... (sort of thing). 

Paul Clarke

unread,
Mar 6, 2016, 4:25:58 PM3/6/16
to SilverStripe Core Development
I've designed a fair bit of the UI for SilverStripe 4 and it is hard to advise on a certain direction without any data to backup decisions being made. I try to use physical testing with users as a guide but you can't test everything all the time and often when an opinion is needed there is no time to do physical user testing. It would be great to be able to get more stats so we can focus more of our attention on functionality and UI that is being used.

Hamish Friedlander

unread,
Mar 6, 2016, 6:01:55 PM3/6/16
to silverst...@googlegroups.com
I'm a bit more tinfoil hat than some of my colleagues, but I'm very uneasy about have a default-on phone home system in the CMS. I think it will significantly affect SilverStripe's acceptability to larger enterprises (as well as others I'm sure, myself included) because of the security and privacy implications.

So I don't mind having something like this, but I think it needs to be opt-in. If it's opt-out, it needs to be in SilverStripe 4 only. We want people to be able to upgrade within a major release fairly fearlessly, and adding something like this silently would impact that.

The best solution I've heard when this has come before is having an "update checker" add on module, that checks all your installed versions to make sure they're up to date & have no security issues. Since this module has to phone out _anyway_, it's more reasonable to also integrate statistics collection into this .

Wordpress has a phone home system like this for update checks that was opt-out, and it caused some controversy at the time (http://www.wired.com/2007/09/wordpress_update_causes_privacy_controversy/) - although that's 9 years ago now. The auto-updater in Wordpress also helps reduce the number of hacked Wordpress installations a lot (yes, it could get worse than it is :).

(Side note: I hate seeing dates that look recent and realising they're from almost a decade ago).

As far as "user or developer enable-able", it probably needs to be developer enable-able, since most larger organisations wouldn't give authority to random CMS users to opt-in to this sort of collection. The first user won't always happen to be someone that has authority for the entire system or all users.

Hamish Friedlander
SilverStripe
http://www.silverstripe.com/

Sam Minnée

unread,
Mar 6, 2016, 8:43:16 PM3/6/16
to SilverStripe Core Development
 
I'm a bit more tinfoil hat than some of my colleagues, but I'm very uneasy about have a default-on phone home system in the CMS. I think it will significantly affect SilverStripe's acceptability to larger enterprises (as well as others I'm sure, myself included) because of the security and privacy implications.
So I don't mind having something like this, but I think it needs to be opt-in. If it's opt-out, it needs to be in SilverStripe 4 only. We want people to be able to upgrade within a major release fairly fearlessly, and adding something like this silently would impact that.

I like the idea of coupling this to some sort of tool for checking whether an install's modules are out of date. That way, it's opt-in with a clear benefit.

Paul Clarke

unread,
Mar 6, 2016, 8:51:54 PM3/6/16
to SilverStripe Core Development
+1

Gregory Smirnov

unread,
Mar 7, 2016, 6:15:07 AM3/7/16
to silverst...@googlegroups.com

So I don't mind having something like this, but I think it needs to be opt-in.

 

We cannot have and allow any uncontrolled requests to third-party sites in our environment. So *please make it optional*.

For the statistics purpose, we use latest FF and Chrome browsers and never IE to access CMS.

 

Mark Muller

unread,
Mar 7, 2016, 11:36:14 AM3/7/16
to SilverStripe Core Development


On Sunday, 6 March 2016 23:01:55 UTC, Hamish Friedlander wrote:
 
As far as "user or developer enable-able", it probably needs to be developer enable-able, since most larger organisations wouldn't give authority to random CMS users to opt-in to this sort of collection. The first user won't always happen to be someone that has authority for the entire system or all users.

+1 - I'd suggest a yaml config setting in the update checker too, that way everyone could benefit from the update checks and the Corporate clients could get their developer to disable the enable-able enabling ;)

Nicolaas Thiemen Francken - Sunny Side Up

unread,
Mar 7, 2016, 4:49:01 PM3/7/16
to silverstripe-dev

I like the idea of coupling this to some sort of tool for checking whether an install's modules are out of date. That way, it's opt-in with a clear benefit.

​As soon as you do it like this, the results are going to be less reliable.  I think the key is to have a randomised (it can be small) sample. If corporates do not allow phone home systems then you will end up with skewed results. ​
 

​Would it be possible to select a few devs at random and get them to provide data from a few randomly selected sites for a week? ​To me, that will give you more reliable results?  Having said that, if IE has very small numbers then you need a large sample to get any meaningful results (in which case we may not care anyway). 

Nedmas

unread,
Mar 8, 2016, 5:03:02 PM3/8/16
to SilverStripe Core Development
I feel like there are 2 main ideas coming out from this discussion so far.

Idea 1:
  • Collection of anonymous browser and operating system usage statistics
  • Needs to provide a varied and large enough sample to provide statistically valuable data
  • Used to provide real world data when making future browser support decisions (SilverStripe 5+)
  • Potentially controversial if made opt-out

Idea 2:
  • Collection of anonymous CMS user interaction analytics
  • Used to provide real world data for helping to make design decision about the CMS
  • Probably best as opt-in and developer configurable
I think that Idea 2 has a general level of support that could enable us to make a decision to implement it for SilverStripe 4 (and potentially 3).
However, although I still believe Idea 1 to be of great value, I think that Idea 1 requires wider consultation and further discussion.

I therefore propose that a RFC is written for Idea 2 (if there's no one else I'm happy to volunteer).
And that we continue to discuss Idea 1 in this thread.

Do people think this is a fair summary?
Are people happy with my suggestions for moving forward?

Cam Findlay

unread,
Mar 9, 2016, 8:02:25 PM3/9/16
to SilverStripe Core Development
Great summary, and +1 if you want to put together a first iteration of an RFC around this. 

Reply all
Reply to author
Forward
0 new messages