rethinking analytics and social media sharing

2016-01-16 · Computing

I find myself continuing to rethink the placement of analytics and social media sharing scripts on the sites I control. Over recent years, this behaviour has become almost automatic for me: create a site or web application, add Google Analytics scripts, add AddThis buttons to facilitate sharing on Twitter and other channels. But I’m realising more and more that we’ve somehow got into a situation where privacy-related decisions are often taken with far too little time for reflection, sometimes supported by the all-too-weak argument that everyone else is doing it. For some parties, I suspect we might have got into this position by design, but for others, it might be more a case of not having adequately thought about it, of not having fully considered what we might be giving up as well as gaining.

In November 2015, I removed Google Analytics and AddThis from Tunefl, my open-source LilyPond mini-score engraving and sharing service for musicians. I also began a more serious review of other sites I’m involved with. Today, I also removed the Twitter embedded-tweet scripts from this blog. Sure, it means that my shared photos don’t auto-display, and that it’s more work for someone to share any content they find interesting (!). But more important to me is that the site is more respectful of users who run JavaScript, and that privacy tools such as Privacy Badger indicate that my site doesn’t appear to be participating in tracking-related activities. And it’s also faster, because of avoiding the need for the remote JavaScript load.

Regarding analytics, the removal of Google Analytics from my site isn’t to say that data isn’t important to me. High-quality data can lead to high-quality decisions (although there is no guarantee of this). But with data collection comes great responsibility. I haven’t had chance to fully review the previous solution. And it’s not even the complete picture anyway, missing not only many non-browser visits such as by web crawlers, but also visits from users who have JavaScript disabled or have privacy-related extensions activated (as often do I). To get a fuller picture of the data, I could independently parse the web server logs (ignoring here the potential privacy implementations of keeping those logs in the first place). I’m not actually doing that at the moment, but it’s certainly something I’ll be thinking more about.

Some might think it would have been better to have kept things as they were until I’d spent more time reviewing the situation and getting alternative solutions in place. But I think it’s often best to set out in the approximate direction you realise you want to go, even without having the whole route planned. Otherwise, it’s far too easy to stay exactly where you are, and keep putting changes off until another time. For a client project, I might not necessarily advise the same approach; that would need careful consideration (and wouldn’t just be my decision, obviously). But really, in the bigger picture, my blog and open-source sites really aren’t that important—not enough to justify doing something I’m uncomfortable with. For the meanwhile, if that means I have less insight into visitors, I think I’m actually okay with that.

I’m not saying I won’t continue to use such analytics and social media sharing scripts in the future, even for sites I don’t have to compromise for, but that at least I would have given myself more time to consider the options carefully before doing so, and, hopefully, to find a solution which yields benefits without potentially contributing negatively to privacy. I’m not necessarily recommending that others follow suit; I think what’s most important here is to think carefully about these things rather than sleepwalk into them, and, if you have the opportunity, to err on the side of caution if your present self is not sure what to do.