The costs and benefits of tracking scripts - business vs. user

Jeremy Keith triggered an interesting IndieWeb/Twitter thread last week, by posting:

Too many businesses treat analytics and tracking scripts as victimless technologies—they only see the benefits (in data acquisation) without understanding the costs (in performance).

First of all: “victimless technology” is such a great term; my brain immediately links this entire discussion with Cade Diehm’s work on “weaponised design”.

A response by Michael Scharnagl caught my interest, as it is an elaborate example of the cost/benefit audit I regularly call for when privacy-relevant decisions are to be made in design projects.

I took the freedom to arrange Scharnagl’s well-argued points - you really should read his entire assessment - in a matrix table to visualize his point:

I am having a hard time seeing the business benefits weighing in more than the user cost (at least for those many organisations out there who rarely ever put that data to proper use). After all, keeping the costs low for the user should be in the core interest of the business as well.

…and this is also why I am (granted: on a case-to-case basis; this cannot be generalised) often having a difficult time when even the most invasive tracking is justified with “legitimate interest” as the legal grounds for processing under GDPR.

Scharnagl further adds a list of “best ways to handle tracking scripts […] from best to worst”:

1. Don’t use any tracking at al
2. Only track on the server-side
3. Only use self-hosted tracking scripts
4. Load third-party tracking scripts
5. Load several third-party tracking scripts
6. Load all the third-party tracking scripts
7. Load all the third-party tracking scripts before anything else

Great privacy-centred and performance-oriented design thinking! It is just too easy to not ask oneself these questions and instead tell those who suggests evaluating tracking practice that it is all absolutely business-critical. In many cases, a lot of it is not.

I like Jeremy’s strategy to deal with this in his communications:

In meetings, in Slack, in emails, and any other discussions, I’m making a conscious effort to use the word “tracking” instead of “analytics.”
A small Lakoffian intervention to remind myself of what these scripts mean for the user.

PS: On the more technical aspects of this equation, Jeremy also links to the ALA article Breaking the Deadlock Between User Experience and Developer Experience by Jason Lengstorf, who discusses the same pay-off from a mostly performance-oriented “user experience vs. developer experience” perspective; a great read as well.