Monday’s dashboard says activation fell. Nobody can remember whether the denominator includes accounts still setting up, whether test workspaces were removed or whether the activation event changed last week. The chart looks precise. The meeting has no decision to make.
Write the contract before the query
Start with the recurring customer job: producing a report from current data, for example, rather than opening the reporting app. Measure on the job’s schedule. A quarterly workflow does not produce a useful weekly retention signal merely because the meeting is weekly.
Give each metric a decision, event, eligibility rule, denominator, exclusions, fixed period and owner. Add a dictionary version and the evidence needed to distinguish a failed job from an unobserved one. Missing telemetry is a state to report, not a reason to shrink the eligible population.
Four metric cards, four different decisions
Scroll to compare the four metric cards.
| Metric card | Formula or definition | Boundary to record | Decision it can inform |
|---|---|---|---|
| First useful event | Eligible new accounts completing the named event inside the local setup window ÷ eligible accounts whose window has closed | Closed setup window; exclude tests and staff; deduplicate accounts; retain eligible unknowns | Which setup state to inspect |
| Retained job | Accounts completing the core job again ÷ accounts with an eligible repeat opportunity in that cohort period | Natural recurrence, paused accounts, known outcomes and eligible unknowns | Which repeat cycle needs investigation |
| Logo churn | Paying accounts ended in the period ÷ paying accounts active at the start | Period, trials, voluntary cancellation, failed payment and closure | Which cancellation evidence to open |
| Support burden | A proposed operating view of workflow-related contacts and handling time beside eligible active accounts | Bug, setup, billing, unclear state and incident consequence | Which product state or support path to examine |
The logo-churn formula above is a local operating definition, not a universal provider definition. Record whether cancellation means a request to cancel or the end of paid access, and how trials, failed payments and reactivations are treated. Stripe subscription analytics uses provider-specific definitions and lets you configure calculations for MRR, churn and active subscribers. Preserve the relevant settings alongside an exported number.
MRR is not “whatever recurs”
Document which recurring components enter your MRR view. Usage charges, taxes, credits, currencies and one-off services need explicit treatment; a dashboard definition is not an accounting standard. Stripe’s analytics documentation includes configurable discount treatment and a Usage MRR preview. Do not assume metered revenue is always excluded, or that a preview is available in your account. Name the report and configuration you actually use.
Google Analytics collects and processes measurement data into reports, with configuration affecting that processing. It cannot choose your product’s first useful event. Audit event names, duplicates and missing telemetry before interpreting a movement.
Filters also change what you can know. Google’s internal-traffic documentation distinguishes testing a data filter from activating it: excluded data is permanently unavailable in Analytics and BigQuery. A new exclusion can make a chart move without any change in customer behaviour.
Put each signal on the clock it deserves
Incident-led
Incorrect billing, failed imports, broken delivery or data-integrity states. Contain and investigate; do not wait for the dashboard meeting.
Operating review
Recent eligible starts, repeat opportunities, cancellations and support evidence. Choose one question to open, not five charts to admire.
Natural product cycle
Retention for monthly, quarterly or event-driven jobs. Review when another opportunity actually exists.
Commercial review
Package, cohort and pricing assumptions after comparable contract events—not after every account movement.
A fictional monthly review with two unknown outcomes
This twelve-account journal is invented for teaching; it contains no PBT activity or observed product results. The job is to turn the month’s client data into a report available for the client to use. Opening the app or merely attempting an import does not complete it.
- Dictionary version
- Monthly report v1. Count one completed job per account and calendar month. Repeated events or deliveries for that account’s report do not add completions.
- Eligible population
- Non-test accounts whose setup window has closed and which have a repeat monthly report due. Fix membership before examining completion records. The journal has ten eligible accounts; the two exclusions remain visible below.
- Observation window
- August 2026 UTC: from 1 August at 00:00 inclusive to 1 September at 00:00 exclusive. Assess August’s job using the records available at that cutoff. Later evidence requires a labelled correction, not a silent change to this snapshot.
- Known versus unknown
- A known outcome has a complete job record supporting either completion or confirmed noncompletion by the cutoff. No event in an incomplete record means unknown. Accounts with unknown outcomes remain eligible.
Scroll to read each account’s eligibility and outcome.
| Demo account | Eligible? | Record coverage | Outcome or exclusion |
|---|---|---|---|
| acct-demo-01 | Yes | Complete | Completed |
| acct-demo-02 | Yes | Complete | Completed |
| acct-demo-03 | Yes | Complete | Completed |
| acct-demo-04 | Yes | Complete | Completed |
| acct-demo-05 | Yes | Complete | Completed |
| acct-demo-06 | Yes | Complete | Completed |
| acct-demo-07 | Yes | Complete | Confirmed noncompletion |
| acct-demo-08 | Yes | Complete | Confirmed noncompletion |
| acct-demo-09 | Yes | Unknown | Unknown outcome |
| acct-demo-10 | Yes | Unknown | Unknown outcome |
| acct-demo-11 | No | Not assessed | Setup window has not closed |
| acct-demo-12 | No | Not assessed | Test workspace |
The denominator is 10 eligible accounts, not just the eight with known outcomes. Six completed the job, two are confirmed not to have completed it and two are unknown. Accounts 11 and 12 are ineligible for different, named reasons; neither is a missing outcome.
- Coverage: 8 ÷ 10 = 80%. We know the outcome for eight of the ten eligible accounts.
- Completion among known outcomes: 6 ÷ 8 = 75%. This describes the known subset only. It cannot stand in for the whole eligible population.
- Completion bounds among eligible accounts: 60–80%. If neither unknown completed, the count is 6 ÷ 10. If both completed, it is 8 ÷ 10. One completion would give 7 ÷ 10.
These are deterministic missing-data bounds, not confidence intervals, a statistical estimate or observed product results. They do not say which unknown outcome is more likely. Keep coverage beside the rate and investigate accounts 09 and 10; do not relabel them as failures or drop them to improve the fraction.
If the same fictional review reveals a delivery incident, do not wait to resolve every unknown before acting. Contain the delivery problem first: a customer may still be unable to use their report. Review the trace afterward.
A comparison with next month is only useful if the same rules describe both months. Changing eligibility changes who gets counted; extending the window gives accounts more time; changing instrumentation changes which outcomes become visible. Version the change and either reconstruct both periods under a comparable definition or mark a break in the series. A higher rate after a tracking repair is not, by itself, better retention.
A review agenda that ends in work
- Validate the measurement. List changed definitions, delayed records and missing events.
- Locate the customer job. Before first value, during repeat use, at delivery, in billing or at cancellation?
- Open the record. Event trace, support contact, cancellation note or invoice—not the chart alone.
- Name one owner. A solo founder can hold every role; the decision still needs an owner.
- Write the next action. Instrument, investigate, repair or deliberately gather more evidence.
What to leave off the dashboard
Leave out CAC, LTV/CAC, annualised tiny-period rates and borrowed “good churn” targets until you have the definitions and evidence to use them. Do not force every metric into a weekly cadence. Do not label provider-accepted email as a completed customer job. A shorter dashboard with visible unknowns is more useful than a KPI wall with hidden denominators.
Complete this card before a metric earns dashboard space
Decision for this week: remove one undefined rate from the dashboard and replace it with a completed metric card. If the underlying evidence is support contact, continue with the ticket evidence register.
Definitions worth pinning
- Stripe subscription analytics, documentation checked 2026-09-14. Definitions, configuration and preview access are specific to Stripe; this is not a universal accounting standard.
- How Google Analytics works, documentation checked 2026-09-14. Collection and processing do not establish that a customer completed their job.
- Google Analytics internal-traffic filters, documentation checked 2026-09-14. Testing and active exclusion have different consequences for data availability.