The average B2B SaaS company with a Segment or Mixpanel implementation is capturing somewhere between 50 and 300 distinct event types. Page views, button clicks, feature interactions, API calls, export events, settings changes — the event stream is enormous. For a product team, this breadth is intentional: you want to know how users navigate, where they drop off, which features land. For a CS team, this same breadth is mostly noise.
CS teams don't need to understand the full usage surface. They need to understand the specific behavioral signals that predict whether an account will stay or leave. Those two information needs overlap, but they're not identical, and conflating them is how CS teams end up drowning in product data while still missing early churn signals.
The Signal Hierarchy: Not All Events Are Equal
The first principle for CS-relevant telemetry is that events are not equally predictive of retention outcomes. Some behaviors are strongly correlated with long-term retention. Some are correlated with churn. Some are neutral — they happen at roughly the same rate in retained and churned accounts and carry no useful signal.
A rough hierarchy, based on patterns we've seen consistently across different B2B SaaS verticals:
Tier 1: High-signal events (strong correlation with retention or churn). These are behaviors that, when you look at your retained vs. churned cohorts, cluster differently. Feature depth events — using advanced configurations, saving templates, creating automations, connecting integrations — tend to cluster heavily in retained accounts. Data portability events — export, API data pull, "download all data" — cluster in accounts approaching churn. Settings exploration of billing and account management pages (not during onboarding) clusters in pre-churn accounts.
Tier 2: Medium-signal events (useful in context, not standalone). Login frequency, session length, and pageview counts fall here. They're useful as trend indicators — a 40% drop in WAU over two weeks is meaningful — but an absolute WAU number without trend context is close to useless. A team that logs in three times a week and has done so consistently for eight months is not at risk. A team that was logging in daily and has dropped to once a week is in trouble, even if the absolute number is the same.
Tier 3: Low-signal events (noise at the CS layer). Individual page views within normal workflows, hover events, minor UI interactions, report rendering events — this is data that matters for product UX analysis but has no reliable correlation with retention at the CS layer. Building health scores or alert logic on top of this data creates false positives that erode trust in the health score system.
DAU/WAU Ratios: How to Use Them Correctly
DAU/WAU (daily active users divided by weekly active users) is one of the most referenced CS telemetry metrics and one of the most misapplied. The ratio measures engagement intensity — what fraction of weekly active users are active on any given day. A ratio of 0.20 means one in five weekly users logs in daily. A ratio of 0.50 means half do.
The correct use for CS purposes is not to compare DAU/WAU ratios across accounts — the "right" ratio depends entirely on the product's intended use frequency. A daily task management tool and a quarterly reporting tool have completely different baseline ratios. Comparing them on the same scale is meaningless.
The correct use is to compare an account's DAU/WAU ratio against its own historical baseline and trend. A drop from a consistent 0.45 to 0.27 over three weeks in an account that uses the product as a daily workflow tool is a significant signal. A stable 0.12 in an account that uses the product for weekly team syncs is not.
To use DAU/WAU correctly in a CS context, you need a baseline period (first 60-90 days after full onboarding), account-specific baseline tracking, and threshold logic that fires alerts based on delta from that individual baseline rather than against a global threshold. This is more infrastructure than "pull the WAU metric from Mixpanel" — but it's the only form of the metric that's actually predictive.
Feature Adoption Velocity: The Most Underused CS Signal
Feature adoption velocity measures how quickly an account is expanding its use of available features over time. An account that activated 3 of 8 core features in month one, 5 of 8 in month two, and 7 of 8 in month three is showing strong upward adoption velocity. An account that activated 3 of 8 in month one and is still at 3 of 8 in month three has stalled.
Adoption stagnation is one of the strongest leading indicators of eventual churn, and it typically appears 60-90 days before any other signal moves. The account is technically still using the product — the sessions are happening, the WAU looks fine — but they've hit a ceiling on how deeply they've integrated it. From the customer's perspective, this often means the product "works for what we use it for" but hasn't expanded into a workflow dependency. That's a vulnerable position: if a better-priced alternative or a product the team is already using adds overlapping functionality, the switching cost is low.
CS teams that monitor adoption velocity can intervene during the stagnation window — proactively scheduling feature enablement sessions, surfacing use cases the account hasn't explored, connecting them with peer accounts who went through the same activation journey. That intervention is high-value and has no equivalent once the account starts actively evaluating alternatives.
The instrumentation requirement: you need to define your "core feature set" — the 6-12 features that represent full product adoption for your use case — and track whether each account has activated each one. This is a product analytics query, not a CS platform metric, which is why it frequently doesn't make it into health scores. But it should.
Session Patterns Over Session Counts
Many CS teams track session counts: how many sessions did this account have this week? What's the monthly active user count? These are reasonable starting points but they miss the pattern information that's more predictive.
What matters more than session count:
Session distribution across the user base. An account with 10 licensed seats and 8 active weekly users is in a healthier position than one with 10 seats and 2 power users driving all the activity. When the power users leave or change roles, the second account loses its entire engagement. The first has broad adoption that's more resilient to individual contact changes. A "user concentration risk" metric — what percentage of total session activity comes from the top 2 users — is a useful health signal.
Time-of-day and recency patterns. An account whose users were logging in throughout the workday and are now primarily logging in for brief end-of-day sessions may be showing workflow integration decline. The product is no longer embedded in the daily rhythm; it's become a reporting tool they check once before close. This pattern is subtle but tends to precede WAU drops by several weeks.
Feature pathway depth. Users who navigate into advanced settings, create saved configurations, set up automations, or invite additional teammates are showing integration investment. Users who stay in the same 2-3 screens every session are showing surface-level engagement. Both might show identical session counts.
A Scenario: Telemetry-Driven Early Intervention
Consider a horizontal B2B SaaS platform — $7.4M ARR, 340 accounts, CS team of five. One account, representing $62K ARR, shows the following telemetry pattern over a 45-day window:
Days 1-15: Normal usage. 6 of 10 core features active. WAU/DAU consistent with their historical baseline. Primary contact engaging with CSM touchpoints on normal cadence.
Days 16-30: Feature adoption velocity flat — still at 6 of 10. A new feature released in this window (automated reporting) is being adopted by 70% of comparable accounts but shows zero activation for this account. Session distribution shows increasing concentration — 2 users now driving 78% of activity vs. 52% 60 days ago.
Day 31: The account's product analytics show their first visit to the billing management page since initial setup.
Day 38: Their CSM gets an automated task: "Feature adoption stalled at 60-day plateau. User concentration risk elevated. Billing page visit detected. Recommend proactive enablement call." The CSM schedules a call, finds out the team has been too busy to explore the new reporting feature, schedules a 30-minute hands-on session, and surfaces two use cases the account hadn't considered. Feature activation follows over the next two weeks.
Sixty days later, the account expands to the next pricing tier. Without the telemetry-driven intervention at day 38, the trajectory was pointing toward a non-renewal conversation in the following quarter.
What to Ignore (Seriously)
We're not saying more data is always better — the opposite is the problem. CS teams that try to monitor 50 event types end up with health scores that are averaging noise. Three categories of product telemetry that should generally be excluded from CS health scoring:
Navigation events within core workflows. How a user moves between screens they use daily tells you about UX, not about health. If you're including click-depth or scroll events in your CS health model, you're adding noise.
API activity for API-heavy accounts. If a customer has integrated your product via API and their primary consumption is programmatic, session metrics and button clicks are irrelevant. API call volume and error rates are the right telemetry for these accounts, and they need separate threshold logic.
Short-window spikes without trend context. A 3x spike in sessions during one week might mean the account is onboarding a new team, running a training, or exploring a feature — not that they're more engaged than usual. Without trend context, single-week anomalies create alert noise that burns CSM credibility when the account turns out to be fine.
The right telemetry stack for CS purposes is narrow and deep: a small set of high-signal events tracked consistently over time with trend logic applied at the account level. That produces actionable signals. A broad event stream averaged into a composite score produces a number that looks like a health metric but doesn't behave like one.