Reading through the WordPress Hackers Mailing list, Nuno Morgadinho wanted to know how to track user engagement with a commercial plugin that is being developed. The metrics that they were most interested in were the following:
- how much time has the user spent playing with my plugin since plugin activation ; - what is the normal usage of the plugin (once a month? once a week? once a day?) ; - while navigating through the plugin does the user go back and forth a lot of does he follow a certain pattern?; - etc.
While the developer would like to use this information to improve the experience of using the plugin, I can already see the people with pitchforks lining up to take this developer out if were not done correctly. Thankfully, Eric Mann has already chimed in with words of warning about how users do not like to find out about third party tracking, especially after it’s already occurred without knowing about it up front. Personally, I have no problem with what the plugin author is trying to achieve as long as I have the option to say no aka, Opt-Out or more preferably, Opt-In. I’m willing to bet that most WordPress website owners feel the same way. If not, feel free to tell me within the comments of this post.
However, I have to point out that according to the WordPress Plugin Repository Guidelines, plugins are not allowed to “phone home” without the user’s informed consent.
No “phoning home” without user’s informed consent. This seemingly simple rule actually covers several different aspects:
No unauthorized collection of user data. For example, sending the admin’s email address back to your own servers without permission of the user is not allowed; but asking the user for an email address and collecting if they choose to submit it is fine. All actions taken in this respect MUST be of the user’s doing, not automatically done by the plugin.
All images and scripts shown should be part of the plugin. These should be loaded locally. If the plugin does require that data is loaded from an external site (such as blocklists) this should be made clear in the plugin’s admin screens or description. The point is that the user must be informed of what information is being sent where.
In general, things like banner or text link advertising should not be anywhere in a plugin, including on its settings screen. Advertising on settings screens is generally ineffective anyway, as ideally users rarely visit these screens, and the advertising is low quality because the advertising systems cannot see the page content to determine good ads. So they’re best just left off entirely. Putting links back to your own site or to your social-network of choice is fine. If the plugin does include advertising from a third party service, then it must default to completely disabled, in order to prevent tracking information from being collected from the user without their consent. This is the method commonly known as “opt-in”.
Note that if you do include what we consider to be “advertising spam”, or attempt to game somebody else’s advertising system, then we will not only remove your plugin, but also report your code to the advertising system’s abuse mechanism as well. We do not react kindly to spam. Don’t try it.
After reading those guidelines concerning phoning home, consider that WordPress itself phones home data without the user ever having a chance to make an informed decision on whether to allow it or not. If you have time and want to read a passionate and heated discussion centered around this very topic, I encourage you to read the following forum thread – WordPress And Phone Home, started in 2009 by Elpie. Within the thread are arguments on what should and shouldn’t be collected, how disclosure should be handled, what is and is not publicly available information, last but not least, reasons as to why what WordPress does and how it does it is ok. While I’m a big fan of the repository guidelines, I don’t understand why plugin authors have to phone home with informed user consent while WordPress can phone home without informed user consent. What’s the difference between the two?
If you’re interested in knowing what data is sent back from a WordPress installation back to the mothership, Eplie has laid out a detailed post showing exactly what is sent.
*UPDATE* According to Otto, Core, Theme, and Plugin update checks do not phone home to WordPress.org.
Note: *In my opinion*, they’re not “phoning home”. Information like PHP and MySQL version is indeed being sent back as part of the core update call, but the information is necessary information to get the proper core update response. Similarly, plugin and theme api checks send information like the plugin and theme headers, in order for the api code to be able to find the right plugins and themes to check updates for.
It is perfectly reasonable for other people to see these API calls differently and say that this is “phoning home”, and I can understand their point of view. For this reason, plugins exist to disable those update checks if somebody wants to do so.