In part 1 of this post, we learned how to identify key events and their flow. In this part, we we learn how to design events and review some best practices.
After reading Part 1, you should have a clear idea of your app’s flow. In this post we will cover event parameters and some good practices in general event design. You will be able to take the next steps in implementing event tracking with your own analytics tool.
If events are actions, there must be a way to describe and differentiate one event from the other. Parameters are features that can be qualitative or quantitative and they characterize events. In UML Use Cases, a parameter can be compared to a variable; the use case defines a set of variables that describe the pieces of information that flow in the system. From this, we know that an event may have one or several parameters.
What the parameters measure is what makes each event unique.
What parameters should I include in my events? In simple terms, as many as are relevant, at least adding all the parameters needed to answer the proposed questions. It is a good idea to keep things simple during the first design and build from there.
Remember that how you name these parameters is not important, but it is helpful to follow an intuitive, easy to understand naming convention that represents what is being measured.
Taking our previous diagram showing event flow, we can start by adding the relevant parameters (or variables) that will provide the actual data to answer our questions.
Let’s start with the Start_App event: I know that in the login action the variables user_id, platform, amongst others are available, so I make these 2 my first parameters.
Next, I do the same with the In_App_Purchase event: I know that it’s a good idea to use the variables item_id, total, currency_code, and also user_id to attribute the purchase to the correct user.
For the Start_Level and End_Level events, I know that, though they may share some variables such as level_id and difficulty, there will still be some that are unique to each one. I keep the variables: end_time, result, and user_id as parameters for End_Level.
My final Event Design will look like this:
Several specific events might be combined easily into one generic event to simplify our event design and understanding of the event flow. For example, given the events buy_boost (boost_id, user_id, price) and buy_powerup (powerup_id, user_id, price) we can see that their parameters are almost identical. We can merge these two events into a single one such as buy_item (item_id, type, user_id, price) where type will determine if the item was a boost or a powerup.
There is an inverse relationship between the number of events and the number of parameters. A decrease in one means an increase in the other.
Determining the quantity of events and parameters per event is a balancing act that will depend on each particular app and its flow. Balance is key!
So… can I have one mega event that contains all of the parameters I want to measure? Or can I have events with only one parameter? The answer to both is yes, you can. But just because you can, does not mean you should. You risk efficiency, clarity, and flexibility.
If your analytics tool allows it, parameter values can be used to calculate other derived values later, and there is no need to have your application perform operations with parameter values.
Make the tools work for you!
Analytics tools that offer this possibility by default add flexibility to your data in case you want to change the operation or want to use the source values for new operations in the future.
Think beyond the visualizations, have a clear target of what you want from the data, how you will use that information to answer your key questions, not just what you want to see in a table or graph.
A final word to wrap up this series… change is inevitable, especially during development. Users may change, the context of your application may change, and your application itself may change. Review your events periodically to get the most valuable information and make your final event decisions before the launch. We addressed this need of having flexible taxonomy in our post on custom metrics. With a clear idea of the flow of key events and well planned parameters in your application you can be sure to save yourself some pain!
Maria J. Mera is an Account Manager at Omniata where she provides support and insights to customers throughout their life-cycle of data needs. Armed with skills in engineering, knowledge sharing, and data science, she has been empowering individuals and teams for almost 10 years in diverse areas. She is passionate about holistic methods in analytics, design thinking and watercolor painting.