Industry / SaaS
Data and AI for SaaS connects product usage, billing and revenue data into one governed model, so retention and expansion decisions rest on a shared definition of an active user or account rather than competing dashboards. Quorlytic reconciles usage events to the billing source of truth and segments retention analysis by cohort and acquisition source.
By QuorlyticUpdated
A software business measures itself with two sets of records that disagree by design: what the product observed someone do, and what the contract says they bought. Usage is eventful, anonymous at the edges and versioned by whoever shipped last; billing is periodic, account-shaped and governed by a subscription state machine. This page sets out the lifecycle both describe, and what has to be true before product and revenue decisions can be made from them together.
Lifecycle
Eight stages of a customer relationship, and a second structure underneath it. The stages are what the business talks about; the identity, account, event, plan and revenue records are what the data actually has. Most reporting arguments come from treating one as if it were the other.
Acquire
Someone arrives from a campaign, a search, a referral or a colleague's link. At this point the business has an anonymous identifier and nothing else.
Sign up and join identity
An account is created and the anonymous visitor becomes a known user. Analytics platforms backfill within the session; activity from before the identifier existed is not reprocessed, so the join has a hard boundary.
Activate
The user reaches the point where the product has actually done something for them. Activation is a definition the business chooses, and it is worth writing down before it is measured.
Adopt across the account
Usage spreads from the person who signed up to the team around them. An account is not a user, and a healthy-looking account can be one enthusiast and twenty dormant seats.
Subscribe and bill
The commercial relationship becomes a subscription with a state machine of its own: trialing, active, past due, paused, cancelled. That state is about payment, not about use.
Expand
Seats, usage or plan tier increase. A mid-period change prorates, which means revenue attributed to a period and product used in that period are computed on different boundaries.
Renew or churn
The relationship continues or it ends. By the time the decision is visible in billing, the behaviour that produced it is months old.
Learn
Work out which product and commercial changes actually moved anything — which requires a comparison group, not a before-and-after chart.
Where it breaks
Six failures that appear in software data estates repeatedly. Most of them are identity or versioning problems that only become visible when someone asks a revenue question of product data.
Product analytics stitches an anonymous visitor to a user when they sign in, but the rules and the boundary differ per tool — and activity recorded before the identifier existed is generally not reprocessed.
What it costsAcquisition attribution and time-to-activation are computed over a population that silently excludes part of the journey, and two tools give two different answers with no way to reconcile them.
Metrics are defined per user, reported per account and sold per seat, with no single place that states how one rolls up to the other — especially where a person belongs to more than one account.
What it costsAdoption looks healthy because one power user is active, retention is computed on the wrong denominator, and account health scores rank the wrong customers.
An event is renamed or its properties change in a release, and the dashboard that depended on it keeps rendering — just with a series that stops.
What it costsA trend break is read as a product or market change, and the correction arrives weeks later after someone has already acted on it.
Subscription status describes payment, not use. A subscription can be active while invoices are outstanding, and it can be past due while the product is being used normally.
What it costsChurn risk is assessed from billing records that are healthy right up until they are not, and genuine disengagement is invisible until the renewal date.
Staff accounts, automated tests, demo tenants and support impersonation all emit the same events as customers, and no flag separates them at source.
What it costsUsage is overstated in exactly the accounts the team looks at most, and any model trained on the mixture learns the company's own behaviour.
A pipeline replay or a historical import writes events with the processing date rather than the original event time, or overwrites a period that had already been reported.
What it costsA quiet week becomes a record week, cohort analysis shifts under the reader, and nobody can tell a data operation from a customer action.
Functions
Software organisations divide by function, and each function trusts a different system. The foundation has to make product, commercial and finance views reconcilable without asking any of them to abandon the tool they run on.
| Function | The question it owns | Data it needs | Analytics | Decision |
|---|---|---|---|---|
| Product management | Is this feature used, by whom, and does it matter? | Versioned product events, feature coverage by account and role, release and flag history | Adoption and depth analysis by cohort, funnel analysis, experiment readout where one exists | What to invest in, change or retire |
| Growth and acquisition | Which acquisition sources produce accounts that stay? | Anonymous-to-known join, campaign context, signup and activation events, early retention | Cohort retention by source, activation funnel analysis, incrementality testing where feasible | Where acquisition spend goes |
| Customer success | Which accounts need attention, and how far before renewal? | Per-seat activity, feature coverage, support history, contract state and renewal dates | Engagement scoring with a stated definition, disengagement detection, intervention tracking | Which accounts a human contacts this week |
| Revenue and finance | What did we actually earn, under which arrangement, in which period? | Subscription status and period boundaries, invoices, proration, plan and seat history | Recurring revenue movement analysis, reconciliation of billing to product entitlement | What is reported, and where revenue and usage disagree |
| Pricing and packaging | What does each plan actually deliver, and to whom? | Entitlements by plan, usage against limits, plan-change history, discounting | Usage-to-plan fit analysis, migration impact modelling, limit-breach patterns | How plans are structured and what moves between them |
| Platform and data | Can these numbers be trusted together? | Event contract and schema versions, identity mapping, internal-traffic flags, backfill log | Contract compliance checks, identity coverage analysis, reconciliation between product and billing | Which measures are safe to publish and which need repair first |
Decisions
Four decisions traced from the question to the measure. The recurring caveat is the same one every software business has to live with: usage that precedes an outcome is evidence of association, and only a designed comparison turns that into a claim about cause.
Data required
Analytics
Decision
Which accounts have started, which step to fix, and which onboarding cohort needs contact.
Measurement
What this does not settleActivation is a definition, not a fact. Changing it changes every historical number, so the definition needs a version and an owner before it is used to judge anything — and an account can satisfy it while remaining one enthusiast and twenty dormant seats.
Data required
Analytics
Decision
Which behaviours to treat as early signals, and how far ahead they are visible.
Measurement
What this does not settleAccounts that use a feature and renew may be renewing for reasons that also caused them to use it. Without a deliberate comparison group, this identifies where to look rather than what to change, and a signal tuned on past churn will be optimistic about future churn.
Data required
Analytics
Decision
Which accounts a person contacts this week, and what the conversation is about.
Measurement
What this does not settleSubscription status answers a payment question. An active subscription does not mean every invoice is paid, and a past-due one does not mean the product has stopped being used — so a risk model built on billing alone will be confidently wrong in both directions.
Data required
Analytics
Decision
Whether to keep, extend, change or retire the thing that shipped.
Measurement
What this does not settleMost product changes ship alongside other product changes, a pricing test and a marketing push. A before-and-after chart cannot separate them, and presenting one as an effect is the most common measurement error in software businesses.
Illustrative interface
A fictional screen showing the shape of a pre-renewal review. No real company, account, person or figure is represented, and every value here is invented.
| Account | Contract state | Product state | Review |
|---|---|---|---|
| OK: Account A · 14 seats | Active, renews next period | Core workflow used weekly by most seats | No action |
| Watch: Account B · 60 seats | Active | Usage concentrated in two seats since a plan change | Investigate before renewal |
| Watch: Account C · 8 seats | Past due — invoice unpaid, access retained | Unchanged | Billing issue, not a product issue |
| Risk: Account D · 25 seats | Active | No authenticated events for a full billing period | Escalate — contract state is hiding it |
Data foundation
Software data is unusual in that the business generates nearly all of it and still cannot reconcile it. The systems are internal, the schemas change with every release, and the join between what the product saw and what the contract says is the piece that is almost never owned by anyone.
Source systems
Nearly all internal, and still hard to reconcile. The ten systems are enumerated in the inventory below.
Ingestion
Replay preserves event time rather than rewriting a reported period
Cloud platform
One place product and commercial history meet
Identity & rollup
Four hops, each one measured for coverage
Contracts & quality
A rename fails a build instead of ending a chart
Product & revenue models
Defined once, reconciled between product and finance
Decision surfaces
Where product, growth and success teams work
Action
A decision with an owner and a recorded outcome
The join that matters most is the cheapest one to neglect: anonymous identifier to user, user to account, account to subscription, subscription to revenue. Each hop loses some population, and the loss is not random — it concentrates in exactly the self-serve and multi-account customers that growth teams care about. State the join, measure its coverage, and publish that coverage next to any number computed across it. The semantic-model and metric-governance guide explains how to carry those account-grain definitions into shared reporting, so a product activation measure and a finance revenue measure retain their distinct denominators.
User and account actions, feature usage, client and version context
Check before trustingSchema changes ship with releases; an unversioned rename ends a series without an error
Accounts, users, entitlements, configuration, current state
Check before trustingHolds state, not history — yesterday's plan is frequently unrecoverable from it
Login identity, session records, SSO and directory mapping, roles
Check before trustingThe authoritative user record; one person may map to several accounts and several identities
Subscription status, period boundaries, invoices, plan and seat changes, proration
Check before trustingStatus describes payment rather than use; period boundaries rarely align with product reporting periods
Opportunities, contract terms, renewal dates, account ownership
Check before trustingMaintained by people under quota pressure, so timeliness and completeness vary by stage
Tickets, severity, resolution, contact history
Check before trustingContact identity is often an email address that matches no user record
Campaign exposure, email engagement, lead records
Check before trustingIts account concept is usually a lead or a domain, not the billing account
Flag state by account and user, experiment assignment, rollout history
Check before trustingThe only reliable record of who actually received a change; frequently retained for weeks, not years
Modelled and reconciled history across all of the above
Check before trustingBackfills must preserve event time; a replay written at processing time rewrites history
What each plan grants, limits, and how migrations map
Check before trustingEntitlement drift between what is sold, what is configured and what the product enforces
Analytics & AI
The same dependency chain as elsewhere, with a software-specific first rung: the event contract. Everything above it inherits whatever the instrumentation did or did not record, and no modelling recovers an event that was never emitted.
Events that are named, versioned, owned and tested, so a release cannot silently end a metric. This is instrumentation work, not analytics work, and it is the rung most often skipped.
RequiresA declared event schema with compatibility rules, and a check that fails a build rather than a dashboard
Anonymous to user, user to account, account to subscription — each hop stated, measured for coverage, and published with the number that depends on it.
RequiresOne authoritative user record, an account roll-up rule, and internal traffic flagged at source
Adoption, retention and recurring revenue movement defined once, reconciled between product and finance, with period boundaries stated.
RequiresDefinitions with named owners, and an agreed treatment of proration and mid-period change
Explaining a movement: which cohort, which plan, which release, and how much of it is a data artefact such as a backfill or a flag rollout.
RequiresRelease and flag history joined to usage, and backfills recorded as operations rather than behaviour
Scoring accounts for risk or expansion potential, with the observation window fixed in advance and the score expressed as a prioritisation rather than a verdict.
RequiresOutcome history at account grain, a fixed window, and a named owner for each triggered action
Changes shipped with a comparison group and an outcome measure agreed beforehand, so the business can say what worked rather than what happened.
RequiresAssignment recorded and retained, pre-registered measures, and the discipline to report a null result
Maturity
Progress here is usually blocked by instrumentation rather than by modelling. The readiness test for each stage is something you can check in an afternoon.
Product, billing and marketing each report their own numbers, and the three do not agree in any meeting.
Ready for the next stage whenOne authoritative user and account record exists, and internal traffic is flagged at source.
Events are named, versioned and owned; a rename fails a check instead of ending a chart.
Ready for the next stage whenThe event schema is declared, compatibility rules are stated, and a breach fails a build.
Adoption, retention and revenue movement are defined once and reconcile between product and finance.
Ready for the next stage whenIdentity join coverage is measured and published alongside the numbers that depend on it.
Risk and expansion signals route to a named owner with a recorded intervention and outcome.
Ready for the next stage whenObservation windows are fixed in advance and false-positive rates are tracked rather than assumed.
Product and commercial changes ship with a comparison group and a pre-agreed outcome measure.
Ready for the next stage whenAssignment is retained, null results are reported, and post-hoc measure selection is treated as a defect.
Measurement
A measurement framework for the decisions above. Software metrics are unusually easy to compute and unusually easy to compute differently, so each one needs a definition owner before it is compared across teams.
| Measure | What it captures | Decision it informs |
|---|---|---|
| Activation rate | Share of new accounts reaching a defined first meaningful action | Which onboarding step to fix |
| Time to activation | Elapsed time to that action, read as a distribution with its tail | Where onboarding friction actually sits |
| Seat coverage within accounts | Proportion of purchased seats showing regular authenticated activity | Whether adoption is genuine or concentrated in one person |
| Feature adoption depth | How many of the capabilities an account pays for are actually used | Packaging, onboarding focus and what to retire |
| Gross and net revenue retention | Revenue kept from an existing cohort, before and after expansion | Whether growth is coming from keeping customers or replacing them |
| Logo retention by cohort | Accounts retained, by the period they were acquired in | Which acquisition sources produce durable customers |
| Expansion rate | Share of accounts adding seats, usage or tier in a period | Where packaging is meeting demand |
| Identity join coverage | Proportion of events and accounts successfully joined across each identity hop | How much to trust any cross-system number |
| Event contract compliance | Share of emitted events conforming to the declared schema and version | Whether instrumentation is safe to build reporting on |
| Share of changes evaluated | Proportion of shipped changes with a comparison group and a pre-agreed measure | Whether the organisation can say what worked |
These are common software measures and their usual reading, not results Quorlytic has produced for a client. Definitions vary between organisations — particularly for activation, an active account and the treatment of proration — which is why each needs an owner and a version before it is compared.
Principles
Active user, seat, account and revenue can each be counted several ways. Define the metric, its grain and its owner before building retention or expansion views. A single semantic model prevents the same customer being counted differently by two teams.
Usage events and billing records arrive on different clocks. Model them with clear identity and time handling, and reconcile to the billing source of truth. Preserve trial, upgrade, downgrade and churn context so movement can be explained.
Compare against a baseline and segment by cohort, plan and acquisition source. Expose where data is sparse or confounded. Avoid presenting a single retention figure without the definitions and filters behind it.
Choose a decision such as which accounts need attention, define the acceptance metric and identify the owner. Expand the model only after the first output is used.
Product analysis is only reproducible when events are governed: a stable name, the properties that travel with them, the identity that connects them to an account, and a version for every change. Without that contract, usage numbers drift silently and every retention debate becomes an argument about instrumentation rather than customers.
Engagement
A typical engagement can progress through these stages. It is a sequence rather than a proprietary method, and in software the instrumentation stage is the one most often underestimated because the data appears to exist already.
Discover
OutputAn inventory of the product and commercial decisions in scope, and who owns each one
Map identity
OutputA documented picture of the anonymous-to-user-to-account-to-subscription joins, with measured coverage at each hop
Audit instrumentation
OutputAn event inventory: what is emitted, what is versioned, what is missing and what is internal traffic
Define the measures
OutputActivation, active account, retention and revenue movement defined once, with owners and versions
Design the architecture
OutputA target-state design covering event contracts, identity resolution and product-to-billing reconciliation
Build the foundation
OutputPipelines, contract checks that fail a build, identity resolution and the reconciled models
Build the decision layer
OutputThe adoption, risk or revenue analysis the decision requires, with its observation window fixed
Operationalise and measure
OutputMonitoring, named ownership, an evaluation habit for shipped changes, and the next decision prioritised
Where this connects
The identity-resolution pattern behind the anonymous-to-user-to-account join, with match confidence retained
Event contracts, versioning and the reconciliation between product and billing that every measure above needs
Cohort, retention and experiment analysis scoped to what the instrumentation can actually support
One definition of activation, an active account and revenue movement, owned rather than negotiated per meeting
Acquisition measurement where attribution and incrementality are reported next to each other
Ownership and monitoring for pipelines whose schemas change with every release
The event contract in full: compatibility rules, enforcement and safe deprecation of a renamed field
Why acquisition credit and acquisition effect are different questions, and when each is appropriate
How to diagnose the product-versus-finance disagreement described above instead of arbitrating it
Detection, containment and replay that preserves event time rather than rewriting a reported period
Turning an account risk score into an intervention with an owner, rather than a leaderboard
Which questions on this page are description and which genuinely need a model
Questions
Assess the decision and the required definitions first. A dedicated tool may help collection and exploration, but a governed model is still needed where product and revenue measures must agree.
Your next data decision
Bring the business question.
We'll help shape the engineering brief.
