Today, OLC Innovate leadership requested feedback from attendees on the issues of data collection and privacy raised by (among other things) the attendee tracking badges and session check-in procedure. I replied in email but am republishing it here, lightly edited:
I’m really glad to see you considering privacy issues, and mostly wanted to just thank you for that. I think OLC could lead the way here.
I felt the badges and the system of checking people into rooms was invasive and took away from the otherwise friendly feel of the conference. I don’t know if I want vendors, or OLC, or my boss knowing which events I attended and which I didn’t – and I certainly don’t want that data on a bunch of USB-based unsecured devices. What we have learned from the past decade is that you can’t really know how data will be misused in the future, and consent on data isn’t really meaningful because when data gets combined with other data it becomes toxic in ways even engineers can’t predict.
It seems to me that you have a few small pressing questions that you could answer without the tech. What sessions do people attend? Are there subgroups of attendees (managers, faculty, librarians) which seem to have less desirable session options?
Even if you still want to use the tech, if you scoped out the specific questions you wanted to answer you could do much better. You could not only capture that info in a less potentially toxic way, but you’d be more likely to use it in useful and directed ways. As just one example, if you replaced unique ids on the badges with a few basic subtypes – one code for managers, one for faculty, etc. – you would not be collecting personally identifiable information about people, but you would meet your goals. If you centralized the collection of information by job type you could also provide that information to speakers at the beginning of their session in ways that would be far more useful and safe than any undirected analytics analysis.
In short, do what we tell faculty to do in assessment of instruction:
- Think about a *small* set of questions you want to answer
- Collect only the information you need to answer those questions
- Answer those questions by creating aggregate findings
- Delete the raw data as soon as retention policy allows
You think you want to answer a lot of questions you don’t know yet by rooting in the data. Most of what we know about analysis tells us you’re far better off deciding what questions are important to you before you collect the data. I would go so far to share with attendees the five and no more than five questions that you are looking at answering each year with the data you collect, and explaining all data and its relation to those questions. After you answer a question a couple years in a row, swap in a new one.
(I’ll add that for all these issues there needs to be a meaningful opt-in/out. I would suggest that the de-individualized code be a removable part of the badge).