First Steps in Setting up your Product Analytics Metrics
In the last post, I spoke about my journey into #ProductAnalytics and how I went about conceptualizing what needs to be part of the analytics for our product at @glideinvest. In this post, I’d like to focus on how we went about setting up each metric before we started measuring them.
Once you have your KPIs conceptualised, its important to start documenting how you want to measure each KPI in the product, and what event will lead to a successful measurement (and drop-off) of the KPI. We made the mistake of first adding events to actions that users would perform on the app, and then mapping them to KPIs. What resulted was too many events in the system to identify and map to the exact measurement that we wanted.
While that was not a good start, the one thing we did do properly was to define a forward-looking naming convention for the events. It was important to anticipate that in the near future, product team will not be the one defining and controlling the events, and if it were ever to get into the hands of the marketing team, then god save us!!! Additionally, I did anticipate that there may be multiple tools in the future which may be integrated into the app, and multiple features that will add to the complexity of existing features, and having a clear naming convention that aligns with the architecture of the product was essential.
Let’s take the sign-up process on the @glideinvest app as an example. As of this writing, our app has a single sign-up process, followed by a risk questionnaire, which finally leads to our home page. There is constant debate between product and marketing whether the risk questionnaire leads to drop-offs or not. So there were 2 journeys to measure as part of sign-up — first from install to sign-up completion, and then from sign-up completion to risk-qs completion, and the aggregate of the two. I’ll detail out the findings in the next post, but for now, once the journeys were defined, the event names were mapped to the designs from figma, which gave a clear sequence of events to be mapped in our funnel in the app for #firebase to capture.
Along with event names, event parameters in the form of key-value pairs can also be passed with events, so that event-specific data can also be stored with each event. While these don’t become part of the funnel, they can be viewed and analysed separately as data points related to the events. Here we made another mistake, which we corrected later. If you create unique key names, then parsing them from #firebase becomes an issue. So it’s better to keep only a few key names, and sometimes even a generic one, especially when only one key-value pair is being passed in an event. Study the #firebase documentation to see what some of the default events are (like sign_up), and use these events where possible. Also use a generic name like “param_key” or “event_param” for your param key. For example, in the screen where you are capturing the mobile no of the new user, we used “event_param” and “<mobile_no>” as the key-value pair.
Finally, the worksheet with event names, and correspoding key-value pairs, mapped to each mobile view screen were shared with the devs, who programmed them in and tested them locally. Once the code was released in production and the values started appering in Mixpanel we were able to measure our funnel conversions, identify those who completed their journey, map those who dropped off and where they dropped off, and also validate what impact the risk-questionnaire had on the install to home screen journey.
In the next post, I’ll elaborate on some additional steps we took during our discovery journey with implementing events in #ProductAnalytics, and the key learnings we got out from this process. Planning ahead and not mapping unnecessary events will lead to a cleaner implementation and easier analysis of what you really need to measure.
#ProductAnalytics is a vast subject itself. There are 100 ways to slice and dice your data. So keep on reading and building your knowledge on this topic. Keep practicing everything that you learn, as it will be easy to forget. And ensure that you are generating meaningful output from all the analysis that you do. If you find that a certain funnel or view created by you has not been used for over 4weeks, drop it and reduce the clutter. If it’s not important now, it will just clutter your analysis. If its important, you’ll be able to rebuild it easily with a better understanding of your data. Focus on analysis that gives you maximum return on your invested time.
