Get App Smart: How to Use AppExchange App Analytics — Part 2

Special thanks to my co-authors Vivek M. Chawla and Vanessa Chalem.

This blog post is the second in a series about AppExchange App Analytics. Catch up on part one, Get App Smart: How to Use AppExchange App Analytics to learn about the following topics:

• Package Activation and Permission Set Creation
• Deciding Which Application Insights You Want
• Building and Submitting an App Analytics Query
• Monitoring Your Query and Downloading the Results

Now we’re going to focus on the steps you need to follow after you’ve made your App Analytics query and downloaded an App Analytics log file.

Learning By Example

After Codey implemented App Analytics, he ran a query to get a log file with detailed analytics for all subscribers who used his app, Codey’s Code Corral, over the past week.

To be truly useful, though, Codey will need to somehow turn this raw log file into actionable insights. Let’s pick things up while Codey is making his first key decision: How to visualize his App Analytics log data.

Step One: Decide How to Visualize Analytics Log Data

Codey will need to visualize his App Analytics log data in order to get actionable insights about how people are using his app. To do this, he’ll need to temporarily store his log files somewhere and use a visualization or reporting tool to make sense of the data.

Here are the options Codey is considering:

1. Manually save log files locally and use Excel to visualize the data
2. Manually import log files into Salesforce and use Reports and Dashboards to visualize the data
3. Create an Einstein Analytics dataflow to ingest log files and use Einstein Analytics Lenses and Dashboards to visualize data

Option one is ruled out because Codey wants a cloud-based solution to make sharing insights and collaborating on data with the rest of his team easier.

Option two is also a no-go because the Code Corral app has hundreds of subscribers, with most subscribers having thousands of users. This can result in big log files with lots of rows, which can quickly eat away at the data storage limit in Codey’s org.

Using Einstein Analytics is Codey’s best bet. It’s built from the ground up to store millions of rows of data and provides him with best-of-breed data visualization and exploration tools. Codey can even test-drive this process in a DE org before deciding to acquire Einstein Analytics licenses for his business org.

Step Two: Bring Log Data into Einstein Analytics

Codey has decided to use Einstein Analytics to visualize his App Analytics log data. This means that he’ll need Einstein Analytics to ingest this data on a regular basis.

To do all this, Codey will need to…:

1. Create a temporary dataset to hold the newly uploaded log data
2. This can either be a direct upload of the CSV file

1. Or use a remote connection
2. Create a dataflow that appends this new dataset onto your existing log dataset
3. This dataflow can then be scheduled to a time after the latest log data is uploaded

Step Three: Bring License Management App Data into Einstein Analytics

Codey also wants to augment his App Analytics data with key information from his LMA so he can associate customer names with subscriber org IDs in the logs.

To do this, Codey will need to…:

1. Bring in the LMA data

If you are using EA on your LMA org, you can just use a local Salesforce connection

Or if you are using EA on a separate org, you can bring in the LMA data using a Remote connection

2. Bring in the following objects: License, Package, Package_Version, Account, and Lead

3. Set up the Salesforce data to sync daily

4. Create a dataflow to join your LMA data into 1 LMA dataset

Note: For this step, start at the lowest level(License), and schedule this dataflow to run after the LMA data is sync’d

5. Create a recipe to append the LMA data with your Log data

In this walkthrough, we are using the LMA package version ID to join to the package version ID in the log data.

NOTE — the id from LMA data (your Salesforce data) will be 18char while the id from the App log data is 15char. You can create a formula field within the recipe to truncate the LMA ids and then use that to match your app log id.

Step Four: Visualize and Analyze

Now that Codey has his log data in Einstein Analytics, it’s time to figure out what information he can glean from the data.

Codey’s main questions are about usage and adoption.

Usage

• How often is a custom object accessed over time?
• Who are my top customers?

Adoption

• How often is a new feature being accessed?
• How many users are accessing my package over time?

Visualizing Usage

By taking the number of unique user_id_tokens over months and daily, we can see our usage.

Here is a dashboard with two lenses:

We have good consistent usage of our app (and it’s two versions).

Visualizing Adoption

Next, we want to find out how our objects are being used and that will help us determine what new features we should focus on.

By simply taking the Entity and Operations and counting rows in our log file, on Einstein Analytics, you can create a heatmap of our most heavily used objects.

Let’s use this heatmap to see how Codey’s subscribers are actually using the custom objects for projects and mentorship.

We could always break this down further by customers or by date (daily/weekly/monthly).

From this adoption analysis, we see there is a high adoption rate of the Projects custom object; however, there is pretty low adoption of the Mentorship object.

Step Five: Take Action

This gives our friend Codey a huge insight into how their application is being used, and where more resources should be allocated as they do future iterations of the application. The Projects functionality is definitely being used to keep track of different projects and can be an area where new and exciting features around project management could further enhance the app and increase adoption.

However, on the other end, Codey recognizes more research is needed on the usability of the app and why subscribers aren’t necessarily using it to track mentors. After some research and feedback from customers, Codey found that many subscribers were actually using the Salesforce standard Contacts object to keep track of mentors. At the end of the day, mentors are just another type of Contact.

With this in mind, Codey decides to modify the app for the next major release where Projects would be linked to Contacts representing mentors instead of the legacy “Mentors” custom object.

Thanks to AppExchange App Analytics, Codey was able to get a deeper view of how users interact with the app, , could take action, and also garner feedback to influence their product roadmap.

Summary

We covered a lot of ground in this blog post. To summarize:

• Once you get the log data, bring it into Einstein Analytics
• The log data can be augmented with LMA data. For example to show customer names instead of subscriber org IDs
• Use the lenses and dashboards to create visualizations that answer your questions

There are many manual steps to make the request, get the log file, and bring it into Einstein Analytics. Stay tuned for the next post in this series to see a proof of concept that allows full automation from request to visualization.

Resources

• ISV Guide — App Analytics
• Trailhead — Einstein Analytics basics
• Einstein Analytics external API
• Partner Intelligence Experts Group on the Partner Community for Q&A