How data management can lower costs for app owners

So you’ve have built the next great app. Maybe it was built in house or maybe you partnered with an app development shop. What comes next? Well, it’s time to create a business around the app and that requires a few tools and services that allow you to make data-driven decisions.

Most app owners will choose an array of tools to equip them with the information needed to create the best possible user experience. Typically an analytics solution is chosen to measure user interaction in order to optimize user flow, a crash reporting solution to ensure the stability of the app, push notification to be able to engage with users inside and outside of the app in a targeted and relevant way, attribution for measuring user acquisition activity, A/B testing to optimize elements within the app. There are also other tools that lots of folks use like email, CRM, retargeting etc. but you get the point…lots of services collecting data to help you make informed business decisions.

In the mobile app space, the way these tools typically are implemented is through software developer toolkits (an SDK). The role of these SDKs is primarily to capture and send data, to their respective platforms. While these integrations are time-consuming and SDKs are confusing if you’re new to mobile, the concept seems pretty straight forward? Data captured. Data sent. Reporting and functionality provided…

Not so fast.

Crash reporting is typically owned by IT. Analytics is owned by an analytics group and/or the executives. Push notifications and attribution are owned by marketing. The same data that’s used by everyone is captured by different vendors used by different stakeholders. And this only gets worse in bigger organizations, especially ones with large portfolios of apps. And again made even worse when some or all app development is outsourced.

On top of this, by embedding multiple third party libraries into the app there are a number of unintended and undesirable consequences as a result. While it may not seem obvious because of this distributed ownership, this creates an incredibly high-cost structure and an inordinate amount of complexity.

Let’s take a look:

Embedded services create very high switching costs.

What happens if you want to switch from one vendor to another? How do you easily get data from one platform to another? You don’t. Your data is trapped. There is a clear lack of data consistency, continuity, portability and if a service goes down, there is no redundancy built in.

Embedded services also create massive opportunity costs.

Far too much developer time is spent managing and QA’ing SDKs which means that their time is not spent building app-related features and functionality. This is a serious problem because many SDKs are incompatible with other SDKs which can destabilize the app and add significant development and QA time. Then when these SDKs have updates which forces you to update your app, you are right back to square one.

If you have outsourced your app then you have to wait even longer. Then you have to wait for App Store re-approval. How many times do you see a generic “bug fixes” in the release notes of an app update. That’s almost always an SDK update. Get the point? It’s a mess.

Embedded services create higher user acquisition costs.

Recent research has shown that only 7% of users acquired through marketing efforts remain engaged over time. This means that for every $1.00 you spend on user acquisition, you would retain $0.07. According to a recent blog post, the top two reasons a user will abandon an app is because it consumes too much data and it drains too much of their battery life. Think about it, anytime there are multiple SDKs capturing and sending data to their respective platforms, each service must open a network connection to stream that data out. That means if there are 4 SDKs then there are 4 open network connections and 4x the amount of data is being streamed from the app. This leads to excessive resource consumption and poor user experience. We all have apps on our phones that we know we have to shut down to preserve battery life and this is almost always why!

So how do you solve this and unwind the vicious cycle?

Well, it’s pretty straightforward in a sense. You need to bifurcate data capture from data distribution. Data capture can happen client side but it only needs to happen once. Data distribution should be done server side to eliminate excessive SDK updates, as well as the need to dedicate excessive time and resources to testing and QA. Moving to server-side integrations means that the business can work with partners easily and vice versa, and don’t require code changes, or long lead times. It also means data ownership and control which pays long-term dividends across marketing, product, and IT. But most of all it means a cheaper, more effective, scalable way to run your app business.

The app ecosystem is evolving and maturing and it’s time app owners start investing in infrastructure rather than just point solutions.