Why data tracking & analysis is iteration and not a one-time project
Dear Data-Traveller, please note that this is a LinkedIn-Remix.
I posted this content already on LinkedIn in September 2022, but I want to make sure it doesn’t get lost in the social network abyss.
For your accessibility-experience and also for our own content backup, we repost the original text here.
Have a look, leave a like if you like it, and join the conversation in the comments if this sparks a thought!
Screenshot with Comments:
Plain Text:
Before you analyze or collect data, you need to define your questions.
This is pretty easy to write in a LinkedIn post.
But the reality is usually much harder.
Let’s take a typical product context. We are working on a new feature and are ready to launch. Now we need to define what kind of questions we want to get answered. So we can determine what data needs to be collected.
Not too hard – Question: Is this feature working?
Too broad – One level deeper:
How can we see if this feature is working?
> Now starts to get interesting – In the end: when a user, after using the feature, has started/renewed a subscription
But this can also be generic and may take some time – let’s dig deeper.
How do we define the success of this feature itself – what is the state of success of the feature – when we determine that we can measure it. We introduce a new workflow feature – state of success: one workflow created and active.
But is that all? No, this is just the start.
My intention of this short exercise is to show two things:
– it’s fun and time worth investing to do a session with all people involved in developing a new feature to think about measuring it
Most important:
> You will not know all the questions before you implement the tracking. Good teams will develop even more after it. And that is totally ok. Therefore you need to have a process to extend your tracking and reporting constantly. Data & Analysis is iteration and not a project.