We’re currently considering adding analytics to Waveform primarily for the reason of understanding how people use the app better. Doing surveys and asking on KVR etc. is an ok first step but only exposes you to the small minority of users who can either be bothered to reply to a survey or have enough courage to enter KVR…
It’s really important to find out how the majority of users use the app.
For example, one thing we really want to know is what features people actually use. There’s literally thousands of things people can do in our software and if we find everyone is using the new MIDI pattern generator then we put more effort in to that. Similarly, if we find no one ever uses another feature we can either think of ways to improve it or avoid focusing on it.
Automatically providing details about crashing is also incredibly useful. Having one loud user on KVR shout that a particular plugin is crashing the DAW is one thing, finding out there are thousands suffering from another that’s giving our app a reputation for crashing is another. It also means we can identify and fix these things before we get bug reports.
There’s also really simple things like what colour schemes are people using the most? Do they prefer the light or dark ones? Do they change them much or stick with one? How long do people use the app for? are there specific things that a user does then closes the app out of frustration?
For us, analytics isn’t about collecting personal or marketing information, it’s about finding out how people use the app so we can improve it.
We will always be transparent out the information we collect (providing a way for users to view it) and of course enabled them to opt out (or maybe opt-in).
To be honest, I think some services don’t even allow you to collect personal information so it’s not like you can data mine email addresses or even names. Everything is anonymised with a rough geo-location the most you can get (don’t quote me on that though, I’ve not fully looked in to it).
Have a look at the statistics collected by Unity to see the kinds of useful things you can determine https://hwstats.unity3d.com/. The basics like this are really useful for determining what platforms/architectures/OS versions to support, it’s useful for determining what hardware you should concentrate testing on in order to best represent the demographics of your users. In a plugins case returning the DAW and version would also be useful metrics. All of the above would be useful data for the JUCE team too, as it gives them good data as to where it’s best to concentrate their development efforts.
I do think that either the collection of such data should be made extraordinarily clear to the user or if you have an opt in/out system it should always be that the user has to forcibly opt-in, anything else is IMO dishonest. I think it’s very important to also make an effort to ensure the data collected is done anonymously and every effort should be made to ensure there isn’t a way to trace data back to a specific user.
Other data that could be useful in a more advanced implementation would be things like what controls someone interacted with and for how long, essentially a heat map of usage, this may help you gauge where users are getting most stuck, or identify controls that are almost never being used.
After having an open conversation with them we’ve just started collecting data with our beta team. I don’t believe we’ve had any negative feedback to date, and there was lots of feedback, just all of it was positive.
Yes. The analytics gathered from the website is primarily to inform the web team about how to improve the website. However, it can also tell us things like which documentation page is the most frequently visited and which tutorial people spend the most time on - both of which give the JUCE team more information about how people are using the library.
Don’t underestimate the power of analytics. A famous example is the design of the game Portal. Here many players were taking much longer to complete a certain level than expected, and many were not completing it at all, because an important feature was placed on the ceiling - if you didn’t look up then you were going to get stuck. In-game head tracking can pick this up, but to reveal the cause of the problem you have to anticipate what the problem was when questioning your users. If you don’t ask “Did you look up?” then it’s unlikely that the information you gather will be very useful. Analytics avoids this problem and you can get feedback immediately from a properly randomised section of your user base, not just the section who are willing to respond to a survey.
… I was bashing out a list of things where analytics can help, but Dave and Anthony composed their responses much quicker than me. In short:
The believe that to the collected data is anonymous and the access to it is randomised truly naive.
It’s about getting the user to get used about it, that every step he takes on his local PC being transmitted to google or another so called “trusted company”, of course to “improve things”.
@jules If there a people who having real concerns, do you think its a good style to make this kind of sarcastic comparisons?
But if i really think about it, juce::RootkitInstaller, is somehow very suitable description to that which is introduced here, it does something which is really hidden for the average user.
Also its a big security problem, what happens if there is a man in the middle between the application and the analytics server, uses some kind buffer overflow (undefined behaviour) to reject user data from the PC. All JUCE plugins would be affected, because they all use the same interface.
Well, to be honest, the “visibility” of this behavior for the end user and his awareness only depend on the implementor of the end-user application, not on the developer of the library.
Without extreme examples like Rootkits and the like, it is already very well possible with JUCE to make an application that opens the computer’s microphone and listens to all the conversations happening in the final user’s room, without his consent.
Should JUCE developers take measures to avoid that as well?
That’s true, but that is also the case in the marketplace module (now juce_product_unlocking), and for the in-app-purchase feature.
In those, it is even “worse” because to perform their operation, data is associated with specific users by design.
If one does not want to collect user data, neither in detailed nor in aggregate form, it’s entirely possible to not use those features and that’s all
For that, I think it is mandated by the law to put an appropriate checkbox where the user must express the explicit content to the gathering of such data.
If a “malicious” developer desires to collect user information without him to know or notice, the instruments are already there (sockets, URL class, background threads), it’s not the absence of this analytics module that will stop him.
Yes, because people take things way too seriously!
App developers have always used analytics, and will do regardless of what we put in the library. In my experience I’ve only ever seen it used to help companies figure out how best to guide consumers to use their apps more effectively, because that’s the thing that matters. Anyone who bothers to use this stuff will have thousands of users, and won’t be remotely interested in individuals, just in the percentages of people who manage to click on a button or page, etc.
When the government officials contacted us and asked us to add these classes in order to help them gather more information about (REDACTED)'s movements and online activity, we did think twice, but… oops, I’ve said too much…
That still looks a liiiitttle sarcastic, I’m sorry, but that’s just the impression that it gives by just reading it. However, I’ll take your redacting intention as well-meant and won’t go on on that topic.
Plenty of people have addressed the concerns with thoughtful, serious answers. No point in me repeating the same stuff.
And to be honest, I struggle to find much patience for anything that sounds like paranoia or conspiracy theories. I’m sure conspiracies exist, but this isn’t one. It’s just some simple classes to help some of our users do what they’d have done anyway.
