DAU dropped to zero after product release: debugging guide

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.

Not specified by the original author.

TL;DR

New cohorts reading zero WAU while older cohorts stay normal means the new onboarding flow stopped emitting, renamed, or re-keyed the activation events the WAU query depends on. Compare the event stream of a user onboarded yesterday against one onboarded last month and the difference is the bug.

why did weekly active users drop to zero after onboarding: fix the missing activation events

Use this when

• WAU is zero only for users onboarded after a flow change
• Older cohorts report normally
• The activation milestone events have new names, steps, or owners

Not for this skill when

• Onboarding was paused or signups were halted
• WAU dropped for all cohorts, pointing at the metric query itself

Steps

1. Pick one user from a zero-WAU cohort and dump their full raw event history. Verify: every event they actually generated is visible, whatever it is named
2. Do the same for a user from a healthy cohort and diff the two event sets. Verify: the missing, renamed, or re-keyed activation events are listed exactly
3. Check the WAU and activation query definitions against the new event names and id fields. Verify: the query clauses that no longer match are identified
4. Update the instrumentation or the query, then re-run WAU for the affected cohorts. Verify: new cohorts report non-zero WAU consistent with their raw activity
5. Add a contract test that fails the release if a required activation event stops arriving from the onboarding flow. Verify: the next flow change cannot silently zero activation again

Variant phrasings

new cohort WAU zero

A related phrasing for the same underlying problem.

activation events missing after onboarding change

A related phrasing for the same underlying problem.

onboarded users not counted as active

A related phrasing for the same underlying problem.

Compatibility: Compatibility: onboarding instrumentation with analytics WAU definitions (warehouse or Mixpanel/Amplitude cohorts), current versions.

Why it happens

Cohort-specific zeros are a fingerprint: the metric works, the users exist, so only the newest flow's contract with the metric broke. A two-user raw diff is faster than any dashboard exploration because it shows what the new flow actually emits versus what the query expects.

Edge cases / pitfalls

• A new flow may emit events under a fresh anonymous id that never stitches to the account. Check identity resolution, not just event names.
• Backfilling cohort WAU from raw events is valid only if the raw events were captured. If the client never sent them, mark the gap honestly.
• Some flows delay activation events to a batch job. Confirm the batch schedule before declaring events missing.

Provenance

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

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

Thread query: why did weekly active users drop to zero after onboarding: fix the missing activation events

TL;DR: New cohorts reading zero WAU while older cohorts stay normal means the new onboarding flow stopped emitting, renamed, or re-keyed the activation events the WAU query depends on. Compare the event stream of a user onboarded yesterday against one onboarded last month and the difference is the bug.

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.