For a long time, SaaS companies have hacked and botched tracking multi-seat applications in regular analytics platforms. (We even did this ourselves in the past). If you have a CRM app and you have a customer with a 10 seat license, how do you correctly analyse that customers usage?
Web analytics was about analysing our ‘visitors’. Then we evolved into Customer Analytics, which analysed ‘visitor actions’. But SaaS applications are a different use case – because groups of users might all belong to a single account. This account might have multiple roles, with different goals and expectations from our product.
To correctly analyse usage of a multi-seat SaaS app, ideally you want to group our users into companies, and have your analytics “intelligently” allow for this relationship & grouping in our reports and segments.
I’m going to run through why this is important in a quick practical walkthough (I promise this is leading somewhere…)
Example: A CRM SaaS App Tracking Wants To Track Their Customers Behaviour
Assume your are ‘Hillrise CRM’, a totally fictitious CRM product. You’ve just secured your first paying Beta customer and they’ve been using your product now for 3 months. It’s time to drill into their usage data so you can analyse the new features, ensure that the customer is achieving success (aka a positive ROI) and that they are utilising all of their licenses that they are paying for.
In this case, they bought a “Pro” plan at $59 /user /month, and they bought 10 users. OK so with only 10 users, you simply pull up the 10 individual profiles in your typical analytics app and you categorise their different user types by simply taking a look a what they’ve been upto.
They have 2 power users, 3 occasional users, 1 person who seems to be a manager, and 4 totally idle/inactive users.
The problem is, you’re only exploring these users individually so you have nothing to benchmark this account against. Is this a healthy account? Are they getting the most out of their 10 seats? How do we ensure the manager (who only ever reads weekly reports) doesn’t skew our results when we’re reporting on adoption of our new feature? Is 4 idle users bad? Is this account going to churn, and if so, when?
When the number of accounts/customers is low, it’s easy enough to assess on “gut feeling” and to just pick up the phone and speak to them. Our analytics product reports on everyone individually, and thats ok because we can explore all 10 users’ activity timelines within a few minutes. I can mentally ‘ignore’ that manager when I’m looking at our funnel reports, etc.
But when about when we have 300 customers? Or we’ve grown to 5,000 customers?
At these volumes, we need to be able to trust in our aggregate reports and dynamic segments. We can’t analyse the cleanliness/sanity of our data on an individual basis. We need to know whether 4/10 idle users is indicative or a company churning or not.
We need to track and analyse teams as a whole.
And of course, that’s where I’m going with this (fairly long winded) introduction – Trakio is now capable of analysing behaviour on both individual People and Companies!
Trakio Now Supports Company Data Tracking
For quite some time, we’ve supported an `account_id` property on People. This allowed you to add a Metric to your Dashboard which was ‘How many accounts have performed event X’. This was OK and useful in some cases, but just wasn’t anything near enough for the use case we just discussed.
To correctly support this type of analysis (and to future proof it for our pattern recognition stuff in the works…) we needed to totally change how People were grouped together in the data.
This means you can exclude people where `Role = Managers` from Health Profiles that track usage of a particular feature, and likewise, you can include only people where `Role = Managers` on a Health Profile that tracks usage of the ‘Executive Reports’ feature.
What About Multiple Companies? My Users Can Switch Between Accounts With The Same Login!
Don’t panic, you crazy user-permission control people! We’ve made this work for multiple companies straight out of the door.
This is explained a bit clearer in our Implementation data sheet, but basically, a Person can belong to multiple Companies. But the only requirement is that events tracked for that person must have the `company_id` attached so that we know which account that person is currently ‘logged into’.
This is because we map the events performed by people into their company – so for users who belong to multiple companies we need to be able to map their events appropriately.
If you have any questions at all about setting up tracking where your users can log into multiple company accounts with the same email/username, just drop us an email.
Does This New Company Stuff Break Anything? Do I Need To Change My Tracking Code?
This data change is not a breaking change for any existing implementations.
The `account_id` property will continue to work with Metrics (though it is now depreciated, meaning we will phase it out) and you can still store a single string value in a ‘Company’ property on People if you wish.
If you do not wish to track People grouped into Companies at all, you do not need to. You can disable the navigation items within your dashboard to hide these things out of the way (“clean and clutter free!”).
For example, if you have a SaaS product which just has a single user login per account., you can continue to just track People and still use Trakio in the same way.
However, for users who would like to take advantage of Company tracking, all of our API endpoints are now live and the full documentation is now available. These have been in testing for around 2 months now and it is fully incorporated into our data logging, data backup and data reporting infrastructure*.
How To Send Your Company Data
Implementation teams can checkout the Developer Portal for full implementation documentation. There is an API endpoint specifically for tracking Company data, and also new People properties for mapping a Person to a Company.
We’ve updated our Implementation Datasheet to illustrate the overall principles and data structures – Download the Implementation Datasheet PDF here.
Of course, we’ve available on email@example.com to answer any questions about implementing Company data.
Creating ‘People Health Scores’ and ‘Company Health Scores’
Of course the real beauty about this new addition is that you can profile users individually still AND profile companies. This is important because there are patterns and profiles which apply to individuals (i.e. feature usage, logging in recently, etc.) and then there are patterns and rules which apply on a company level (i.e. A certain % of the companies employees have performed a certain action, the company has paid it’s invoice, API usage is low etc.)
We’ll be posting a lot more about this over the coming months, but a simple use case for a Health Profile rule would be:
‘Mark all companies as `Very Good Health` where 80% of it’s employees are`Power Users` AND the company has paid an invoice in the last 30 days’
‘Mark a person as a `Power User` if they use Feature A and Feature B at least 4 times a week’
Company Health Score setups will be available in accounts who start to send company data. Email us to discuss setting these up as we’d like to work with early users so that we can help you to get the most out of them and also so we can get your feedback.
Want To See A Demo Of Company Tracking & Analysis In Action?
If you have a multi-seat SaaS app that could benefit from a full analytics package to power your customer success, sales, marketing and product development teams, then get in touch for a demo walkthrough or if you’re feeling independent, you can signup for a 14 day free trial and just dive straight in.
Full Company tracking (and intelligence Segmentation, Health Scores, Automated Emailing, Team Alerts) is available on both our Startup ($250 /mo) and Enterprise ($2,000 /mo) editions.
We’re super excited about this BIG change to the product. It represents a huge amount of engineering work, and we’re also totally psyched that this has set the foundation for us to start testing our Automated Pattern Recognition on data sets… (“Ooooh he said a data science buzz word!”)