| |||||||||||||
How not to figure out why people use alternativesHow not to figure out why people use alternativesPosted Feb 10, 2012 10:16 UTC (Fri) by KotH (subscriber, #4660)Parent article: Tracking users
Am i the only one who wonders why one would gather data on the users of Product A to figure out why people migrate from product A to products B,C,D? I mean, wouldn't it make a lot more sense to gather data on products B,C and D to figure out why people use those instead of A?
(Log in to post comments)
How not to figure out why people use alternatives Posted Feb 10, 2012 16:37 UTC (Fri) by KaiRo (subscriber, #1987) [Link]
If you tell us how Mozilla can easily gather representative performance, etc. data on Chrome, MSIE, and Safari users, I'm sure the metrics team will be interested. But it's a bit hard to ask users of other products to opt in to your product's improvement program...
How not to figure out why people use alternatives Posted Feb 11, 2012 0:05 UTC (Sat) by giraffedata (subscriber, #1954) [Link] I don't see how data only on the competitor would be any more use than data only on Firefox. Ideally, you'd want both, but with that not possible, data on just Firefox is pretty good too.The question of why people are leaving Firefox just boils down to why people don't like Firefox, and the imagination runs wild thinking about ways these metrics would help answer that question. About the most basic thing I can think of: if stats show half of the features you have developed are never used, you can assume that's part of why users leave Firefox. Competitors, who have market intelligence, are spending all their development money on features users want and Firefox is spending 50% of it on features they don't. Or, over time, you see most of Firefox's decline is in uses on old computers. So maybe it's because the competitors are more backward compatible. Or maybe it's harder to install on a new computer.
How not to figure out why people use alternatives Posted Feb 13, 2012 11:07 UTC (Mon) by KotH (subscriber, #4660) [Link]
Gathering data and running statistical tools over it will not give you the understanding you seek. You will be just crunching numbers and find things which can be explained somehow... but how do you know that this is actually what is happening? Or to put it short: Corelation does not imply causality!
How not to figure out why people use alternatives Posted Feb 13, 2012 11:04 UTC (Mon) by KotH (subscriber, #4660) [Link]
There is an old and tried method for this: It's called market research. There are many companies that offer services in this field. Yes, it costs money, but a well devised market research will give you a lot better understanding of what is going on in the browser market than gathering some random numbers from people without understanding what those people are actually doing and why.
I'm actually horrified by the thought that an organisation dedicated to openess is considering gathering person related data without asking the people first instead of considering other ways... Not to talk about that such behaviour is illegal in most european countries (you are not allowed to gather person related information without prior consent and have to declare exactly what data is collected, when, who has access to it and how long it is stored)
How not to figure out why people use alternatives Posted Feb 15, 2012 16:51 UTC (Wed) by gerv (subscriber, #3376) [Link]
I'm not sure that market research could tell us which SQL queries are running long, or which addons are commonly installed by people who are more than one standard deviation above average memory usage, or...
Asking users to describe the performance problems they see is one thing. Working out which bits of the code are _causing_ that is something you need built-in metrics for.
How not to figure out why people use alternatives Posted Feb 15, 2012 18:31 UTC (Wed) by deinspanjer (guest, #82864) [Link]
This proposal is not about collecting person related information. It was built from the ground up to avoid personal information. It has technical features such as using a constantly changing document identifier as well as policy features such as explicitly ensuring that the IP address and previous document IDs are not linked into the data. It provides a very clear view of the data that is collected, to the extent it even provides a tool to allow an interested user to review the data and discover potential problems or useful performance or stability characteristics about their installation locally. It also provides a means for a user to delete the information about their installation from our servers if they choose, and both the client code and the server code is available as open source.
|
|||||||||||||