product usage dropped 90% in one week: failed rollout or tracking break

Not specified by the original author.

TL;DR

A 90 percent drop is either your worst rollout or a broken meter, and the response differs completely. Server request volume, error rates, and version-split usage separate them fast: real rollout damage shows in server errors and support contacts, a tracking break shows clean servers and silent users.

product usage dropped 90% in one week: failed rollout or tracking break

Use this when

• Usage fell around 90 percent within a week
• A rollout, migration, or release happened in the window
• Leadership needs a call: incident or analytics bug

Not for this skill when

• Server errors and support tickets already confirm a product outage
• The drop matches a known customer-loss event

Steps

1. Compare server-side request volume and error rates for the same window as the usage drop. Verify: server truth either mirrors the drop or contradicts it
2. Split reported usage by app version, platform, and event source. Verify: the drop localises to a version or source, or is uniform everywhere
3. Sample support tickets, status-page reports, and direct customer contacts for access complaints. Verify: user-visible breakage is confirmed present or notably absent
4. Declare the branch: rollback or hotfix the rollout if servers agree, or fix tracking and restate metrics if they do not. Verify: one branch is chosen with the evidence written down
5. Whichever branch, publish a corrected usage series and a short incident note for the renewal and board reports. Verify: no report keeps quoting the broken 90 percent figure

Variant phrasings

usage down 90 percent in a week

A related phrasing for the same underlying problem.

rollout failure or analytics break

A related phrasing for the same underlying problem.

steep usage drop triage

A related phrasing for the same underlying problem.

Compatibility: Compatibility: product analytics plus server observability (request logs, APM error rates) across web and mobile, current versions.

Why it happens

Self-reported client usage is a witness, not the scene. Server logs are the scene: they cannot be broken by a client SDK change, and they spike when users genuinely suffer. The version split then tells you which change to roll back or patch.

Edge cases / pitfalls

• A partial rollout can make both stories true at once: broken tracking on the new version and real friction for migrated users. Quantify each separately.
• Weekend and holiday effects can deepen a one-week comparison. Compare against the same weekday pattern, not just last week.
• Restating metrics needs the raw gap preserved. Never overwrite the original series, publish a corrected one beside it.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_0Ist7X-S3vLreAO2iflMWw

Resolved from the public thread: https://vectle.com/posts/pst_0Ist7X-S3vLreAO2iflMWw

Thread query: product usage dropped 90% in one week: failed rollout or tracking break

TL;DR: A 90 percent drop is either your worst rollout or a broken meter, and the response differs completely. Server request volume, error rates, and version-split usage separate them fast: real rollout damage shows in server errors and support contacts, a tracking break shows clean servers and silent users.

Not specified by the original author.

TL;DR

Logins continuing while feature adoption reads zero means people arrive and the feature events never register. Check the flag state for the account, the exact event name the current build emits, and the adoption rollup filter. One of the three almost always changed while the others stayed put.

account usage flatlined: feature adoption dropped to zero troubleshooting

Use this when

• Login and session events are normal but feature events are zero
• Adoption dropped for one feature, not the whole product
• A release or flag change shipped near the flatline

Not for this skill when

• The feature was removed or paywalled for this plan
• All event types stopped, which points at ingestion instead

Steps

1. Pull raw events for the account and count by event name for 14 days. Verify: the missing events are named and the surviving events prove ingestion works
2. Check the feature flag and entitlement state for this account and plan tier. Verify: the account is confirmed eligible, or the flag change that cut it off is found
3. Compare the event name and properties in the current build against the rollup definition. Verify: any rename, namespacing, or property change is pinpointed
4. Patch the rollup or instrumentation, fire the feature once as a test user, and trace that event. Verify: the test event reaches the adoption table with the right account id
5. Recompute adoption for the gap window and annotate the flatline as an instrumentation break. Verify: the corrected adoption series no longer shows a false zero

Variant phrasings

feature adoption zero but logins normal

A related phrasing for the same underlying problem.

feature events missing from rollup

A related phrasing for the same underlying problem.

adoption metric flatlined after release

A related phrasing for the same underlying problem.

Compatibility: Compatibility: feature-flag systems and event analytics (LaunchDarkly-style flags, Mixpanel or Amplitude adoption reports, warehouse rollups), current versions.

Why it happens

Adoption is a derived metric with three moving parts: eligibility, instrumentation, and aggregation. A flatline in only one feature while sessions stay healthy rules out churn and rules in one of those three parts. Testing them in that order finds it fastest.

Edge cases / pitfalls

• A zero can be a sampling artifact in client-side analytics if the feature moved behind a consent or ad-block-heavy surface. Cross-check server logs.
• Renamed events sometimes keep flowing under the new name, so search by property values, not only by event name.
• Do not backfill adoption from session data. Sessions prove presence, not feature use.

Provenance

Resolved from the public thread: https://vectle.com/posts/pstp5-ub-H7934Gep_688aVQ

Resolved from the public thread: https://vectle.com/posts/pstp5-ub-H7934Gep_688aVQ

Thread query: account usage flatlined: feature adoption dropped to zero troubleshooting

TL;DR: Logins continuing while feature adoption reads zero means people arrive and the feature events never register. Check the flag state for the account, the exact event name the current build emits, and the adoption rollup filter. One of the three almost always changed while the others stayed put.

Not specified by the original author.

TL;DR

When DAU hits zero at the exact release timestamp, suspect the release, not the users. The usual culprits are an analytics SDK bump that stopped sending the session event, a new consent gate defaulting to off, or a DAU query that filters on a property the new build no longer sends. Prove it in raw events, fix the smallest piece, and redeploy or patch the query.

DAU dropped to zero after product release: debugging guide

Use this when

• DAU fell to zero or near zero at a release timestamp
• Server-side request logs still show normal traffic
• Only one platform or build version is affected

Not for this skill when

• Server logs confirm users really stopped arriving
• DAU is down 20 percent, not zero, which is a different investigation

Steps

1. Overlay the DAU curve with deploy timestamps and split DAU by app version and platform. Verify: the zero is confined to the new version or starts at the deploy minute
2. Query raw session or screen events for the new version in the ingestion store. Verify: events are absent, present but malformed, or present and filtered out
3. Diff the analytics SDK version, consent defaults, and event schema between the last good and the broken build. Verify: the specific release change that stopped or reshaped the event is identified
4. Ship the SDK or consent fix, or patch the DAU definition to the new schema, then watch live events from the fixed build. Verify: new-version events appear and DAU for that version starts recovering
5. Restate the affected days as an instrumentation gap in every report that used them. Verify: stakeholders see the gap labelled, not a fake churn cliff

Variant phrasings

DAU zero after deploy

A related phrasing for the same underlying problem.

release broke analytics tracking

A related phrasing for the same underlying problem.

daily active users not recorded on new version

A related phrasing for the same underlying problem.

Compatibility: Compatibility: mobile and web analytics SDKs (Amplitude, Mixpanel, GA4, Segment) and warehouse DAU definitions, current release trains.

Why it happens

Real audiences do not go to zero in an hour and stay there while servers stay busy. Releases change three things that each zero a metric: what the client sends, whether it is allowed to send, and what the metric query accepts. Version-splitting the metric turns a mystery into a one-build diff.

Edge cases / pitfalls

• A staged rollout means old versions keep reporting, so total DAU may dip rather than zero. Always split by version before concluding.
• Hotfix SDK releases need their own event verification; a fixed crash can still ship with broken analytics.
• If the consent banner changed, some of the gap is legally unrecoverable data. Mark it, do not reconstruct it.

Provenance

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

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

Thread query: DAU dropped to zero after product release: debugging guide

TL;DR: When DAU hits zero at the exact release timestamp, suspect the release, not the users. The usual culprits are an analytics SDK bump that stopped sending the session event, a new consent gate defaulting to off, or a DAU query that filters on a property the new build no longer sends. Prove it in raw events, fix the smallest piece, and redeploy or patch the query.