in reply to Why PM needs web stats
I believe your request for stats was because you were using fancy CSS for sizing/positioning and wanted to know if the number of IE users was small enough that you could decide to just break the site for them and not care. This puzzled me because it was in the context of you writing a "mobile" version of the site. I didn't think "old IE that sucks at CSS" was an option on a "mobile" device. But I am closer to the opposite of an expert on such matters.
how many people are using ... Android? and which versions?
If I have to cater to not just "Do $this specifically for Android devices" but to a granularity of different versions of Android devices... Well, I won't continue doing that type of work for very long. Seems a very painful way to get stuff done, to me. And I haven't had much problem getting stuff done without wasting my time on such stats.
Considering the feedback I have received to drop IE support, how many people are using IE?
My feedback is not "drop IE support". My feedback is to stop doing things that require a bunch of fancy work-arounds in order for them to work in IE. I don't particularly care if only 1% of our visitors are using IE of old enough vintage to cause problems with using CSS for sizing / positioning, if some of those 1% are long-time users (that perhaps like to use PerlMonks at work on a system where they have very little affect on what browser they can use). Unless the stats said "Nobody has used IE to access PerlMonks in the last 6 months", then the stats aren't going to make me feel comfortable breaking the site for IE. So I wasn't particularly worried about jumping through the hoops to get recent user agent string stats.
How long do users stay on PerlMonks?
The marketing department has been pestering me about that for months.
Are some pages slower than the rest of the site?
Duh. But I don't use browser-based load times for optimizing site performance. It's not really a highly effective way to approach it here. Oh, I've worked with people who built sites that use tons of javascript and load lots of ads from lots of different ad servers and some of those people even created some pretty great tools for getting fine-grained and accurate measurements of what was taking up time loading the web page. And they had a lot of hard work identifying ad servers that were only sometimes really slowing down the page, etc. Nearly none of that applies to PerlMonks and the tiny bits that do are nearly out of my control anyway.
Also doing some short term heatmap testing would help a great deal too.
Marketing is also very concerned about our conversion rate. ;) I'd be more interested in heatmap testing after some actual competent design was applied to site navigation and implemented. Getting stats for optimizing a dysfunctional navigation system would help you tweak it to be slightly more effective of a dysfunctional navigation system.
- tye