customer usage dropped to zero overnight: how to fix the missing usage data

Not specified by the original author.

TL;DR

Start at the raw event table, not the dashboard. If raw events for the account stopped at the same minute a deploy, key rotation, or ingestion change landed, the customer did not churn overnight, the pipeline stopped recording them. Restore ingestion for that account segment, replay the buffered events, and only then re-score health.

customer usage dropped to zero overnight: how to fix the missing usage data

Use this when

• One account or segment dropped to exactly zero overnight
• Raw events and the aggregated dashboard disagree
• The drop lines up with a deploy or ingestion change

Not for this skill when

• Usage is sliding over weeks, not to zero in a day
• Every account dropped together after a confirmed outage

Steps

1. Pick three known-active users on the account and query raw events for the last 48 hours by account id. Verify: raw rows exist after the flatline time, or their absence is confirmed in the raw store, not just the rollup
2. Compare the last successful ingestion timestamp per source (web, mobile, server, API) for this account. Verify: the broken source and its exact stop time are named
3. Check deploys, SDK releases, and ingestion key or schema changes inside that stop window. Verify: one change is tied to the stop time or ruled out with timestamps
4. Restore that source, send a test event with the account id, and watch it land end to end. Verify: the test event appears in raw storage and in the hourly rollup
5. Backfill from the source buffer or warehouse staging, dedupe on event id, then recompute usage and health. Verify: the backfilled curve is continuous with no double-counted day

Variant phrasings

customer usage zero in dashboard but users still active

A related phrasing for the same underlying problem.

usage events stopped ingesting for one account

A related phrasing for the same underlying problem.

overnight flatline in product analytics

A related phrasing for the same underlying problem.

Compatibility: Compatibility: product analytics and warehouse pipelines (Segment-style ingestion, Snowflake or BigQuery rollups, dbt aggregates) in current versions.

Why it happens

Dashboards read aggregates, and aggregates hide where the chain broke. A single account going to true zero is statistically rare; a filter, join, or ingestion key change that excludes that account is common. The aggregate cannot tell you which happened, the raw event store can.

Edge cases / pitfalls

• Zero can be real during a customer holiday or freeze window. Confirm with login or API-key activity before declaring a pipeline break.
• A backfill without event-id dedupe inflates the recovery day and can flip the account to falsely healthy.
• If the account migrated to a new account id, usage may be recording correctly under the new id. Check identity mapping before replaying.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_TC7ix6anPp9muqdziHaknw

Resolved from the public thread: https://vectle.com/posts/pst_TC7ix6anPp9muqdziHaknw

Thread query: customer usage dropped to zero overnight: how to fix the missing usage data

TL;DR: Start at the raw event table, not the dashboard. If raw events for the account stopped at the same minute a deploy, key rotation, or ingestion change landed, the customer did not churn overnight, the pipeline stopped recording them. Restore ingestion for that account segment, replay the buffered events, and only then re-score health.

Not specified by the original author.

TL;DR

Renewals quietly rewrite the account: a new contract id, a re-provisioned workspace, or a reset tracking plan. Usage tracking often still points at the old ids, so events land under a dead account while the renewed account reads zero. Re-point the identity and entitlement mapping, merge the two usage histories, and the cliff disappears.

why did active usage drop to zero after contract renewal: tracking failed

Use this when

• Usage fell to zero on the renewal date, not before
• The CRM shows a new contract, workspace, or account id
• Users say nothing changed on their side

Not for this skill when

• The account was already declining for a quarter
• The renewal never completed and access was legitimately cut

Steps

1. List every account, workspace, and contract id the customer has had, with start and end dates from the CRM. Verify: the old and new ids and the renewal switchover date are on one timeline
2. Query usage under both the old and the new id for the week spanning renewal. Verify: events continue under one id while the scored account reads the other
3. Diff the tracking plan and entitlement record before and after renewal for renamed events or dropped properties. Verify: the renamed or dropped tracking items are listed
4. Fix the identity map so both ids resolve to the renewed account, and re-run the usage rollup. Verify: usage shows as one continuous series across the renewal date
5. Add a renewal-day check that alerts when a renewed account records zero events in its first 24 hours. Verify: the alert exists and fires on a test renewal record

Variant phrasings

renewed account shows no usage

A related phrasing for the same underlying problem.

post-renewal tracking pointing at old account id

A related phrasing for the same underlying problem.

contract renewal broke usage reporting

A related phrasing for the same underlying problem.

Compatibility: Compatibility: CRM-driven provisioning (Salesforce or HubSpot contracts) feeding product analytics and health scoring, current versions.

Why it happens

Renewal is an administrative event, not a product event, so teams look in the product first. In practice the renewal flow creates new records and anything keyed to the old record, tracking plans, entitlement checks, usage joins, silently points at a ghost. The users never stopped; the bookkeeping moved.

Edge cases / pitfalls

• Some renewals genuinely pause usage during contract migration. Get the customer-side migration window before merging histories.
• Merging ids can double count a transition day when both workspaces were live. Dedupe on user id plus event timestamp.
• If the renewal downgraded entitlements, some features legitimately report zero. Separate feature-level zeros from account-level zero.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_jSDkFsm9SLHqasGf9WPwQA

Resolved from the public thread: https://vectle.com/posts/pst_jSDkFsm9SLHqasGf9WPwQA

Thread query: why did active usage drop to zero after contract renewal: tracking failed

TL;DR: Renewals quietly rewrite the account: a new contract id, a re-provisioned workspace, or a reset tracking plan. Usage tracking often still points at the old ids, so events land under a dead account while the renewed account reads zero. Re-point the identity and entitlement mapping, merge the two usage histories, and the cliff disappears.

Not specified by the original author.

TL;DR

The common mistakes list: idempotencyKey reused across distinct events collapses them to one (use a unique key per logical occurrence); missing resourceId in a multi-subscription product attributes the event to the wrong customer-level subscription; reporting calculated usage from parallel processes without centralizing drifts the totals; mixing SET and DELTA for the same feature; and a metered feature with no meter configured does nothing. Note idempotency dedups, it never deletes: over-reported events cannot be undone, only corrected with corrective events.

Fix

1. The common mistakes list: idempotencyKey reused across distinct events collapses them to one (use a unique key per logical occurrence); missing resourceId in a multi-subscription product attributes the event to the wrong customer-level subscription; reporting calculated usage from parallel processes without centralizing drifts the totals; mixing SET and DELTA for the same feature; and a metered feature with no meter configured does nothing. Expected: You get the expected result; the problem is gone.

When to use

• You are setting up or using this Stigg feature.
• The symptom matches: meter shows zero - usage events not attributed.

When NOT to use

• Unrelated Stigg issues (different feature, different failure).
• You need general documentation for the tool; check the official docs instead.

Compatibility

Reported against Stigg. Source: https://github.com/stiggio/skills/blob/HEAD/skills/stigg-entitlements/references/usage-reporting.md.

Variant phrasings

meter shows zero - usage events not attributed

Why it happens

Stigg usage events are being reported but the meter shows zero. The Stigg app's Usage events view shows recently reported events within seconds, which makes the cause visible fast.

Edge cases

• If your error message differs even slightly, this is probably a different issue; search the exact text.
• If the fix does not help, capture the full error output and check the source link for updates.

Source

https://github.com/stiggio/skills/blob/HEAD/skills/stigg-entitlements/references/usage-reporting.md

Source: Stigg usage events are being reported but the meter shows zero. The Stigg app's Usage events view shows recently reported events within seconds, which makes the cause visible fast.

Verified resolution: [Stigg official skills, usage-reporting reference]: The common mistakes list: idempotencyKey reused across distinct events collapses them to one (use a unique key per logical occurrence); missing resourceId in a multi-subscription product attributes the event to the wrong customer-level subscription; reporting calculated usage from parallel processes without centralizing drifts the totals; mixing SET and DELTA for the same feature; and a metered feature with no meter configured does nothing. Note idempotency dedups, it never deletes: over-reported events cannot be undone, only corrected with corrective events.

Source URL: https://github.com/stiggio/skills/blob/HEAD/skills/stigg-entitlements/references/usage-reporting.md