How hard can defining an Analytics event be? Really?

All of my Analytics courses and lectures begin with me explaining why having many (over 100) Analytics events is bad - very bad. There are many reasons. Thus, I spend a full lecture explaining them. But this time I wanted to actually show, on a real product, how hard defining an event really can be. Or rather how easy it is to not define an event well at all.

Volunteers? Yes, you in the back? Couldn’t catch your name - Spotify, is it?

So, let’s take the most basic event we’d want to track if we’re a PM at Spotify - Play a song: 
Let’s define the event:
Name: “Song played”. 
Trigger: user clicks on the play (triangle) button. 
Yay! Now we’ll know exactly how many songs were played.
Mission accomplished - Yessss! Moving on to define the next 500 events. 
But wait a minute…

Maybe we should add a few properties to better enrich the data set

Properties:
Song name - that’s easy. 
Band, album, genre, release year, song duration, explicit content, top chart ranking and much more…  
Now that’s rich! Moving on to define the next 500 events (although now I realize this might take me a few days…).

Well… I actually might need some context to go with that…

Many times the event is meaningless without proper context. There’s a reason why it’s called ‘Behavioral Analytics’ - we want to analyze behavior, not just show a pretty graph.  
Maybe it’s important to understand if this is the 1st/10th/50th song played today - as they might represent very different behaviors?
Maybe it’s also important to understand if this specific song was played by my specific choosing, as part of a playlist I built, a playlist I found or if it was chosen for me by Spotify’s engine. Just because I might be interested in understanding how many Spotify suggestions are played.
And what about the context of whether this song was played by a free or premium user? I can’t accurately tell if the user played a few songs for free and then turned premium. I only know the current user status…

But, hold on a sec - What if the user hated the song and skipped it after 5 seconds?

That’s a totally different experience. That can't account as a good ‘song played’. Practically, to truly understand how each song was experienced by the user I must wait (at least) until the end of the song.
How long did the song play, out of its full duration? Was it skipped? Was it favorited? Was it shared? Did the user interact with it (FF/RW, viewed lyrics, watched video, lowered volume)?
This different perspective on context could allow me to understand much more about the user’s experience, behavior and intent.

Come to think of it, most songs are played without even pressing ‘play’

So it looks as though we’ve defined the wrong trigger or even the wrong event (‘Song played’ needs to fire only when the song has STOPPED playing). Or maybe we need 2 different events… 
Now let’s consider doing that for all 500 events :-(

Having this article as a good answer for the above quote, let’s move on to - what should we do? . 
Unfortunately, that’s always more complicated (remember I mentioned the full lecture on the subject…). But if I was to leave you with just one point of advice, it would be to focus on the question “what is truly important for us to understand about our users’ behavior?”, which must far precede “what do we need to measure?”

We will continue exploring this subject, even trying to give a generic answer to the “what to do?” question, with the disclaimer that it’s not going to be easy to put in writing. But that will have to be in my next article.. 
Now excuse me while I assist solving that exact dilemma for a dear client :-)

Yoav Yechiam is a partner at the Product Alliance, a boutique consulting firm specializing in Strategy, Product and Analytics. He is a globally recognized Analytics and Optimization expert, with over 13 years’ experience working with all Analytics tools imaginable. Yoav will be leading the next Mixpanel Analytics Mastery Course that begins in September. Click here for more details.