If you would prefer to watch a video instead, you can check it out below!

This post is for people who are managing multiple mobile applications in their organization:

  • VP of Mobile
  • Director of Mobile
  • CIO
  • CTO

These roles have unique challenges, such as each mobile team integrating completely different SDKs into internal apps, or some internal apps having no SDKs in them at all.

Generally, this problem can be very hard to deal with if you're just coming into a role like that. We want to give you a little bit of advice from an engineer on how to think about the data coming out of these SDKs and how you can use it to optimize your entire organization, not just the engineering teams.

Get Your Teams To Use The Same Tools

We covered this in a previous video and blog post, but it’s important for everyone to be using the exact same tools.

Now that you’ve got all teams using the same tools, you have the same kind of data going into these dashboards. You might not look at them, but engineering managers are looking at those dashboards multiple times a day to understand how their apps are performing, if the new version is being rolled out successfully, etc.

But you should look at those dashboards as well. The data in them is actually going to be really interesting to you and let me try to explain why.

CS Team

Let’s say you are running an e-commerce site with a customer support team. They field questions from users who had problems with one of your applications. If that application had an SDK that was reporting logging, crashing, or analytics back to a dashboard, your CS team could use the data in that dashboard to do some basic triage.

They could find out if the user is a paying user. How high of a paying user are they? Are they worth bumping ahead in the support queue?

The dashboard might tell you that this user’s network connectivity was really bad. The CS rep could ask the user for more information and find out they were driving in their car while using the app. In this case, the issue doesn’t even have to go to engineering. It can stop right there. The CS rep can apologize to the user, and the issue ends there.

In a lot of ways, the data coming from these SDKs can actually save your organization time and money beyond just the lower level of the engineering team using them to solving crashes. If you bring the data up to a higher level in your organization, your other teams benefit as well.

QA Teams

Another really important concept is your QA teams. They can also use these dashboards to do basic troubleshooting on their own, which is going to save your engineering teams a lot of time and money. For example, QA teams are often testing in parallel on a QA environment or a staging environment where developers might also be messing around. When things don’t work, the QA team has to go right to the developers and ask if they were deploying something or if a server was down.

If QA had access to the dashboard data, they could actually just look at their own sessions and see that the server was down at that point in time. They don't even need to go and bother engineering. They know what happened and can probably fix it themselves.

Summing It All Up

The purpose of this post was to try to help you understand different ways to use the data coming from these SDKs to help optimize your entire organization. Many teams, including CS and QA, can be more productive by sharing the data your mobile engineers are already using.

Who We Are

Embrace is a mobile monitoring and developer analytics platform. We are a one-stop shop for your mobile app’s performance and error debugging needs. If you’d like to learn more about Embrace, you can check out our website or visit our docs!