So you’ve built a Salesforce application and users have been downloading it into their orgs. You’ve been in the swing of things now for a few months, and feel like you’ve got the hang of things now. Do you how well your application is doing?
Seems a pretty obvious question, almost rudimentary. Yet, you can actually answer it in many ways. You could track your installs and say “We’re growing because more users are installing our app.” And that would be a fair assessment. You could say “We are getting more licenses by the day.” That, too, could certainly be a great indication of growth – after all, more sales is a good thing.
But experience should have taught us all that the growth curve doesn’t move from the lower left to the upper right forever. Eventually, you start to move sideways. Eventually that line starts to oscillate in fits and starts. And when it does, you’re brought right back to my question: How well is your application doing? And, now you’re in a bit of a conundrum, because your previous answers no longer apply. That’s because those answers were reactive in nature – “We are doing well because the end result is well.”
My suggestion is to be proactive from the very beginning. Your assessment could then be: “We are doing well, because we are actively monitoring our users to ensure they have the best experience possible.”
I’m going to go into a variety of options available to you, so you can see what you can look to deploy into your application. Our goal to show AppExchange users how to see into their application to determine the user’s experience. If you’ve read any of my previous blogs, your primary objective for your application is to stay on top of any and all issues. I’ve discussed establishing a strong community engagement strategy to address that. Now, I’d like to discuss usage tracking.
There are basically two approaches to this process. The first approach, and likely the most obvious, is to leverage existing Salesforce assets and options. The other is to employ some operations within your application to monitor activity.
Salesforce Option
Usage Metrics
I’m going to assume you already have Environment Hub set up, and your release and reporting orgs are connected to your Environment Hub; these are required to enable Usage Metrics. The release org is where you’re packaging your application. The reporting org is where you want the usage data delivered. Once you have this set up, open a case within the Partner Community to have Usage Metrics enabled – be sure to have your Package ID handy.
Usage Metrics is a feature that, once enabled, will update your reporting org daily with usage data from orgs that have your application installed. The information covers your Visualforce pages and your custom objects – providing aggregated information on their usage. Tracked metrics include the total number of visits per org to your Visualforce pages; the average load time for your Visualforce pages, and more.
Pros
Users cannot opt out of this data – you know you’re getting all the data available to you.
Cons
While it’s a great start, there are some issues with it. Because the data is sent into a specially formatted text file, it requires special wrangling if you want to parse data for custom reporting. To get it into a system of your choice for further, deeper analysis, you have to write a custom process to collect the metrics data from your reporting org.
Additionally, if you have a lot of data, (for example, if your Salesforce application has been around for awhile), then attempts to view your Usage Metrics data start to fail. After a while, you’re pretty much required to export the data into an external system to analyze.
Leveraging Tracking in your App
The complexity here can vary, so I won’t go into great detail on each of these. Everyone’s application is different, and so how you’d leverage these options really depends on your unique circumstances. That all being said, let’s start with the basics.
Google Analytics
There are many reporting products similar to Google Analytics (GA), so I’m going to use GA as a surrogate for all of these. Setting up GA on Lightning experience components and Visualforce pages is certainly feasible. There are two main areas of concern when approaching usage-data collection.
You will need to save GA as a static resource within your application. This may be a bit difficult when it comes to managing your application and keeping GA up to date – but it’s a requirement. So any changes to GA that need to be reflected within your application would require you to push an update to your application to all of your current users.
Pros
Similar to Usage Metrics, this will provide you with more detailed information on usage within your Visualforce pages – as well as lightning components. And, with the data already being collected into a site where it’s easy to manipulate and build reports from; you circumvent an entire setup process you’d face using Usage Metrics. Plus, this option scales really well.
Cons
The static resources aspect may be something of a painful restriction, but it’s certainly manageable. The level of detail of information you’re receiving is pretty much on par with Usage Metrics.
Application-based Usage Metrics
You have a variety of pages, objects, and features you’d like to track. The previous options work, but you’d like more granular information. You’d like to track not only Org-level activity, but also User-level activity. Who is clicking, where and what? How often is this User performing this operation? It may sound Big-Brother-like, but understanding this can benefit your end user.
For example, you want to collect user information to ascertain if a user is having a problem with your application – so you can promptly resolve it without requiring the user to open a ticket or contact your support team. Perhaps you’d like to track a given user’s behavior so you can make specific usage recommendations to them, to better enable them to leverage your application to its fullest. There are many reasons to get this granular with tracking, but there are rules you have to follow first.
Collecting anything more than the OrgID requires end-user approval. This means you will first have to mention on your AppExchange listing that you will be monitoring usage data. You also will have to provide a notification of this monitoring behavior within your application’s administration page, and allow administrators to “disable” the collection operation. This is required even if you are only collecting aggregated data like total users assigned with specific permission sets.
Once you enable this, then it just becomes a process of collecting the data in a custom object. Most create routine operation that collects the data and makes a callout to your API endpoint to deliver it to you.
It goes without saying that everything within this process will be required to pass muster with the Security Review team, just like everything else within your application. My strong recommendation is to consider keeping the usage data well maintained. I’d recommend against a scheduled batch job to clean this up. Instead, consider a trigger on the usage data custom object that creates a future job to make the callout once the count of records within that object gets to a certain limit – then deletes all the records after a successful call. Making a callout after every created record can cause problems within orgs.
Pros
You’re getting a whole lot more data than before, and it’s as granular as you need. This process can very easily be leveraged to enhance the end-user experience. The gains are limited only to your imagination.
Cons
There’s going to be some dev work in this, and the introduction of the “opt out” feature may seem unpalatable. A valid concern is that that users will just always opt out – and that even asking raises red flags. I would recommend clearly articulating to the user exactly what you’re tracking and how it’s a benefit to them. If you’re just tracking OrgId and UserId, then it would likely be easier to accept the feature than if you’re collecting Name, Email, and Date of Birth.
Moreover, if your collection process adds any sort of burden to the user’s org operations, you’re almost guaranteeing that they opt out. You also need to limit batch jobs for your callouts and be wary of storage creep.
Final Thoughts
There are a variety of ways better track your application’s usage within a given org, and/or within your community of users. None of them are perfect. Some require more work than others, but tracking your application’s performance beyond just licenses and installs is a worthwhile endeavor.
You’ve spent a lot of time, energy, and money getting your application on the AppExchange. Don’t let up on the reins now! You should be constantly monitoring the pulse of your product to ensure a longer, and stronger, growth trajectory that takes you from the lower left to the top right with full visibility through the rise.
If you are seeking a PDO to get you to market or solve issues that are taking away from the success of your product, look no further. As the only PDO Master, we are formally recognized as providing the highest level of expertise with Salesforce solutions, including a demonstrated history of customer success. We help SaaS businesses thrive on the AppExchange. Let’s talk!
