Collecting information on users is something every program wants to do. Doing it is easier said than done.
When you build a product, you want people to use it. Obviously. But more than that, you want to know how they’re using it so you can know how to make it better for everyone. In order to get that information, you need to monitor and track your users.
I hate that.
So do most users, actually.
In the world of social media, with photos flying left, right, and center about what we’re doing and where we’re going and what we’re eating, controlling that data can make someone a king. At least, if they know how to use it.
The issue with data collection is consent.
If you have a WordPress plugin, you’re not allowed to track users without their consent. You must let them opt in. But that’s the easy part. The hard part is getting the users to understand what they just agreed to.
No one reads EULAs. We all see that license agreement when we upgrade our phones, we scroll down, and we click okay. We don’t read. While, arguably, we should, the issue is not just that we don’t read but that we’re getting too much information, and none of it really is what we needed to know.
With WordPress plugins (and you can easily reach to Drupal extensions with this), we have a unique opportunity to educate our users.
“Allow tracking. By checking this box, data will be sent to the service X in order for me to learn about usage and develop improvements.”
Simple and direct. I would even add in a link to Service X, or better yet to a page that explains exactly what is tracked. When you do this, you will be educating the user as to exactly what ‘tracking’ means.
Past the consent is the world of how to do the collection.
Size Bloat
I have a big beef with plugins that use frameworks because a high number of developers do this and make their plugins hundreds of times larger. I see, regularly, a one-page plugin where someone uses a framework instead of learning the settings API. And that’s the first issue. These frameworks for tracking are big. They can be megs of files that add more bloat to a plugin.
There’s a new tool out there to help developers track the usage of plugins. If you add that to your plugin, it’s your job to make sure it doesn’t violate any terms of use. If you add it in later, consider what this will do to people upgrading. Will people who use small, shared, hosts run out of memory upgrading your plugin because it’s now 10 megs?
Sinking Speeds
There’s another massive issue, which is the speed of the site. The more trackers you add into a site, the slower it gets. This is pretty basic logic and you’ve probably seen it from Google Sitespeed. “Your site is connecting to too many other servers.” The more sites a domain has to hit to load, the slower it is. Period.
Services have to hold up, too. If someone crashes the service because they get featured on Post Status or Reddit, then that is a part of your responsibility as a plugin developer. You’ve added in a feature. It now is broken. What happens to your users? Did you break their sites? What if they can’t reach the host because it’s blocked in China?
Full Disclosure
We’re back to this for a reason. I had a whole post about it, from the developer perspective in being upfront of who is doing the tracking in a service. But that was really about informing the person who installed the plugin. Now I want to address the visitors. When you’re tracking the usage of your plugin, you have to be clear as to what you’re tracking and specificlly who you’re tracking.
If you’re tracking visitors to the site, you have to make sure the person running the site knows, so they can make sure their visitors know. That’s their job. Yours is to educate in a clear and direct way.
Be Honest
This is really your golden rule. Be honest and up front with what you’re tracking, why you’re tracking it, what you do with the data, and protect yourself. You’ll need the legalese yes, but you should make those things human readable too.
People want to know who has their data.
Make it easy to know.
