Logging in is not usage
A product team buys an analytics platform, drops the snippet in, and three months later has a chart of monthly active users that nobody has ever used to make a decision. The chart is not wrong. It answers a question nobody asked. An account can log in every weekday and be a month from cancelling, and a different account can touch the product four times a quarter and be the most secure revenue on the book. Counting sessions cannot tell those apart, and that is what most instrumentation counts.
The work that makes usage data worth its cost happens before any code is written. It is deciding what the product is for, in one sentence, and then instrumenting that one thing well.
You are probably here because
- An account churned and the health score was green the week before
- Two dashboards disagree about how many customers you have
- Someone asked what percentage of customers use a feature and the honest answer took four days
- The analytics bill grew faster than revenue and nobody can say which events caused it
These are taxonomy problems and unit-of-analysis problems. Neither is fixed by a better tool.
Pick one value event and defend it
Every product has an action that is the reason customers pay. An invoice sent. A report exported and opened. A shift published. A candidate moved to offer. A ticket resolved. Whatever it is, name one, define it precisely, and make it the spine of your reporting.
The test is simple and uncomfortable: if this number went to zero for a customer, would they cancel? If yes, you have found it. If the answer is "probably, eventually", you have found a proxy for engagement and not a measure of value, and it will behave like one when you try to predict renewal from it.
One value event is enough to start. Two or three tiers — a value event, a set of supporting actions, and a small number of admin or setup actions — will carry a product for years. What does not work is instrumenting everything so the answer will be available later. Later never arrives, and the bill does.
In business software, the account is the unit
Monthly active users is a consumer metric that escaped into business software and did real damage. A two-hundred-seat account with twelve weekly users looks healthy in a user-level chart and is in serious trouble in a renewal conversation. The unit that renews is the account, so the unit of analysis is the account.
Roll everything up: active seats as a fraction of licensed seats, value events per account per week, the count of distinct departments or teams touching the product, and whether the person who signed the contract has logged in this quarter. That last one is not a joke. In a great many cancellations the economic buyer had not opened the product in five months and heard about it only when the invoice arrived.
Daily active users is worse than useless for anything with a weekly or monthly rhythm. If your product is used at month-end close, on Monday shift planning, or when a claim comes in, then a daily chart is mostly a picture of the calendar. Measure on the cadence the work actually has.
Activation is discovered, not decided in a workshop
Activation is usually defined in a room, by the people who built the product, and it usually reflects what they wish mattered. The better method is to derive it. Take accounts that signed up nine or more months ago, group them by what they did in their first thirty days, and look at who is still paying now.
You are looking for the behaviour with the largest gap in later retention: teams that connected a second data source, or invited a third user, or completed a first cycle end to end. That behaviour is your activation definition, and it is frequently not the one product marketing has been using.
Two honest caveats. This is correlation, so treat the result as a hypothesis to test rather than a lever to pull. And it needs volume — a few hundred accounts with enough history. Below that, the pattern you find is noise with a chart around it, and talking to twenty customers will teach you more in a week.
What client-side collection quietly loses
Browser-based tracking is easy to install and lossy in ways nobody puts in the report. Content blockers, privacy modes, corporate proxies and mobile network conditions all drop events. The loss varies enormously by audience: for a general business audience it commonly runs somewhere in the range of eight to twenty percent, and for products sold to engineers and security teams it can be far higher.
The loss is not random, which is the actual problem. It skews toward the technically sophisticated and toward regulated enterprises with locked-down browsers — often your best accounts. Anything used for a commercial decision should be emitted server-side, where you control it.
| Source | Good for | What it loses | Use it for a renewal decision? |
|---|---|---|---|
| Browser SDK | Funnels, page flow, UI experiments | Blocked or dropped events, skewed toward sophisticated users | No |
| Server-side events | Value events, entitlement, billing-relevant actions | Anything that never reaches your backend | Yes |
| Application database | State: seats, plan, objects created, configuration | Sequence and intent — it shows what is, not what happened | Yes, alongside events |
| Mobile SDK | In-app behaviour, crash correlation | Offline sessions until sync, plus version fragmentation | Only with server confirmation |
| Support and billing systems | Ticket volume, invoice disputes, downgrade requests | Everything the customer never reported | Yes, and it is chronically ignored |
The taxonomy is the project
An event name is a public interface. Once dashboards, alerts and a customer success playbook depend on it, renaming it is a migration. Fix the conventions in the first week, in a document, and enforce them in review.
Past tense, object then action, one name per concept: invoice_sent, not SendInvoice, Invoice Sent and send_inv in three different files. Properties carry the detail rather than multiplying the event names. Keep a registry in the repository next to the code, add a schema version, and reject an event in continuous integration if it is not in the registry. That last mechanism is what stops the drift, because a convention nobody can violate is the only kind that survives a busy quarter.
Watch cardinality while you are at it. An account identifier as a property is fine. A free-text search string, a raw URL with query parameters, or a session identifier as a property will multiply your storage, slow every query, and show up on the invoice.
Where the effort pays — our weighting for a first build
Weights sum to 100. Our starting allocation, not a measurement. The last row is where most teams spend first.
Health scores that only predict logins
Customer success teams want one number per account, and the request is reasonable. The usual implementation is not. A score weighted mostly on login frequency and page views predicts login frequency, which is a thing you already knew and did not need a model for.
A score is worth having when every component is something a human can act on. Seat utilization falling means a conversation about rollout. The last admin login in ninety days means a relationship problem. A support ticket about an integration failing means an engineering escalation. If a component of the score has no matching action, it is decoration weighted at fifteen percent.
Start with rules, not a model. Three or four thresholds that a customer success manager helped write will outperform a churn model trained on four hundred accounts, and more importantly, the team will believe it. When you do have thousands of accounts and years of outcomes, revisit the question — and check the model against the obvious baseline before you deploy it.
Event volume is a bill, and it grows in the dark
Most product analytics platforms price on monthly tracked users, event volume, or both. A mid-size business product commonly sits somewhere between one and eight thousand dollars a month. The way that becomes a five-figure line item is an autocapture setting that records every click and page view on every session, none of which anyone queries. Before you turn autocapture on in production, decide who will be reading those events, and set a budget alert on the account.
Land the raw events in your own warehouse
Send events to your analytics tool and to your own storage, from day one. The tool is optimised for a particular set of questions and will eventually refuse an important one — usually the first time someone asks to join usage against revenue, support tickets or the sales pipeline.
Raw events in your own warehouse also mean you can recompute history when a definition changes, and a definition will change. If activation is redefined in March, the version that lives only inside a vendor's aggregation cannot be recomputed backwards. Yours can. This is also the answer to vendor migration, which is otherwise a project that starts with the sentence "we have no history before June."
What does not belong in an event
Customer content, free-text notes, email addresses, names of the end customer's own customers, anything from a document body. Event payloads end up in a third-party system, in exports, in a screenshot in a support ticket, and in a data-processing agreement that somebody will eventually read carefully.
Send identifiers and let the joins happen in your own warehouse where you control access. If your customers are in health, finance, education or anywhere with a privacy commitment in the contract, this is not a preference — it is a term you already agreed to. Write the rule down once and check it in review, because the person adding a helpful debug property in month fourteen will not have read this article.
When you do not need any of this
Under about fifty paying accounts, do not buy an analytics platform. Write four queries against a read replica of the production database, run them weekly, and put the results in a shared document. You will learn more, faster, and the cost is one afternoon. At that scale you can also just call the customers, which nothing on this page can replace.
Instrumentation earns its cost when three things are true at once: you have enough accounts that individual conversations no longer cover the population, you have people whose job depends on the answer, and you are prepared to change something because of it. Any product built to satisfy a board slide, with nobody accountable for acting on it, will be abandoned within two quarters. We have been asked to rebuild several of those, and the rebuild is not the fix.
What we are called in to fix
- Autocapture on everything, a five-figure bill, and no question anyone can answer
- User-level metrics for an account-level business, so seat decay is invisible
- Three names for one event across web, mobile and backend
- Commercial metrics collected client-side, undercounting exactly the enterprise accounts that matter
- A health score weighted on logins, green the week before a cancellation
- No raw event history, so a definition change cannot be applied to the past
- Customer content inside event properties, discovered during a security questionnaire
- Anonymous and identified users never reconciled, so signup funnels double-count
A four-week instrumentation pass
From nothing to numbers you would act on
Step six is the one that determines whether any of it survives. A number with no owner and no triggered action becomes a chart that loads slowly and is eventually removed by someone doing housekeeping.
Before you ship the instrumentation
- One value event, written in a sentence, agreed across three teams
- Every commercially meaningful event is emitted server-side
- An event registry lives in the repository and CI rejects unregistered events
- Raw events land in storage you own, not only in the vendor
- Account-level rollups exist: seats used, value events, admin last-seen
- No customer content or personal data in any event property
- Cardinality reviewed on every property before it ships
- Each health-score component maps to an action and a named owner
- A billing alert is set on event volume
Bottom line
Decide what the product is for and instrument that. Roll it up to the account, because the account is what renews. Emit anything commercial from the server, keep the raw history in storage you control, and put a name and an action next to every metric you intend to keep. Do that with thirty events and you will be ahead of most teams tracking three hundred, and your bill will be a tenth the size.
Frequently asked questions
Twenty to forty is enough for most products, and the discipline of choosing them is most of the benefit. Teams that instrument three hundred events almost never query more than a dozen, and the rest are cost, cardinality and noise. Add events when a specific question needs one, not in case a question arrives.
Both, for different purposes. Browser collection is right for interface flow and experiments and is lossy in a biased way — blockers and locked-down corporate browsers skew the loss toward sophisticated and enterprise users. Anything that feeds a renewal, pricing or billing decision should be emitted server-side, where nothing between you and the customer can drop it.
Usually because the score is mostly login frequency, which measures habit rather than value, and because it is computed per user in a business where the account renews. Rebuild it on seat utilization, value events per account, whether the economic buyer has appeared this quarter, and support signal — and drop any component that does not map to something a person would do.
Below roughly fifty accounts, neither — four weekly queries against a read replica will do more. Above that, land raw events in your own warehouse regardless, and add a platform when non-technical people need to explore funnels without asking an engineer. The warehouse is the durable asset; the platform is an interface you may change.
Cohort your accounts by first-thirty-day behaviour, then look at who is still paying nine to twelve months later, and find the behaviour with the biggest retention gap. Treat the result as a hypothesis rather than proof, and remember it needs a few hundred accounts with real history before the pattern means anything.