## TL;DR
A decline before renewal gets read as churn risk, but a slow tracking rot looks identical: one surface stops sending, one integration ages out, one event gets renamed. Audit coverage per surface and per event before trusting the trend, fix what is broken, and give the renewal team a corrected baseline to negotiate from.

```text
why is customer usage declining: find the broken tracking before renewal
```

## Use this when
- Usage declines steadily while support and login signals stay flat
- The decline is concentrated in one surface, event, or segment
- Renewal is close and the number will be quoted to the customer

## Not for this skill when
- The customer confirmed a shutdown, layoff, or migration away
- Usage declines equally across every surface and signal

## Steps
1. Break the decline down by surface, event name, platform, and account segment. Verify: the decline localises to specific surfaces or events instead of the whole account
2. For each localised drop, check the last instrumentation, integration, or schema change on that surface. Verify: a change matching each drop is found or the drop is cleared as real
3. Sample five active users and trace one full session in raw events against what the product logs server-side. Verify: missing client events are confirmed against server truth
4. Repair the broken tracking and note the exact gap window per surface. Verify: fixed surfaces resume sending and the gap windows are documented
5. Publish a corrected usage baseline for the renewal conversation, with gap windows annotated. Verify: the renewal team quotes the corrected number and can explain every annotation

## Variant phrasings
### usage declining but tracking suspect
A related phrasing for the same underlying problem.
### pre-renewal usage audit
A related phrasing for the same underlying problem.
### declining metrics caused by broken events
A related phrasing for the same underlying problem.

Compatibility: Compatibility: multi-surface product analytics plus CRM renewal workflows (warehouse event tables, Segment or RudderStack routing), current versions.

## Why it happens
Churn declines are usually broad; instrumentation declines are narrow and step-shaped per surface. Decomposing the trend is the whole diagnostic: if the drop lives in one event family, it is engineering, and if it lives everywhere including server-side signals, it is the customer.

## Edge cases / pitfalls
- Never present a corrected baseline without the raw evidence. Customers dispute adjusted numbers, they accept shown event logs.
- Some decline will survive the audit as real. Report both numbers; hiding the real part destroys trust in the fix.
- Check timezone and week-boundary changes in reporting before blaming instrumentation for a slow drift.

## Provenance

Resolved from the public thread: https://vectle.com/posts/pst_qkjfsD7OsvSaFe-zMZb81Q