Ask HN: How much tracking is okay?
I am personally against most kind of tracking, especially the kind of invasive tracking that Google or FB does to target ads. But what about tracking your users within your own website to find what is working and what is not? For example, is it alright to track which country the traffic is coming for and which pages are more popular for each country, or to see if any people reffered from an external link is actually buying any product? On one hand I believe this data is important for business decisions, decisions which can really make or break the business. On the other hand, I am confused how much of it is actually different than what facebook or Google does. How do judge which tracking is ethical, where do you draw the line on what's invading privacy and what's not? Or is it a black and white question where either you track or you don't without any middle ground?
8 comments
First party vs Third party tracking is a big divide.
If you are tracking on your own web site and using it for your own purposes then you can draw a boundary around it and be able to make some ethical decisions about what you do.
If on the other hand you put on a Google or Facebook tracker then you have wider issues, particularly that Google and Facebook tracker data leaks out to fourth and fifth parties.
If you are tracking on your own web site and using it for your own purposes then you can draw a boundary around it and be able to make some ethical decisions about what you do.
If on the other hand you put on a Google or Facebook tracker then you have wider issues, particularly that Google and Facebook tracker data leaks out to fourth and fifth parties.
I will tell you what is my opinion of it. Do server side logging, but you should not use analytics stuff, or read what someone entered into a form without submitting, or tracking ads, or tracking data which is done entirely on the user's computer (e.g. most traditional command-line programs and GUI programs should not use any remote tracking), etc. (You can also program the server to reduce the amount of data logged for HTTP requests with a "DNT:1" header; I have made it to not log the IP address in this case, although timestamps and amount of data transfer are still logged.)
Its pretty simple I think. You can collect, store, process, track, do whatever with data as long as that data cannot be used to identify the single individual person that produced that data.
If on the other hand the data you want to collect or track can identify a person, you should ask this person if (s)he is okay with it before you do it.
Seems fair enough to me. And it could be me your website was tracking.. or, you that my website was tracking
If on the other hand the data you want to collect or track can identify a person, you should ask this person if (s)he is okay with it before you do it.
Seems fair enough to me. And it could be me your website was tracking.. or, you that my website was tracking
One thing to watch out for with this reasoning is that there are a lot of data points which are innocent by themselves, but can produce a high-accuracy fingerprint when combined together. For example, browser, language, screen resolution, timezone, etc. By themselves none of these would identify anyone uniquely, but the combination might be enough to target a single user with very high accuracy.
Generally my line is server-side vs client-side.
It is unknowable to me what data you're saving on the server side using information that I willingly sent to the server as part of normal use (eg. my ip, what HTTP calls I'm making).
It's when you start manipulating the client into sending you additional data that things become a problem. This I _can_ see, and it amounts to an attempt to trick my own user-agent into revealing information that should be private. In other words, your client-side code is now officially malware, and I will block it if I can or just leave the malware-infested site if I can't.
I could make an exception for tracking that is a) high value, b) aligned with my goals as a user, and c) as respectful as possible of my privacy (eg. anonymising values, only taking what info you need).
The b) condition there is most nebulous - I'm mainly thinking of things like reporting client-side javascript errors. This is aligned with my goal of your site being bug-free so I can use it better. Another example would be an (opt-in!) recommendation system that I find valuable. What would NOT be an example of this would be tracking of my actions on the page in order to optimize the chances that I'll engage with the content. Engagement is your priority, not mine.
It is unknowable to me what data you're saving on the server side using information that I willingly sent to the server as part of normal use (eg. my ip, what HTTP calls I'm making).
It's when you start manipulating the client into sending you additional data that things become a problem. This I _can_ see, and it amounts to an attempt to trick my own user-agent into revealing information that should be private. In other words, your client-side code is now officially malware, and I will block it if I can or just leave the malware-infested site if I can't.
I could make an exception for tracking that is a) high value, b) aligned with my goals as a user, and c) as respectful as possible of my privacy (eg. anonymising values, only taking what info you need).
The b) condition there is most nebulous - I'm mainly thinking of things like reporting client-side javascript errors. This is aligned with my goal of your site being bug-free so I can use it better. Another example would be an (opt-in!) recommendation system that I find valuable. What would NOT be an example of this would be tracking of my actions on the page in order to optimize the chances that I'll engage with the content. Engagement is your priority, not mine.
Your points a) b) c) is good (and so is the part at the beginning about server vs client, which is what I mentioned too in my other comment here), but I may also add: d) do not make too many extra requests or large requests.
(It is also my opinion that client side code should mostly be avoided, or sometimes optional. There are cases where it is needed, but for ordinary documents it isn't needed.)
(It is also my opinion that client side code should mostly be avoided, or sometimes optional. There are cases where it is needed, but for ordinary documents it isn't needed.)
As for anything I make. It's all fairly anonymous.
I really just want to know how people are using X, Y, or Z so I can make it better. I don't care about demographics or identifying anyone as much to just know if the application is working / how it is being used, so any logging or such is. As far as what I do as far as gathering that information is all pretty manual / rudimentary.
Granted, this is all just for my personal projects and work is a SaaS product that customers pay for that isn't tied to ads or anything outside our systems, so that means I've got the option to just not do those things.
I really just want to know how people are using X, Y, or Z so I can make it better. I don't care about demographics or identifying anyone as much to just know if the application is working / how it is being used, so any logging or such is. As far as what I do as far as gathering that information is all pretty manual / rudimentary.
Granted, this is all just for my personal projects and work is a SaaS product that customers pay for that isn't tied to ads or anything outside our systems, so that means I've got the option to just not do those things.
I think it can't go unsaid that the tracking data and the conclusions you draw from it are useless without the second step which is the actions that emerge from those conclusions. i.e. Lots of people are visiting the second page of process x but not the third - tracking data. There is something wrong with the transition between those pages or the 'flow' of process x - conclusion. Conduct observational/interview testing to determine why - action.
My point is why weren't you doing the action in the first place? Did you actually need the tracking data to tell you that?
My point is why weren't you doing the action in the first place? Did you actually need the tracking data to tell you that?
I think most tracking within your own app is okay. Its what you do with that info is subjective. I.E Sell it vs writing more code based on the data the tracking provided.
If you dont track what users are doing on your own platform how do you know what they are doing, and how they are using it? You dont.
If you dont track what users are doing on your own platform how do you know what they are doing, and how they are using it? You dont.
none. tracking makes you into a cattle. a dumb product to profit off of.