Product Analytics for B2B: 5 Models for What to Measure

16 Jul 2019 by Scott Middleton
Close up picture of pirate face

On the surface product analytics for products serving business customers and users seems straight forward. You just take a common framework like Pirate Metrics, apply it and then bang, you now understand your users, success! At least, that’s what I thought when I first setup product analytics for a business-to-business (B2B) product. But B2B product analytics is a bit more complicated than that. 

Understanding how a business customer is using your product usually involves understanding the actions (or inactions) of multiple users and, sometimes, the interplay between those users. 

You can track analytics at an account level (e.g. a company), a team level, a department level, a user level, by user role and more. If you’re just starting then this can be overwhelming and if you’ve been at it for a while then you know you can add another perspective but it often comes at a cost (which might just be the cost of useless data overload).  

This post is going to explore five different models you can use for B2B product analytics, building on the Pirate Metrics (AARRR) framework, to help you work out what analytics you need.

B2B Product Analytics Models

The models for B2B product analytics are:

  1. Users Only – you track analytics at a user-level only.
  2. Accounts Only – you track analytics at an account-level only (an account being the entity that is paying you).
  3. Loosely Linked Users and Accounts – you track user-level analytics and account-level analytics but they aren’t joined particularly well if at all.
  4. Accounts With Linked Users – you track users, you track accounts and you track user activity within accounts.  
  5. Advanced Add-ons – some advanced add-ons you can throw into the mix. 

These models are really meant to serve as a foundation for you to build on and think about your own analytics needs. In practice you’ll most likely fall somewhere in the grey area between them all.

Just before digging into each model we need to lay some foundations.

Pirate Metrics: The Base Framework

The base framework we are going to use for the models is the Pirate Metrics framework. Pirate Metrics was created by 500 Startups founder Dave McClure in a bid to form a common model for understanding the products of the hundreds of startups they’d invested in and the thousands more that were being pitched to them.

Pirate Metrics gets its memorable, not-so-professional sounding name from the initials (AARRR) of the different metrics of a product/business that it suggests you track. The initials AARRR stand for Acquisition, Activation, Retention, Revenue and Referral. Here is a brief summary of what each means:

  1. Acquisition: Users come to the product from various channels
  2. Activation: Users enjoy the first use and have a happy user experience
  3. Retention: Users come back, use the product multiple times
  4. Revenue: Users conduct some monetisation behaviour
  5. Referral: Users like the product enough to refer others

The ordering of them is meant to also indicate the funnel that a user will move through. You can reorder them to suit your funnel. For example, if you were on the Slack team you may have reordered this list to put referral above revenue.

Some product teams add Awareness making the initials AAARRR and use awareness to measure further up the funnel than acquisition might. This is a grey area as to whether you add this and it probably depends on your organisation’s size – a larger company may get value from adding awareness so this can be owned by a marketing team.  

In a B2B context, Referral can be subdivided into sub-metrics: Internal Referral and External Referral. Internal Referral is where customers refer your product to customers in other parts of their organisation. External Referral is where your customers refer you to entirely different organisations.

We can now dig into the models themselves.

Model fo Pirate Metrics flow by Dave McClure
Model of Pirate Metrics by Dave McClure

Model #1: User Only Product Analytics

The User Only Product Analytics Model is an approach where you measure the usage of users without much, if any, regard for the organisation they are attached to.

You can measure a user by their email address for instance. The user becomes the key ‘unit’ that you track metrics for across Acquisition, Activation, Retention, etc.

Situations this is best applied:

  1. When your product is sold to micro-businesses. Micro-businesses tend to have a small number of people (1-5) and little division of responsibility meaning the behaviour of a single user largely represents the behaviour of your customer.
  2. When your product is sold to and used by the same single individual in a company. If your product is purchased by and used by the same person in a company then you can use this approach. This is rarely used in the long run as products used in companies/teams tend to require more than one person. 
  3. When you are getting started and your early adopter is the purchaser and the user but later you know it will include others. You can start out tracking just the user (which is often faster and more convenient for customer development) then expand to one of the models below that includes account analytics. This is a likely scenario for many bottoms-up B2B products that are just getting started.

Model #2: Account Only Product Analytics

The Account Only Product Analytics Model is an approach where you measure usage at the account-level without much, if any, regard for the behaviour of specific users.

You measure metrics against a domain name or account ID under this approach and focus on this level of granularity. You focus on tracking accounts across Acquisition, Activation, Retention, etc. 

This is usually a good starting point for products that really require an entire team, department, or company to be involved to see success. You can look at number of users undertaking the actions you want them to, new accounts that have signed up, and repeat usage within an account. 

It is also a good starting point for process automation products that are less about individual usage and more about tasks performed. For example, Trello’s Butler bot automates Trello actions so it ideally has 0 active users each week but at an account level is performing many interactions so measuring at an account level makes a lot of sense. 

A quick rule of thumb to determine if this is a good model is to ask yourself whether the person that signs up and activates the product needs to use it again for a group of people (company, department or team) to get value.

To recap, situations this is best applied to are:

  1. Automation products
  2. Top-down enterprise products

The problem with this model as your only model is you may have trouble debugging customer success/usage problems because you don’t know who got stuck where.

The flaw in this model brings us to the next model.

Model #3: Loosely Linked Users and Accounts

This model for B2B Product Analytics is about taking the Account Only Model and taking the User Only Model then essentially running them side-by-side.

You use it when the Accounts Only Model needs you to do some customer development/success debugging for individual users. Or, you start using it once your early adopters have started requesting ways to involve more of their organisation.

Model #4: Accounts with Linked Users

This is the upgrade to Loosely Linked Users and Accounts. It is about more closely linking Users with Accounts so that you can come at your product analytics from multiple perspectives.

Under this model you can drill down through an account to its users or up from a user to the account it belongs to. You can include metrics about average individual usage in an account, the frequency of usage in an account and the type of usage.

This is really relevant for products that require active usage from across the team.

Model #5: Advanced Add-ons

This is less of a single model and more a collection of add-ons you may need to enhance your product analytics to really understand account usage.

You may need to add modelling for the following:

  1. Organisational layers like departments, teams and business units.
  2. Role based understanding of users (e.g. the admin that enables the application, the manager that views reports only, the individuals that enter data)
  3. Industry analysis for how your product is used differently across different industries.

Now to apply it

It is easy to think you will start out by jumping straight to the most advanced analytics, but this isn’t realistic or pragmatic. You need to look at the next most achievable and relevant step to your products analytics journey.

The realities of iteration, effort, cost, technical complexity, product changes, customer feedback and more means you need to gear towards iterating fast. So you need to prioritise what you will measure.

Furthermore, extra data is nowhere near as useful as the right data. Arriving at the right data to track is a process of iteration. Get started with the most relevant model to your product or new feature and then evolve it. Less is definitely more here.

Back to Blog