Why bother collecting clickstream data? Good question.

To answer a question with another question: What are you going to do with it?

“I’m going to store it in a big database, I’m going to collate it up and make metrics out of it etc.” Not nearly good enough.

“I’m going to look at it, I’m going to compare it to other data, I’m going to report it back to the business.” Still not good enough.

“I’m going to analyse the data, answer business questions and suggest changes.” Better, but still not good enough.

Not one of the above actually changes anything. They’re the means, not the end.

If you’re going to collect clickstream data, have a clear understanding of how it will lead directly to change.

The starting point is; how will I use this data to improve the customer experience? But it quickly requires more detail, like:

  • Who’s going to evaluate it?
  • Who’s going to decide what change to make?
  • Who’s going to implement the change?
  • What percentage of the base should we deploy the change to?
  • How much will the change cost?
  • How long will the change take?
  • How do we evaluate success?

If you don’t have clear answers to these questions and more, getting that extra bit of code deployed to collect scroll depth is the least of your worries.

I mean, ok, reality check: in most businesses, we already collect clickstream data. There’s nothing wrong with that; this isn’t a call to immediately stop what we’re doing.

But when we tackle a new project, we should try to think about clickstream data in terms of real deliverables, same as we would any other aspect of the project. Only collect what we’re going to use to change something.

This should strip our requirements back to the basics – a minimum viable product for click-stream data collection, focussed on value drivers. Less development time, lower costs, real outcomes and a reduction of technical debt. Hooray!

At the end of the day, without follow-through to deliver something real, what’s the point of collecting data at all?