User behavior analysis and engagement play an important part in realizing the business value of a consumer mobile app. Tagging plans are the mapping within the application of how usage events and measurements are collected. These tags serve as raw material to describe user journeys or funnels and organize the customers in segments that can be observed and engaged in the most efficient fashion.
While these techniques are not new, they still suffer from the common mistakes below for which we offer remedies:
1 – Copy the Web
It is very tempting to duplicate the HTML thinking of a website and consider the app as a succession of pages. The focus will then be on page visits. However, a well designed app should serve highly dynamic content with notifications and calls-to-action that adapt to the context of usage, which is powered by a deep awareness of the user’s expectations and likeliness to enter into a transaction. The Web approach can lack the ability to distinguish important signals from the noise.
2 – Ask the developer
If you ask a mechanic to describe a car, the answer will probably include an engine, gearbox, wheels, etc. The same question to a soccer mom will likely involve the size, ease of driving, fuel consumption, and maybe the color. Because of the perceived complexity of the tagging process, it is not uncommon for marketers to rely on the mechanic, in this case the developer, with little or no guidance and end up missing out on the usage value proposition.
3 – Put as many tags as you can and worry later
FollowAnalytics consultants, when reviewing initial tagging schemes with customers are often confronted with hundreds if not thousands of events. These schemes are meant for human consumption (sometimes for machine learning) and someone has to make sense of the observations and measurements collected. Sometimes the proliferation of tags stems from the use of automated utilities that extract and/or transform existing code taxonomies into tags. Tools such as FollowAnalytics provide advanced filtering capabilities, but it is still good practice to approach the tagging plan with a “what do we need” mindset and not fall victim to the “what can we eliminate” conundrum.
4 – Bad naming convention
While it is usually viewed as a good engineering practice to reflect the categorization in the way events are named using prefixes, suffixes and numberings, it is important to consider, once again, the business audience for whom the tagging plans are destined. Clarity should be privileged so that important events are comprehensible and accessible without risk for confusion. On a more practical level, when presented as a list, events sharing the same prefixes cause the loss of valuable UI real estate and can be a source of frustration when scrolling through them.
5 – Disconnected from business goals
Sure, it is a lot easier to hand over a finished app to the business teams and plan only for small modifications before releasing it to the public. In practice, the business people who may have a hard time understanding the abstract view of a specification document are bound to unleash their creativity and business acumen once they have it in their hands. Ideas on what to measure and analyze and how to engage the users will start flowing and some of them may require the tagging schemes to be modified. This should be planned for and can yield material enhancements to the overall marketing value of the app.
6 – Apps as a closed isolated system
For organisation purposes and to avoid paralyzing external dependencies, it is often the case that tagging plans are built in isolation within the App. A good practice is to consider a more global vision of important events and measurements to be collected. For example, an insurance company will be interested in analyzing the impact of the mobile App on the efforts to streamline customer interactions (less calls to the contact center, less paperwork, etc.). The mobile tagging plan must be designed to contribute to that overall data analysis.
7 – Hard to organize in funnels
This may stem from a lack or excess in the level of collected details. For example, in an m-commerce check-out workflow, it may be impossible to distinguish a successfully completed payment event from one that didn’t go through. Also, if the funnel view is not considered early enough, it is likely to result in a number of missing important events needed to complete a funnel or a considerable number of “leftover” events that are not used at all.