👓 The importance of account level analytics in B2B

User-level behavioural analytics are a wonderful thing and something that, over the years, have unlocked countless insights for me and the teams I’ve worked with or led.

But user-level analytics aren't enough if you're working in B2B.

Insights from user-level analytics still matter in B2B of course, but alone, and without account-level context, they fall short.

That’s because, in B2B, every user event happens in the context of a team, workspace, company, or account.

People (users) work together in a team.

• Slack: users send messages, and others in their team/company read them and reply.

• Loom: users send videos (Looms), and others in their team/company view them, react and comment.

• Airtable: users create databases (Bases), and they and others in their team/company collaboratively update them.

• Jira: users create tickets, and they disappear into the ether (shoutout to Adam Fishman) 😉

Jira jokes aside, with user-level analytics alone, all of that team context is missing.

Questions that user-level analytics cannot answer

Think about questions such as the ones below:

• How many teams/companies have adopted and are still using our new feature?

• Has this account reached this important usage milestone? When did they do that?

• How long, on average, does it take new accounts to activate?

• What percentage of accounts reach the setup moment within their first 7 days?

• What’s our account level retention at 7, 30, 90, 180, 365 days?

• What behaviour is predictive of an account monetising?

Questions like these can't be answered without account-level data and tools that let you analyse at the account level.

You can’t use user-level analytics to answer these questions because of the multi-player nature of B2B. Account-level analytics aggregate individual user behaviour at the team/workspace/account level, enabling questions like these to be answered easily.

To give an example, in B2B SaaS, it’s not uncommon for different users to complete different tasks on the overall activation journey.

At Snyk, activation was defined as F30D, meaning the account Fixed at least one detected vulnerability in the first 30 Days.

The Setup moment was the account successfully connecting their SCM system (GitHub, Bitbucket, GitLab etc.) and scanning a repository.

The Aha moment was viewing the details for at least one of the detected vulnerabilities.

The Habit moment was the remediation of a detected vulnerability (within the first 30 days).

It was quite common that the steps needed to reach the setup moment would be completed by a different user (in smaller companies - a tech lead, in larger companies - someone in the AppSec program) than those fixing the vulnerabilities (developers).

Let’s say you then want to build an activation funnel that answers the question, “How many new accounts in the last 90 days reached Setup, Aha and Habit moments?”

If you have the account data and a tool that supports account-level analysis, it’s easy.

Without either of those and you’re stuck. You need both.

Grouping user-level analytics by account is not the same

Grouping user-level analytics by account is complementary, not a replacement for true account-level analytics.

Account-level analytics will allow you to aggregate the actions of all users within an account as if they were one, and then look at the behaviour of each account.

As an example:

A Loom product team might ask, “What is the 12-week retention of new teams, where the retention event is defined as recording and sharing a new Loom? How are we improving this over time?”

They’d need account-level analytics for this.

Grouping user-level analytics by account/workspace would allow them to look at the user retention for each individual account. But it’s still user retention, not account-level retention.

You can ask and answer more questions when you have both user and account-level perspectives.

The Loom product team might ask, “In accounts where 12-week retention is less than 20%, what % of users are creating Looms each week? What about accounts where 12-week retention is more than 60%? What are users doing differently in these two cohorts of accounts?”

B2B KPI design

In B2B, ensure you are tracking primary KPIs at the account level that include:

• Signups

• Activation (Setup, Aha and Habit moments)

• Engagement (States)

• Monetisation

Optimising for these at the user level usually isn’t appropriate in B2B.

Yes, you can and should still track user signups, but what’s really important for your business and sales opportunity pipeline is how many distinct teams/companies have signed up and reached significant product milestones such as team habit formation.

Yes, you can and should still track the breadth and depth of user engagement, but you won’t understand if what you’re seeing is good or bad without knowing how those users are distributed across accounts.

Consider this simple (completely hypothetical) example.

Loom has 1M users, split across 10,000 paying companies.

80% of users are active in the product, as measured by Weekly Creating Users (WCU), so 800,000 WCU.

Is this a good situation for Loom?

Loom can’t know the answer to that question without the account-level perspective of something like Weekly Creating Teams (WCT).

800,000 WCU and 9000 WCT tells a very different story to 800,000 WCU and 1000 WCT.

Only 10% of paying companies are active in the latter - more Doom than Loom!

But it should be clear that you need both perspectives to understand what’s going on.

9000 WCT (90%) with only 10,000 WCU would be equally concerning.

Signals for use across the company

This account-level perspective also becomes critical for use cases across the company, such as:

• Input to PQA scoring and providing rich data for sales interactions

• Feedback on acquisition channel performance

• Customer health scoring for CS teams

• Support team resource modelling

When thinking about your event instrumentation, involve stakeholders from across the company to understand the type of questions they have about accounts.

How to track and analyse behaviour at the account level

When instrumenting code, your tracking calls will need to identify the user and the account the event belongs to.

Note that it is the association of the user event to an account that is important - not the association of a user to an account, as at first may seem logical.

That’s because account context can change. A single user might be part of different accounts/workspaces, so their account context would change when they switch workspaces. You need to be able to see which account context every event was made under.

If you’re using Segment, you’ll typically make the association with a group call that most analytics platforms natively understand and map to their account entity.

Some analytics platforms include account-level functionality out-of-the-box (e.g. June).

Others (Amplitude) don’t, and it’s an optional add-on. If your product is B2B and you use Amplitude and don’t have the Accounts add-on, you’re analysis is severely impaired.

Amplitude really ought to include this OOTB for their B2B customers.

Summary

User-level behavioural analytics still have immense utility in any situation where you want to break down team activity into the things that users do to reach aggregate milestones.

Ultimately, these user-level behaviours are the levers at your disposal that you will experiment on to influence the aggregate outcomes for the team or account.

But account-level behavioural analytics provide essential perspective for cross-functional teams in B2B, augmenting user-level analytics and unlocking answers to important questions that B2B teams need to ask.

Thank you for reading The Product-Led Geek. This post is public, so feel free to share it.