A couple of weeks ago I wrote about the user state. Went through what it is and what it has, meaning, what variables are included. This week the focus is on what you can do with it.
Assuming you are sold to the idea of a user state, you now have (or will have!) a large table with all or users. That table has a many variables that touch all areas of The Player Lifecycle.
So… now what? What’s the point.
This is the objective of this post, to tell you what you can do with it.
Tell me more… what can I do with such an extraordinary thing?
The first and best use case for a user state is to support ETL. The point of this use case is that your automated data wrangling code needs bits of information that will always require some sort of SQL join. For instance, to create cohort tables you will need acquisition date and retention day by proxy or calculation. There are two ways of doing this: you either query your whole events to find that or you simply store it in the user state. The former is very intensive and costly, the second is a simple query.
The second is segmentation and clustering. Every time you want to get your hands on a segment of users, you either query massively or you query the user state, assuming the data that you want to segment or cluster by is in the user state. This use case also allows for less feature extraction in ad-hoc analysis. If the variables are there, computed every day, we don’t need to build them at analysis time.
Segmentation and clustering also support other data products. For instance if you have an in house A/B test or RCT tool developed, clearly stating that segments for the experiments can only be created from user state queries makes everything so much easier, clear and usable.
The third use case is event enrichment. What this means is that when and event enters our system, we add bits of the user state to it. Which ones? The ones that will help your BI and visualisation tools quicker queries without joins. This is mostly a reporting concern but it is no small thing. Not many things worry me more than business users not accessing the data they need.
Another thing we can do with the user state is query it directly. This is particularly useful if you want to build dashboards. Creating a rolling retention visualisation is a piece of cake if we have a user state up.
Last but not least: data products! Be it interactive or automated, the end products of data science teams are data products. In a way this is an extension of the previous point with the difference that it can be bidirectional.
And that is it. The shortest post to day if I’m not mistaken.