Several Models for Implementing your B2B Product Analytics

On the surface, the implementation of an analytics solution for products serving businesses seems straightforward using a common framework like “Pirate Metrics”. B2B product analytics is a bit more complicated than that.

Understanding how a business customer is using your product usually involves understanding the interplay between multiple stakeholders (some of them, not using the product).

With product analytics solutions on the market, it’s up to you how you eventually decide to identify users. On top of simple users, there are various levels of aggregations that are possible such as teams, departments, accounts. Nothing is stopping you, when implementing an analytics solution from tracking the interactions with your application of these different levels of aggregation, to gain a particular perspective.

Adding another perspective always comes at a cost, and has both advantages and drawbacks. B2B Product Analytics Models Let’s explore five different models that can be used for B2B product analytics, based on the Pirate Metrics framework (aka “AARRR”), to help you figure out what analytics perspective is relevant for you.

The models for B2B product analytics are:

• Users: Identifying interactions at a user-level only.
• Accounts: Identifying interactions at the account-level (the account being generally the entire company of the customer or the entity that is paying you to use your product).
• Loosely linked users and accounts: You track user-level interactions and account-level interactions but they aren’t tightly joined, if at all.
• Accounts with linked users: You track interactions of users, and accounts and you track user activity within the accounts.
• Advanced variants. These models are the foundation on which to build and satisfy your own product analytics needs. In practice, businesses tend to fall somewhere in the grey area between them.

Let’s lay some foundations first. Pirate Metrics: The Base Framework The base framework we are going to use for the models is the Pirate Metrics framework 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.

It’s made of different metrics and often referred to by the initials of these metrics: AARRR. Here is what each metric means: Acquisition: When a user comes to the product from any acquisition channel Activation: When a user enjoys the first use of the product and when you see value in that user. Retention: When a user comes back after stopping to use the product. Depending on the product, it can simply be when a user uses the product multiple times. Revenue: When a user conducts some monetization behavior Referral: When a user refers the product to other people or businesses Even though the order of the above metrics indicates the funnel a user is generally expected to move through, you can reorder them to suit your particular funnel. For example, at a product team of a company like Slack referral would be put above revenue.

Depending on your organization’s need, you might even want to add “A” in front of the “AARRR” to measure “Awareness” further up your funnel than “Acquisition” might. “AAARRR”. This “Awareness” part might be owned more specifically by the marketing team of your organization, though.

In a B2B context, it’s convenient to split “Referral” into two sub-metrics:

• Internal Referral: When your customers refer your product to their direct colleagues or people in other parts of their organization
• External Referral. When your customers refer your product to different organizations.

Model of Pirate Metrics by Dave McClure.

Model #1: “User Only”

In the “User Only” product analytics model, the behavior of users and interactions with your product is measured at the user level, without much consideration for the organization they belong to.

For instance, you can identify a user by their internal user ID in your system or the email address they registered with. The user is the elementary unit that you track metrics for across the metrics of the Pirate Framework.

This is a likely scenario for many bottoms-up B2B products that are just getting started.

This model is best applied whenever:

• Your product is sold to micro-businesses or businesses with a small number of people (say 1 to 5) or whenever the behavior of a single user largely represents the behavior of the business with your product.
• Your product is sold to and used by a single individual in a company. This is rarely the case in the long run because products like yours may be seeking to deliver meaningful value to offer to customers to charge them more, and that is generally the outcome of the workflow between several persons.
• Your business is new and your early adopters are both purchasers and users. Even if you know that it will change later, to encompass more roles, you can start out tracking just the user because it is often faster and more convenient for customer development. Later on, you can expand the analytics perspective to one of the models below that considers the whole account.

The limitation of this model is that you see nothing at the account level, which brings us to the second model.

Model #2: “Account Only”

The “Account Only” product analytics model is the approach where you measure the usage at the account-level without considering the behavior of specific users that are part of the account.

You measure metrics against an account ID or a domain name and focus only on this level of granularity. to track accounts across Acquisition, Activation, Retention, etc.

This is a good starting point for products that require an entire team, department, or company to be involved for meaningful usage. You can look at the number of companies undertaking a specific action, new accounts that have signed up, and repeat usage within a whole account, should there be several people in the account using the product for the same purpose.

To determine if this is a suitable model for your product analytics, ask yourself whether the person who signed up and activated the product needs to use it again for a group of people (team, department, or company) to get the value promised.

Generally, this model is a good starting point for products that are less about individual usage but more about tasks performed.

For example, consider Trello’s Butler bot. It 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.

To recap, this model is very relevant in these cases:

• Automation products
• Top-down enterprise products The limitation of this model, if used as your only model, is that you may encounter troubles when debugging customer success or usage problems because you don’t know who did what in the account and who got stuck where. This flaw brings us to the third model.

Model #3: Loosely linked users and accounts

This philosophy behind this model for B2B product analytics is about adopting the “Account Only’ model and the “User Only” model and essentially running them side-by-side.

This association is relevant when the “Accounts Only” model is your primary model, yet you need to be able to do some customer success and debugging for individual users, or when your early adopters have started involving more of their organization in the usage of your product.

Model #4: Tightly linked accounts with users

This is the enhancement of the model with loosely linked users and accounts. This model more closely links the two levels so that you have two available perspectives in your product analytics.

With this model, it’s possible to drill down through an account to its users, or up from a user to the account.

This model helps compute metrics such as the average individual users per account, their frequency of usage in the account, and the type of usage for each user.

Needless to say, this model is very relevant for products that require active usage from several users across the team.

Model #5: Advanced variants

This is not a single model but a collection of hybridizations to enhance your product analytics to deeply understand account usage, when the product is becoming complex and more granularity levels are required in between the user and the account or beyond.

For example, it can include the following use cases: Organizational layers like departments, teams, and business units. Role-based understanding of users (e.g. the admin that enables the application at the beginning, the staff that enters the data every day, the manager that views reports only once a month and approves some kind of action e.g payment, etc.) Industry analysis for how your product is used differently across different industries.

Wrapping it up!

Jumping straight to the most advanced analytics implementation isn’t always realistic or pragmatic, considering unknowns, costs, etc.

Having 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 and then evolve it.

Prioritize what you will measure, look at the most achievable and relevant step to your product analytics journey, and accept that it will evolve after some time, as is your understanding of your customers’ journey through your product.

Furthermore, the realities of iteration, effort, cost, technical complexity, product changes, customer feedback, and so on… means you need to gear towards iterating fast.

Good luck with your product analytics implementation