Account-Level Analytics: Why Aggregated User Data Fails B2B Teams
In B2B, '60% of users completed onboarding' is a meaningless number. Account-level analytics tells you which accounts completed onboarding and which are at risk. Here's why the distinction matters.
TL;DR: Every product analytics tool in the market aggregates user-level data. In B2B, this creates a fundamental distortion — the same metrics that look healthy in aggregate can hide dying accounts and inflate struggling ones. Account-level analytics means organizing every metric around the account as the primary unit, not the user. Until you make that shift, your data is lying to you.
Here’s a number that came out of a real analytics dashboard at a real B2B SaaS company: “78% of users were active this month.”
Sounds healthy. The exec team was happy. The board deck looked great.
Then they lost three of their top ten accounts at renewal. Combined, those accounts represented 30% of ARR. The CS team was blindsided. The data had said everything was fine.
Everything was fine — in aggregate. But aggregate user data in B2B is a magic trick. It makes problems disappear until they show up as churn.
What is the aggregation fallacy in B2B analytics?
The aggregation fallacy is when overall metrics look healthy while individual accounts are failing — and the structure of your analytics makes it impossible to see the difference.
Consider “60% of users completed the onboarding flow.” In a consumer app with 100,000 anonymous users, this is a meaningful conversion metric. You can A/B test the flow, improve the percentage, and move on.
In B2B, that number is essentially noise. Here’s why:
Your product has 500 users across 30 accounts. “60% completed onboarding” means 300 users finished. But you don’t know:
- Did Account A (your biggest customer, 80 users) complete onboarding? Maybe all 80 did — great. Or maybe only 5 did and the other 75 never came back.
- Did Account B (up for renewal next month, 20 users) complete it? If only 2 of their 20 users finished onboarding, that’s a renewal risk hiding inside a healthy-looking aggregate number.
- Are the 300 users who completed onboarding spread across all 30 accounts, or concentrated in 5 large accounts that are doing fine while 25 smaller ones are drowning?
The aggregate number is technically accurate and practically useless. This is the aggregation fallacy, and it infects every metric in a user-level analytics platform when applied to B2B.
Why does the same event mean different things at the account level?
Because context changes everything, and user-level analytics strips away context.
Example 1: Ten logins from one account vs. one login from ten accounts.
Your dashboard says “We had 10 logins today.” In user-level analytics, those are 10 equivalent events.
But what if all 10 logins came from one account? That’s one healthy account with a highly engaged team. Meanwhile, nine other accounts didn’t log in at all. You have a concentration problem masked as healthy activity.
Alternatively, what if those 10 logins came from 10 different accounts, one user each? That might look worse in aggregate (fewer total events per account) but it actually means broader engagement across your customer base.
Same event count. Completely different story. User-level analytics can’t tell the difference without manual work.
Example 2: Feature adoption.
“40% of users adopted the reporting feature.” This could mean:
| Scenario | What the Metric Says | What It Actually Means |
|---|---|---|
| All accounts have ~40% adoption | 40% adoption | Healthy, room to grow |
| 3 large accounts at 90%, rest at 5% | 40% adoption | Most accounts aren’t adopting |
| Free trial users inflating the number | 40% adoption | Paying customers might be at 15% |
| One power user per account, no team spread | 40% adoption | Champion risk — if they leave, adoption drops to 0 |
Same metric, four completely different realities. Account-level analytics separates these scenarios. User-level analytics mushes them into one number.
Example 3: “Daily Active Users” in B2B.
DAU is the king metric of consumer analytics. In B2B, it’s almost meaningless.
A B2B product might have 1,000 DAU. That sounds stable. But if last month Account X contributed 200 DAU and this month they contribute 50, that’s a 75% engagement drop in a single account — potentially a massive churn signal. The overall DAU number might not even move because Account Y happened to onboard new users that offset the decline.
DAU hides account-level stories in an aggregate average. You’d never know Account X was dying until they canceled.
What does the account-level shift look like?
It means reorganizing every metric, every dashboard, and every alert around the account as the primary unit of analysis.
Instead of “X% of users did Y,” you ask “Which accounts did Y, how deeply, and how does it compare to their own baseline?”
Here’s what changes:
| User-Level Metric | Account-Level Equivalent | Why It’s Better |
|---|---|---|
| Monthly Active Users (MAU) | Monthly Active Accounts + active users per account | Tells you breadth and depth |
| Feature adoption rate | Feature adoption by account | Identifies which customers need help |
| Retention rate (user) | Account retention + per-account engagement trend | Predicts actual revenue churn |
| Onboarding completion | Onboarding completion by account | Reveals which customers are stuck |
| Session duration (average) | Session patterns per account | Spots declining engagement before it’s obvious |
| DAU/MAU ratio | Per-account activity frequency vs. their own baseline | Catches individual account decline |
The account-level shift isn’t about adding a “group by company” filter to your existing reports. It’s about making the account the atomic unit. Every event belongs to an account. Every metric is computed per-account first, then aggregated if needed — not the other way around.
What do real-world account-level insights look like?
Let me walk through three scenarios that show the difference between what user-level and account-level analytics would tell you.
Scenario 1: The “healthy” product with hidden churn risk.
User-level view: 82% monthly retention rate, 70% feature adoption, DAU growing 3% month-over-month. Everything looks great.
Account-level view: Your top 5 accounts (60% of ARR) are healthy. Accounts 6-15 (25% of ARR) show flat engagement. Accounts 16-30 (15% of ARR) have declining active users, with 4 accounts showing less than 20% of their team logging in over the past 30 days. Three of those four renew within 90 days.
The user-level view says “keep doing what you’re doing.” The account-level view says “four accounts need intervention this week.”
Scenario 2: The feature launch that “succeeded.”
User-level view: New feature launched. 45% adoption in the first two weeks. Product team celebrates.
Account-level view: 45% adoption is concentrated in 3 early-adopter accounts that were involved in the beta. Of your remaining 27 accounts, only 8 have had any user try the feature, and most of those were a single user clicking around once. The feature hasn’t penetrated the customer base — it’s just popular with the same accounts that adopt everything.
The user-level view says “successful launch.” The account-level view says “you have a distribution problem.”
Scenario 3: The support ticket surge.
User-level view: Support tickets jumped 40% this month. Something is broken.
Account-level view: One account filed 35 tickets because they’re migrating to a new workflow and hitting edge cases. Remove that account and tickets are actually down 5%. The “surge” is one account going through a transition, not a product-wide problem.
The user-level view triggers a fire drill. The account-level view triggers a targeted CSM conversation.
How do you build an account-level analytics pipeline?
If you’re going to make this shift, here’s what the pipeline looks like:
Step 1: Event attribution.
Every product event needs to be attributed to an account, not just a user. If you’re using Segment, this means your identify and group calls need to associate users with accounts. Most B2B SaaS companies already do this — they just don’t have tooling that uses it.
Step 2: Account-level computation.
Raw events are user-level by nature (a user clicked a button, a user loaded a page). You need a computation layer that rolls these up to account-level metrics: active users per account, features used per account, engagement trend per account. This is where user-level tools fail — they don’t have this layer natively.
Step 3: Baseline comparison.
A healthy metric for one account isn’t healthy for another. An account with 5 users and 3 active is at 60% engagement. An account with 200 users and 60 active is at 30%. Same “active users” metric, different health story. Your pipeline needs to compare each account against its own baseline, not a global average.
Step 4: Alerting and surfacing.
The value isn’t in the data warehouse. It’s in a CS team member seeing “Account X has dropped 40% below its engagement baseline this week” and picking up the phone. The pipeline needs to surface insights where they’re actionable.
You can build this yourself. Many companies do, with a combination of dbt models, a data warehouse, and a BI tool. It takes a data engineer, a few months, and ongoing maintenance. It works, but it’s custom infrastructure for every company.
How does AccountLens handle account-level analytics?
AccountLens is an open-source product analytics platform that gives B2B Customer Success teams account-level health scores, feature adoption data, and churn signals. It was built specifically to solve the problem described in this entire post.
Here’s how it maps to the pipeline above:
- Event attribution: Events flow in via Segment webhook. AccountLens uses your existing
groupandidentifycalls to attribute every event to the correct account. No custom mapping tables. - Account-level computation: Health scores, feature adoption rates, and engagement trends are computed per-account automatically. This isn’t a “group by” on top of user data — the account is the primary entity in the data model.
- Baseline comparison: Each account’s metrics are compared against its own historical baseline, not a global average. An account declining from its own norm triggers a signal, even if the global numbers look fine.
- Surfacing: Your CS team gets a dashboard with account health, risk signals, and deep-dive views. No SQL. No engineering tickets. No waiting for the weekly data refresh.
It’s MIT-licensed, self-hosted, and free. Your data stays on your infrastructure. You can read the code, modify it, and contribute back.
The aggregation fallacy isn’t a tooling limitation — it’s a design choice that every user-level analytics platform makes. They chose the user as the atomic unit because that’s what consumer analytics needed. B2B needs a different choice. AccountLens makes it.
Frequently Asked Questions
Can’t I just use “group by company” in my existing analytics tool?
You can, and it gets you about 20% of the way there. The problem is that “group by” gives you filtered user-level data, not account-level computed metrics. You don’t get per-account health scores, baseline comparisons, or trend analysis. You get the same user-level charts with a company filter applied. It’s better than nothing, but it’s not account-level analytics.
What’s the minimum number of accounts where this matters?
Even with 10 accounts, aggregated data can mislead you. But the pain becomes acute around 30+ accounts, where your CS team can’t manually track every customer’s product usage. At 100+ accounts, operating without account-level analytics means you’re flying blind on most of your book of business.
How is account-level analytics different from what Gainsight does?
Gainsight is a CS operations platform — it manages playbooks, tasks, emails, and workflows. It has health scores, but they’re typically based on CRM data, NPS, and support tickets, not deep product analytics. Account-level analytics (as described here) is about computing health and engagement metrics from actual product usage data. Gainsight and AccountLens solve adjacent but different problems. Gainsight manages the CS workflow. AccountLens provides the product data that should inform it.
Does this mean user-level analytics is useless for B2B?
No. Your product team still needs user-level data for UX research, funnel optimization, and feature design. The point is that user-level analytics shouldn’t be the only lens, and it shouldn’t be what your CS team relies on for account health. Both levels of analysis have value — but in B2B, the account level has been neglected by nearly every analytics tool on the market.