Stop your app journey from going off-course

Building a mobile app is not a once and done activity. It is a journey. This is true for many aspects of the app, including the data services that support it.

The app data journey often begins during the development of the first version of the app and the first stop is analytics. This makes sense because all functions will need analytics to help power their decisions. Engineering and product teams will want to understand users’ behavior in the app in order to optimize the experience. The marketing team will want to know where users are coming from and what exactly they end up doing in the app to help drive strategy. When an app has eCommerce, the entire business, of course, will rely on knowing how much revenue is being driven by the app.  

There are a lot of great analytics tools out there to help provide teams these insights, from free tools such as Google Analytics, to others such as Amplitude or Mixpanel. Regardless what tool the team ends up choosing, their app’s data needs to get to that tool. Typically, this results in the engineering team installing the analytics tool’s SDK in the mobile app. After deciding what data to collect and how to go about naming each data point and implementing the code, the business has mobile analytics after the app release.

Now the app is live in the app store and has garnered some interest, resulting in a few downloads. The engineering and product teams are already leveraging insights from the analytics tool for the next release. The marketing team knows it’s now time to begin owning the airwaves and run app install campaigns. Rather than just writing checks to media partners, they want to be smart about where they are spending their marketing dollars and be able to adjust tactics based on knowing what is working and what is not. The weapon they need here is an attribution solution, such as Kochava or Tune. Whatever tool they use, that tool will need to know what users end up getting to the app, and potentially what those users are doing in the app. So the vendor will provide the marketing team with an SDK to put into the app and collect the right data to power the attribution tool, and the app’s marketing team will ask engineering to squeeze the attribution tool’s SDK implementation into the next release. There may be some KPIs that matter for them now, and those requirements might make it over to engineering to help guide them in the implementation of the SDK.

It’s now a pretty exciting time for the entire team. The download campaigns have been wildly successful, and the app has hundreds of thousands of downloads. Customer feedback is beginning to come in, helping influence the app’s product roadmap, and users are engaged. However, users have short attention spans, and competitors are beginning to take notice of the app’s success as well. It’s time to begin engaging users via email marketing and push messages and keep them coming back to the app. Companies such as Braze and Kahuna have some powerful tools to help with this sort of marketing automation. Both platforms can do a great job, and both platforms leverage app data to help power the marketing. Again, it’s time to implement an SDK, and again the conversation about what data to collect (hopefully) comes up.

At this point, after continued success, leadership clearly sees that the mobile app business is something serious. A serious business, demands a serious business intelligence solution. The team begins examining potential solutions for storing user behavioral data from the app for business intelligence purposes. However, access to the right data for business intelligence purposes becomes a challenge. The servers that the app sends data to don’t have the right data, nor is it in a format digestible for business intelligence. Meanwhile, the marketing team has in essence become victims of their own success; they now are ready for more advanced tactics, however, their attribution tools don’t have the right data to report on new KPIs. Since the marketing automation tool was implemented later, and by a different engineer, the naming conventions in that tool don’t line up with what’s in the analytics tool and the team is unsure what the data actually means. This state leaves the business on shaky ground, where they face challenges scaling and are unable to leverage their data as a strategic asset. New tactics or the need for different data requires a significant investment of precious engineering time.

This sort of state certainly isn’t the desired route for anyone’s business journey, but it’s easy for even the savviest businesses to end up going down this path. So how does one get out of such a situation or prevent it from happening? By investing early on in a data layer, and taking the time to develop a data strategy, any business will be ready to effectively leverage the right data during the entire journey. Furthermore, making that investment will increase the team’s efficiency – the marketing team can pursue marketing without significant technical dependencies, and the engineering and product teams can focus on building the app, rather than spending time managing SDKs. Even if a business has veered off course and ended up like the fictional one in this blog post, it’s never the wrong time for a company to begin taking ownership of its data.