As application developer you want to track and measure everything, but the key to success is in identifying the most meaningful events. This post explains how to identify the most important events to track.
Applications (mobile or otherwise) can help us do many things, things that range from the very complex to the fairly simple. As application developers or publishers we want to understand how our users interact with our application so that we can continuously provide better, more reliable products based on data.
Applications are complex systems and, as we add elements to the system the interactions between these elements become more and more demanding to keep track. Systems tend towards chaos; this makes it increasingly challenging to obtain the meaningful data that can help us improve our products.
But don’t panic!
To go from chaos to order, we can select what happens during the most meaningful interactions (or “events”) and forward that information for analysis and decision making. This is what event design is all about.
After reading part one of this two-part series you will be able to explain what an event is, know how to identify one, and enjoy some stellar diagrams. Are you ready?
Although it is easy to be tempted to just start and adapt later, in analytics a planned beginning can save a lot of resources. A well thought out event design can be the difference between hard-to-interpret data and available information.
Understanding the flow of information is vital for any data analytics work and this flow should not be imposed by the analytics tool.
Understanding your application’s data flow should always be your primary objective. Do not fight your data, work with it!
Generally speaking, an event can be thought of as an action. It can be done by the user of the application or by the application itself unto another element. An event, as an action, can be generic (“application loaded”) or specific (“help menu clicked 3 times”) and for data analytics it typically represents an element of interest for tracking.
An event can look like a verb! It can help visualize both cause and effect. Events tell you information about what is going on at a certain point and time in the application. This information can be from day to day, or session to session, (over time, context, users, etc.)
At this point you may realize that your application has a ton of events, and tracking all of them may seem counter productive. Do not worry! Not every event in an application is worth tracking. As a rule, we only want to follow the events that could be changed in order to a) improve user experience and b) allow us to deliver a better product.
Do you UML? If you need a little help, you can use your application’s UML Use Case diagram because it closely models event description. You might want to consider starting with this and later trimming down your event design to include the critical events that are of interest to analytics.
Let’s imagine we are developing a mobile game app. Our game is level-based and sells items in an in-game virtual store. As part of the first meeting with the analytics team, they tell us they are interested in solving the following 3 questions:
Our game already has all this data on a per-user basis, how do we start with the event design then? By looking at the application’s use cases, or in this example, looking at the game’s core loop. For our simple game, the core loop may look like:
Notice that this describes what the game is doing at various points in time, they are all verbs and show interactions not only with the user but also with the game itself.
Since we are focused on answering our three questions, we can instantly disregard some of the events, leaving our event design diagram looking like this:
Why do I keep these four events? For starters, the Start_App is going to tell me if the user is new or not, answering the first question. The next action of interest for me is the In_App_Purchase event; keeping this one will answer the second question. Finally, the Start_Level and End_Level events will provide the information I need to answer the third question.
Even though the raw data from the events may not answer your questions directly, at the instant the event occurs, the data needed to find the answer will be there waiting for you.
So far, we have pared down all of the interactions in our application to the most meaningful events, but this is just the beginning. With this model, we can see the dependencies, and hence the flow of our simple game. When you are doing this with your own application, you should be able to spot redundant or missing events, and improve the model with every iteration.
Where to go from here? Try it out, find your event flow and stay tuned for Part 2 of this post where we will take a look at what makes each event in your flow unique, and how this can help you get the different stories your data can tell! Meanwhile, please feel free to check out Omniata's features or contact us if you have any questions!
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.