I am currently watching all Star Trek episodes. I started with Next Generation, of course (you can now guess my age) and will go through DS9 next. I can already say that TNG is still my favourite part of Star Trek, by far.
A lot of episodes could be a blue print for how web analytics should ideally work: the enterprise crew find some phenomenon that puzzles them or presents a threat. They analyse the situation and usually raise more questions until they eventually find the explanation and then fix the issue.
This is pretty much exactly what a web analyst could be doing. And funny enough, it is also how development can work, except that rather than exploring the unknown, both web analyst and developer handle requests from business users and other stakeholders.
For the web analysts, the “TNG blue print” applies on many levels:
- Analysis of data in the context of the business goals
- Analysis of the data from a perspective of data quality
- Improvement of analytics tool deployment
- …
In the context of this blog, the first level doesn’t matter that much. Don’t forget that it is what web analytics is paid for, though! And through the other two, you can support your friendly marketer or web analyst making the most of the tool!
Let’s see what we can learn from Star Trek!
Data Quality
The quality of the data is a question that does definitely concern you.
It is likely brought up by business users or web analysts, and you will probably be asked to contribute to the analysis. You will also be part of the solution. Somewhat like Geordi La Forge, you will support the analysis with technical backround and then put a fix in place.
The obvious thing here is that just like Geordie knows his engines better than the woman who designed them, you will (or at least should) know the internals of the analytics implementation better than anyone else in your company.
With this background knowledge, you can quickly home in on any issues.
The biggest motivation behind this blog when I started it was to help a lot of you developers to become the La Forges of your respective organisations.
So next time someone is doubting the data or pointing out obvious flaws, try compensating for the discrepancy by re-aligning the tracking variables with the Solution Design. No, wait, that almost makes sense. How about try compensating for missing orders by aligning the core data with the — oh whatever.
Improvements
You can like Wesley Crusher or not. He often comes up with suggestions that seem beyond his age and experience. This is actually a pretty good parallel to what you as a developer could do when you work with web analysts.
Think about it: you would never expect your friendly marketer to walk up to you and suggest a really nifty CSS trick. You would probably freak out if he sat down and said “hey, have you seen this Javascript snippet on that blog? Couldn’t we use that to …?”
But that is what Wesley Crusher is doing constantly. In the beginning, people dismiss him, but after a couple of hits, they start listening. And since he’s insanely bright, they quickly respect him.
I’m not saying you are Wesley or that you have to be an overachiever.
But I do think that learning about the context of your work helps a lot!
When you start understanding your friendly marketer or web analyst, you will have two extremely valuable advantages:
- You can look at their requests from a more abstract level
- You can start thinking ahead
The abstraction will help you prioritise and make sure you do not get bogged down by tactical issues. Seeing the big picture will also very likely help you identify the best way of doing things.
And if you think ahead, you can a) surprise your friendly marketer with solutions to problems they didn’t even know they had, and b) make your own life easier in the process.
Learning from each other across the fence is a huge win-win for everyone.
I know – making the connection with Wesley Crusher, I might not have sold this one very well… but if you look at it from inside, Wesley had a pretty profound effect on some missions and he moved up in the world due to that.
Next Generation
Star Trek doesn’t seem to work without some outsider on a quest. TNG had Data, the android who wants to be more human. In DS9 we saw Odo sleep in his bucket and try to find out who he was. And VOY introduced 7of9, a retake of Data, badly done. Spock, from TOS, still is a legend even in movies today.
Can Data serve as a role model for a developer or an analyst?
I think so.
The main difference between Data and his shipmates was that Data had no feelings and approached everything from an analytical point of view.
Given how the results of web analytics can sometimes be used in decision making high up the chain, it makes sense for both developers and analysts involved in finding and providing that data to do the same.
Kevin Hillstrom recently posted a very personal account of why you should be “neutral”: Testing and Consequences. From this experience on, he decided to follow the “Switzerland Approach”.
We think that makes sense, and Data would most certainly agree.
To sum it all up:
You are currently doing a job similar to Geordie La Forge. You can change to be more like Wesley Crusher if you want to be respected by the business users, but be sure to approach analysis like Data so you don’t get burned.
Hm.
Put into a single paragraph like this, the whole thing sounds horribly wrong. Maybe using Star Trek as an analogy was not a good idea after all. What if I loop the core message through a cross-linked perception modification algorithm in order to re-establish structural integrity? … Captain! We’re approaching maximum inverse relevance! I won’t be able to sustain this level of buzzwording much longer!
Soothing voice of Picard from the off: it’s allright, Geordie, shut it down.
That was close.
One thought on “The “Star Trek Blue Print” for Web Analytics”