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

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

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

Your check-in agent keeps sending "we miss you" nudges to users who already activated because it never re-checks activation status before sending. The fix: query the current activation state at send time and skip anyone already active. Then fix the scheduling so the nudge sequence cancels itself the moment activation is recorded.

The error

User activated 2026-10-03; received nudge emails on 10-04, 10-05, 10-07
Agent log: "user inactive, sending nudge #3"

Steps

1. Confirm the stale reads. Pick an affected user and compare the agent's log timestamp against the activation timestamp. Expected output: the agent read "inactive" after the user was already active.
2. Add a send-time status check. Before each nudge, fetch the live activation state. Expected output: the check returns active and the send is skipped.
3. Cancel the sequence on activation. Wire the activation event to cancel any scheduled nudges for that user. Expected output: no nudges are even scheduled after activation.
4. Backfill the damage. Find all users who got post-activation nudges and suppress the rest of their sequence. Expected output: zero further nudges to activated users.
5. Watch one full cycle. Expected output: inactive users still get nudges; activated users get none.

When to use

• Activated users complain about nudge emails
• The agent's log shows "inactive" for users who are active
• Nudges continue on a fixed schedule regardless of user state

When not to use

• Nudges never send at all: the scheduler or template is broken
• Active users get the wrong email content: a segmentation problem
• You want to nudge active-but-disengaged users: that is a new campaign, not this bug

Tool compatibility

Any check-in or lifecycle email agent: marketing automation platforms, custom schedulers, and agent frameworks with timed actions. The send-time check pattern works with any activation event source.

Variant phrasings

nudge emails after activation

Re-check status at send time.

onboarding emails keep coming after signup complete

Cancel the sequence on the activation event.

check-in agent spamming active users

Stale state; verify before each send.

user activated but still getting reminders

The schedule never learned about the activation.

Why it happens

The agent snapshots the user list when the sequence starts ("these 40 users are inactive") and then works through the snapshot for days. Activation happens in a different system, and nothing updates the snapshot. Each nudge send reads the stale list, concludes the user is still inactive, and fires. It is the classic read-once-act-many bug. The fix is to make state a per-send question ("is this user active right now?") instead of a per-sequence assumption, and to let the activation event kill the schedule outright.

Edge cases

• Activation is defined by multiple events: pick one canonical "activated" flag or the check stays ambiguous.
• The activation event arrives late: keep the send-time check as the backstop even with event-driven cancellation.
• Users who activate then churn: do not restart the onboarding nudges; that needs a separate win-back flow.
• Timezone-scheduled sends: a user activating an hour before a queued send still gets that one email. Accept it or shorten the queue window.

Provenance

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

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

Thread query: check-in agent looped nudge emails after user already activated

TL;DR: Your check-in agent keeps sending "we miss you" nudges to users who already activated because it never re-checks activation status before sending. The fix: query the current activation state at send time and skip anyone already active. Then fix the scheduling so the nudge sequence cancels itself the moment activation is recorded.