Bonds Analytics Catalog

Comprehensive reference for all Mixpanel tracking in the Bonds app. Module: src/utils/analytics.js.

For product: This document lists every event, property, user attribute, and funnel tracked in the app. Use the table of contents to navigate.

For developers: When adding or changing events, update this document in the same PR. See the Developer Checklist at the bottom.

Table of Contents

1. Conventions
2. Identity & Properties
3. Screens
4. Domain Events
5. Element Clicked Reference
6. Funnels
7. Recommended Mixpanel Reports
8. Developer Checklist

1. Conventions

Measuring: always filter to US/CA

Any real-user analysis (funnels, retention, drop-off claims) MUST be filtered to mp_country_code = US or CA. The team runs heavy QA testing against production, concentrated in India/Israel, which pollutes global numbers badly enough to invert conclusions (e.g. a "~40% forced-logout within 1 hour" cluster that was entirely India QA traffic). Mixpanel's single-value string filters can't express "in [US, CA]" — either run US and CA separately, or break down by mp_country_code and read the US + CA rows. Production project id: 3256863. No tester-exclusion cohort exists yet; this filter is the stand-in.

Naming Rules

When to Use Which Event Type

Property Value Enums

2. Identity & Properties

2a. Identity Lifecycle

┌─────────────────┐     identifyUser()      ┌──────────────────┐
│    Anonymous     │ ─────────────────────→  │   Authenticated  │
│  (random ID)     │                         │  (Bubble user ID) │
│  user_type:      │                         │  user_type:       │
│   'anonymous'    │     resetIdentity()     │   'authenticated' │
│                  │ ←─────────────────────  │                   │
└─────────────────┘                          └──────────────────┘

2b. Super Properties

Auto-attached to every event. Set by initAnalytics(), updated by identifyUser().

2c. People Properties (User Profile)

Stored on the Mixpanel user profile. Visible in the People section.

Cohort tag: the A/B/C payments cohort's source of truth is the Bubble User field payment_variant (Statsig only seeds it once — see docs/statsig-experiments.md). It's written to the Mixpanel user profile as the payment_variant People property (the effective value incl. admin overrides, set by <PaymentVariantSeeder>) — use this for all cohort filtering and breakdowns. It's a People (not super) property because the cohort is sticky and server-owned: a profile property survives reset(), is queryable on the user level, and is still segmentable in event reports, with no need for an at-event snapshot. The raw Statsig bucket is not mirrored to Mixpanel as experiment_payments (kept to one property to avoid confusion); Statsig retains the exposure for experiment analysis on its side.

3. Screens

All values used with Screen Viewed. Fired via screen(name) helper which calls track('Screen Viewed', { screen: name }).

4. Domain Events

App Lifecycle

App Opened

Fires once on app launch after analytics initialization.

Source: App.jsx

App Backgrounded

Fires when the app moves to the background (Natively lifecycle hook).

Source: App.jsx

App Foregrounded

Fires when the app returns to the foreground (Natively lifecycle hook).

Source: App.jsx

Logged Out

Fires when user logs out. Identity is reset after this event.

Source: App.jsx

Session Force Logout

Fires when Bubble force-logs the user out via setLoginState(false) while they were in an authenticated phase (no React-initiated logout pending). Most likely cause is the WebView losing its session cookie (_u2main) across a process restart, which triggers Bubble's "User is logged out" event server-side. Tracked into Mixpanel so we can monitor frequency and surface in retention/funnels alongside other auth events.

Source: App.jsx (in setLoginState(false) handler when source === 'bubble')

Since 2026-07 (conservative session validation): also fires on the cold-start path, but ONLY after /me (get_user) returned a confirmed-anonymous answer twice — source: "cold_start_me_anonymous", reason: "me_anonymous_confirmed". The old snapshot-mismatch trigger (source: "cold_start_uid_mismatch") was removed; watch this event's volume as the "did we regress auth" tripwire (Sentry alert rule).

Session Validation Outcome

Fires once per cold-start session validation (authenticated session flags present). Replaces the old silent snapshot-mismatch logic with an auditable decision. Spec: docs/superpowers/specs/2026-06-29-conservative-session-validation-design.md.

env_switch_pending_hold (2026-07-07): a foreign-version setLoginState(true) arrived while the staging env-switch prompt was awaiting the user's choice — the event is held instead of bouncing (the bounce used to race the prompt); the prompt's own resolution follows as Element Clicked { switch_here | go_home }.

cross_env = landing on any non-HOME version (universal HOME rule — link or bare URL, any tier) → auto-return home, no logout, no wipe. adopt = unanchored version where Bubble confirms a session (migration heal). fresh = quiet welcome, nothing lost. Production should see ~zero; Sentry alert rule on sustained volume (a mis-built push/link reached real users).

Source: App.jsx (checkSession decision flow; autoReturnHome)

Env Switch Prompt Shown

Staging-only QA affordance: shown when a device lands on a foreign staging version whose home is also staging, in place of the silent foreign-landing bounce (design 2026-07-06). Production-home users never see it. Resolves into exactly one Element Clicked { element: 'switch_here' | 'go_home' }; go_home additionally emits Session Validation Outcome { reason: 'cross_env', source: 'env_switch_prompt' }.

Deep Link Rejected (Wrong Environment)

Fires when a deeplink's tier differs from the user's active environment — the route is dropped (never honored) and the generic "This link couldn't be opened" notice is shown.

Source: index.jsx (cold-start parse + handleDeepLink guard)

Deep Link Opened

Fires when a deep link is processed. Attribution params (if present in the URL) are spread into the event properties.

Source: MainTabs.jsx

Attribution Captured

Fires when a URL with attribution params is opened (cold start or warm start), regardless of whether a deep link route is present. Independent of Deep Link Opened.

Source: analytics.js via captureAttribution()

Profile Pull (Phase 2 dual-run — shadow telemetry, removed with the element kill)

Session Data Divergence

Pre-APPLY divergence between the /me pull and current state — rollout health metric while the reactive element coexists; after element deletion it measures boot-cache staleness. Expected benign noise: transient coins divergence when a /me lands between an optimistic coin update and the reactive echo — judge by rate and persistence, not single events. Any uid divergence is a P1 signal — investigate immediately.

boot_late = the boot /me resolved after Bubble's page event had already moved the app to main; the session decision is discarded but the authenticated data still applies (pre-fix, this path silently dropped the snapshot — the frozen-balance bug from QA 13-07-26). fun_zone_settled is RETIRED in BNS-1088 slice 2 — the fun-zone creation now charges inside one awaited HTTP workflow and returns the post-deduct balance in the response, so there is nothing left to reconcile: no /me pull, no setUserData push, and no race between them (#427 added the pull, #430 removed it from the delivered path; the migration removed the last of it). Check the Mixpanel boards before dropping the value from any saved report.

Source: App.jsx (session validation incl. late-boot apply, foreground refresh, post-auth checkpoint). The former ActivityView.jsx fun-zone-create-timeout refresh (FunZoneContext.refreshBalance) was removed with fun_zone_settled in BNS-1088 slice 2 — the awaited workflow response is now the only balance writer.

Authentication

Sign In Started

Fires when user initiates sign-in (OAuth or email).

Source: SignInScreen.jsx

Sign In Completed

Fires on first successful identity merge (anonymous → authenticated). Reads bonds_auth_method from localStorage. Since BNS-1136 the Sign-In screen tags SSO attempts too, so method reports "google" / "apple" / "email"; "oauth" remains only as the fallback when the tag is missing (e.g. the Android OAuth redirect wiped localStorage). Boards filtering on method = "oauth" should switch to the concrete provider values.

Source: UserContext.jsx

Sign In Failed

Fires when sign-in fails (wrong password, Bubble error).

Source: App.jsx (via setSignInError)

Sign In Blocked

Fires when sign-in detects a non-existing account (UID comparison or Bubble search).

Source: App.jsx (via onSigninComplete)

Onboarding

Onboarding Step Completed

Fires after each onboarding question is answered.

Source: OnboardingFlow.jsx

Onboarding Completed

Fires when user finishes all onboarding steps.

Source: OnboardingFlow.jsx

Onboarding Abandoned

Fires when user exits onboarding via back button on step 0.

Source: App.jsx

Onboarding Resumed

Fires when onboarding session is resumed, either automatically on app reload (source: 'auto') or when user chooses to continue via the resume dialog (source: 'dialog').

Source: App.jsx

Onboarding Intro Viewed

Fires when the one-time intro video screen is mounted.

Source: OnboardingIntro.jsx

Onboarding Intro Completed

Fires when user taps the CTA after the intro video has finished playing.

Source: OnboardingIntro.jsx

Onboarding Intro Skipped

Fires when user taps the CTA before the intro video finishes (skips remaining video).

Source: OnboardingIntro.jsx

Onboarding Intro Replayed

Fires when user taps replay to watch the intro video again.

Source: OnboardingIntro.jsx

Onboarding Intro Backed Out

Fires when user navigates back from the intro screen to welcome.

Source: OnboardingIntro.jsx

Two Last Questions Shown

Fires when the "Two last questions" popup appears just before the first open question (Groups A & C only — gated by useOnboardingCoinsHidden()). PRD UI Outputs #2. The CTA emits Element Clicked { screen: 'onboarding', element: 'two_last_questions_continue' }.

Source: OnboardingFlow.jsx

Onboarding Insight Started

Fires when insight generation begins after all questions answered.

Source: OnboardingInsight.jsx

Onboarding Insight Generated

Fires when the generate_onboarding_insight HTTP call returns a usable insight.

Source: OnboardingInsight.jsx

Onboarding Insight Generation Failed

Fires when generation fails: a transport error, the workflow's own quota_exceeded / generation_failed status, or an empty body. The user sees the retry dialog. Replaces the old Onboarding Insight Timed Out (BNS-1088 s3).

reason enum: http_5xx, http_4xx, timeout, network (transport, via failureReason), quota_exceeded, generation_failed (workflow status), empty_content (ok response, no text).

Source: OnboardingInsight.jsx

Onboarding Insight Manual Retry

Fires when the user taps "Try again" on the failure dialog.

Source: OnboardingInsight.jsx

Onboarding Insight Prewatch Shown

Fires when the before-watching gate appears ("This insight usually uses 3 coins, but this one's on us"). Groups A & C only — the gate exists to frame the coin reward, so Group B (no coin economy) has no gate and auto-plays the insight directly, never firing this event. PRD UI Outputs #4.

Source: OnboardingInsight.jsx

Onboarding Insight Watch Tapped

Fires when the user taps "Watch" on the before-watching gate, starting insight playback. Groups A & C only (Group B has no gate — see Onboarding Insight Prewatch Shown).

Source: OnboardingInsight.jsx

Onboarding Insight Playback Completed

Fires when TTS playback finishes and user taps Continue.

Source: OnboardingInsight.jsx

Onboarding Insight Playback Skipped

Fires when user taps Continue before TTS playback finishes.

Source: OnboardingInsight.jsx

Onboarding Insight CTA Tapped

Fires when user taps "Create Your Account" after insight playback.

Source: OnboardingInsight.jsx

Onboarding Insight Timed Out — RETIRED (BNS-1088 slice 3)

Removed when onboarding insight moved to the awaited HTTP call. The old 90s JS2B timeout no longer exists; failures now fire Onboarding Insight Generation Failed (with a reason, including timeout). Kept here as a tombstone — check Mixpanel boards referencing it before final removal.

Onboarding Data Connected

Fires after signup when the onboarding data was successfully committed to Bubble for the new user (the connect_anon_data_to_user HTTP workflow returned 200). Success-only since 2026-07 — previously this also fired on the (since removed) JS2B fallback path, where delivery wasn't confirmed.

Source: App.jsx

Onboarding Data Connect Failed

Compensating negative event: fires when the post-signup connect_anon_data_to_user HTTP call fails after retries (or the surrounding connect block throws). The user is NOT transitioned to the main app; onboarding data stays in storage for recovery. Together with Onboarding Data Connected this resolves the post-signup funnel into connected + failed.

Source: App.jsx

Onboarding Step Back

Fires when user navigates backward during onboarding.

Source: OnboardingFlow.jsx

Onboarding Mic Permission Denied

Fires when microphone permission is denied during onboarding open question.

Source: OpenQuestion.jsx

Onboarding Mic Unavailable

Fires when microphone/speech recognition is unavailable for a non-permission reason.

Source: OpenQuestion.jsx

Onboarding Speech API Unavailable

Fires when SpeechRecognition API doesn't exist on the device and dialog auto-switches to text mode.

Source: InsightOtherDialog.jsx

Dictation Stopped On Edit

Fires when the user manually edits the textarea (typing/deleting) while dictation is live, which ends the recognition session (BNS-1057 — an edit is authoritative, so the session terminates rather than reconciling with in-flight speech results). Signals how often users correct mid-dictation and re-tap the mic. Emitted from the shared useSpeechRecognition hook, so it covers every voice surface (Act "other outcome", journey "what's on your mind", insight "other").

Source: useSpeechRecognition.js

Signup

Sign Up Started

Fires when user initiates sign-up (OAuth or email).

Source: SignUpScreen.jsx

Sign Up Completed

Fires on successful signup. Detects email vs OAuth via bonds_auth_method localStorage flag.

Source: App.jsx

Sign Up Failed

Fires when sign-up fails (Bubble error).

Source: App.jsx (via setSignUpError)

Sign Up Blocked

Fires when sign-up detects an existing account (UID comparison or Bubble search).

Source: App.jsx (via onSignupComplete)

Email Authentication

Email OTP Sent

Fires when an OTP code is successfully sent to the user's email.

Source: SignUpScreen.jsx, SignInScreen.jsx

Email OTP Verified

Fires when user successfully verifies the OTP code.

Source: SignUpScreen.jsx, SignInScreen.jsx

Email OTP Failed

Fires when OTP verification fails (wrong or expired code).

Source: SignUpScreen.jsx, SignInScreen.jsx

Email OTP Resent

Fires when user taps resend code.

Source: SignUpScreen.jsx, SignInScreen.jsx

Password Reset Completed

Fires after a successful password reset + auto sign-in.

Source: SignInScreen.jsx

Sharing

Share Created

Fires when user creates a shareable link.

Source: InsightPlayback.jsx, SimulatorResults.jsx, ActivityView.jsx

Share Viewed

Fires when someone views a shared link.

Source: ShareViewer.jsx

App Shared

Fires when a user shares the app itself (not a piece of content) — the "Share {app}" CTA opens the OS share sheet with the brand's shareLink (brand.urls.shareLink, default https://<domain>/?source=share_app; white-label tenants override via setAppConfig). When the friend opens the link, the cold-start attribution capture fires Attribution Captured with source: "share_app" — that's how web-side joins from a share are tracked. For store-install attribution, point shareLink at a per-tenant Branch quick link (Branch is already integrated; parseDeepLink unwraps $deeplink_path) whose web fallback is this URL — Branch then reports installs by link, and the deferred deep link restores source=share_app on first open. Fires on initiation: the native share sheet (window.natively.shareText) is fire-and-forget, so share completion isn't observable. Co-fires the Appsflyer af_share event (af_description: "app").

Source: MainTabs.jsx (Profile → Support), ChapterCelebration.jsx — both via shareApp() in utils/deepLink.js

Share Reward Granted

Fires when the user is granted coins (EARN.share, currently 10) for sharing the app, capped to once per day. Granted on share tap — when a share sheet opens (grantShareRewardOncePerDay() in utils/shareReward.js), the surface calls the gift_coins Bubble action and shows the CoinGrant confirmation dialog (rendered behind the native sheet, revealed on dismiss). (Granted on tap, not on app-return: the native share sheet is a modal that often doesn't background the app, and Natively's shareText has no completion callback — a foreground-return gate missed ~80% of shares in QA. The daily cap, persisted via bonds_share_reward_date, bounds the "grants even on cancel" trade-off to once/day.)

Cohort gating: only fires for coin-eligible users — non-premium Groups A & C. Group B (paywall-first) and premium subscribers never see the coin economy, so they get a plain "Share {app}" CTA with no reward and this event never fires for them (App Shared still fires for everyone). Eligibility = useCoinRewardActive() (!isSubscribed && variant !== 'B').

Abuse note (MVP): this does not verify the friend installed — and since it grants on tap, cancelling the share sheet still grants. Accepted for MVP; watched via the ratio of this event to App Shared. Closing the loop on the invitee joining is the deferred proper fix.

Source: ShareAppRow.jsx (Profile) and ChapterCelebration.jsx via grantShareRewardOncePerDay() in utils/shareReward.js

Account

Account Deleted

Fires when user confirms account deletion.

Source: MainTabs.jsx (AccountInfoPage)

Onboarding Question Skipped

Fires when user skips an open-ended onboarding question.

Source: OpenQuestion.jsx

Journey

Chapter numbering convention. Two property names coexist for historical reasons, both 1-based:

• chapter — used by step-level events (Chapter Started, Chapter Completed, Journey Step Started/Completed/Abandoned, Journey Video Watched, Journey Practice Started/Completed). Value is the chapter's index from Bubble (the temp_index field).
• chapter_number — used by chapter-level / UI events (Chapter Confirmation *, Chapter Start Tapped, Chapter Step Start Tapped, Chapter Paused State Shown, Chapter Menu Opened, Chapter Menu Chapter Selected).

They agree numerically. When building a funnel across both groups, Mixpanel's "formula" column can alias one to the other.

dynamic segmentation. Every chapter-scoped event carries a boolean dynamic property (Phase 2 dynamic chapters vs predefined). Use it to split funnels and retention by chapter kind. Predefined chapters report dynamic: false; LLM-generated 3-node chapters report dynamic: true. For Simulator Session * events the property is present only when mode === 'journey'.

Chapter Started

Fires when the user pays the chapter cost (10 coins per the Coin Economy price card) via the coin gate and a new chapter begins. Not tied to a specific step — mirrors Chapter Completed.

Source: JourneyPath.jsx

Chapter Start Failed

Fires when the chapter_started HTTP workflow fails after all central retries and the optimistic start is reverted (BNS-1112). Chapter Started fires optimistically before the HTTP call, and the next Start tap after a revert fires it again — subtract this event to de-duplicate the start funnel. Rare by design (transient failures are retried with backoff).

Source: JourneyPath.jsx

Journey Step Started

Fires when a journey step begins (learn, practice, insight, or act).

Source: ChapterFlow.jsx

Journey Step Completed

Fires when a journey step finishes successfully.

Source: ChapterFlow.jsx

Journey Step Abandoned

Fires when user exits a journey step without completing it.

Source: ChapterFlow.jsx

Journey Video Watched

Fires when the learn video finishes playing.

Source: LearnStep.jsx

Journey Practice Started

Fires when user starts a practice simulator session from the journey.

Source: PracticeStep.jsx

Journey Practice Completed

Fires when practice simulator session ends with a score.

Source: PracticeStep.jsx

Chapter Completed

Fires when all steps in a chapter are done.

Source: ChapterFlow.jsx

Chapter Start Tapped

Fires when the user taps the external "START CHAPTER · N COINS" button on the journey map. This button replaces the in-bubble START for the first step of a chapter (PRD Phase 1, page 2).

Source: JourneyScreen.jsx

Chapter Step Start Tapped

Fires when the user taps the in-bubble START button on a non-first step (Practice/Insight/Act) on the journey map.

Source: JourneyScreen.jsx

Chapter Paused State Shown

Fires when the paused view is rendered the day after a chapter is completed (PRD Phase 1, page 4). Deduped by completed → next pair so a single paused session fires the event once.

Source: JourneyScreen.jsx

First Step Spotlight Shown

BNS-1077 orientation beat. Fires when the first-step spotlight (dim map + glowing cutout around the chapter's first step circle + explainer bubble) appears — beat 1 of the standalone Ch1 confirmation overlay, shown once after the post-FTUE dialog chain.

The user's tap on Next fires Element Clicked { screen: "first_step_spotlight", element_type: "button", element: "next", dynamic }.

Source: MainTabs.jsx

First Step Spotlight Skipped

Compensating event: the spotlight auto-skipped straight to the Start-Chapter sheet because the target circle couldn't be measured. Spotlight Shown funnels resolve into Element Clicked (next) + this event.

Source: MainTabs.jsx

Chapter Confirmation Shown

Fires when a predefined confirmation card is shown. Two sources — when building the Confirmation → Start → Complete funnel, union screen ∈ { ch1_predefined_confirmation, chapter_predefined_confirmation }:

• Ch1 — beat 2 of the standalone post-FTUE overlay (after the first-step spotlight) with screen: "ch1_predefined_confirmation", via: "standalone_overlay". History: the event originally fired from the last FTUE walkthrough slide (step / is_replay props); it went silent (~2026-05-08) when the card moved to the standalone overlay, and was revived with the BNS-1077 wiring — treat the gap accordingly in funnels.
• Ch2 / Ch3 — standalone bottom sheet shown at session start if the active chapter is an unstarted Ch2 or Ch3 and the user hasn't yet responded (PRD Phase 1, page 8 — Figma 1590:1791). Evaluated once per session; not re-triggered on chapter scroll. Uses screen: "chapter_predefined_confirmation".

Source: MainTabs.jsx (Ch1), JourneyPath.jsx (Ch2 / Ch3).

Chapter Confirmation Accepted

Fires when the user taps "Start Chapter" on the predefined confirmation card (Ch1 FTUE or Ch2/Ch3 standalone sheet).

Source: MainTabs.jsx (Ch1 standalone overlay), JourneyPath.jsx (Ch2 / Ch3). The DrLeoWalkthrough.jsx last-slide path is unreachable in production.

Chapter Confirmation Dismissed

Fires when the user taps "No thanks, later" on the predefined confirmation card.

Source: MainTabs.jsx (Ch1 standalone overlay), JourneyPath.jsx (Ch2 / Ch3). The DrLeoWalkthrough.jsx last-slide path is unreachable in production.

FTUE First Slide Shown

Fires when the FTUE first slide ("Generating your chapter…") is shown (PRD Phase 1, page 5).

Source: DrLeoWalkthrough.jsx

FTUE Skipped

Fires when the user taps Skip on any FTUE step. Per PRD §6, Skip now jumps to the last FTUE step instead of closing the walkthrough.

Source: DrLeoWalkthrough.jsx

Chapter Menu Opened

Fires on the OPEN transition of the chapter-list dropdown (chevron tap when the menu was closed). Does not fire on close — use the companion Element Clicked { element: 'chapter_menu_chevron' } event for bi-directional tap counts.

Source: JourneyScreen.jsx

Chapter Menu Chapter Selected

Fires when the user picks a chapter from the chapter-list dropdown. Funnels dropdown engagement → scroll navigation.

Source: JourneyPath.jsx

Insight

Insight Flow Started

Fires when an insight generation flow begins.

Source: InsightFlow.jsx · InsightStep.jsx

Insight Question Answered

Fires per insight question response.

Source: InsightFlow.jsx · InsightStep.jsx

Insight Generated

Fires when insight generation succeeds. For type: 'learn' it fires when generation is triggered (legacy JS2B path). For type: 'journey' (BNS-1119, HTTP path) it fires when the synchronous generate_journey_insight call returns the insight, with the round-trip duration.

Source: InsightFlow.jsx (learn) · InsightStep.jsx (journey)

Insight Generation Failed

Fires when the journey insight HTTP generation fails after its transport retry (BNS-1119 — replaces Insight Generation Timed Out for the journey surface). The user sees the Retry UI.

Source: InsightStep.jsx

Insight Generation Manual Retry

Fires when the user taps Retry on the journey insight failure screen.

Source: InsightStep.jsx

Insight Replay Loaded

Fires when opening a completed chapter's insight (replay) and the get_journey_insight read returns the stored insight.

Source: InsightStep.jsx

Insight Replay Load Failed

Fires when opening a completed chapter's insight (replay) and the get_journey_insight read fails or finds no stored insight.

Source: InsightStep.jsx

Insight Generation Timed Out

Fires when insight generation exceeds the timeout. Journey surface removed in BNS-1119 (replaced by Insight Generation Failed); Activity surface removed in BNS-1088 slice 2 (replaced by Activity Create Failed — the 90s poll timer it fired from is deleted). From that release this event only fires for the Tab/Learn surfaces.

Source: InsightFlow.jsx (learn/activity)

Insight Playback Completed

Fires when TTS playback finishes and user taps Continue.

Source: InsightFlow.jsx · InsightStep.jsx

Insight Playback Skipped

Fires when user taps Continue before TTS playback finishes.

Source: InsightFlow.jsx · InsightStep.jsx

Insight Flow Closed

Fires when user exits the insight flow without completing playback.

Source: InsightFlow.jsx

Simulator

Element Clicked — simulator / toggle / input_mode / mode (voice/text) / SimulatorSection. BNS-1071: the voice/text landing toggle persists the user's choice as their default next session (one shared preference across Ask, Practice and the Simulator). Fired only on an explicit toggle — never on the forced voice→text fallback, a "Try in simulator" seed, or a re-tap of the already-selected pill.

Mid-session breadcrumbs & drop position (BNS-1142). The session-boundary events say THAT a user dropped, not WHERE — and a user who backgrounds/kills the app emits nothing at all, so drop position is recovered from the last breadcrumb seen before the session went silent (Simulator Clarification Asked/Submitted, Simulator Turn Completed). All simulator events carry seconds_since_start (whole seconds since the session's Simulator Session Started). Recovery/exit events additionally carry the shared position props:

• phase — "clarification" (dynamic/freeform Stage 1 Q&A) / "intro" (predefined-chapter intro card) / "conversation" (Stage 2 incl. the connecting transition) / "eval" (Stage 3) / null (before the first stage signal). Seeded (Try-in-simulator) sessions briefly report "clarification" during the pre-connect window even though they skip Stage 1 — accepted imprecision.
• clarifying_questions / clarifying_answers — Dr Leo questions delivered / user answers submitted this session (0 for predefined chapters). Reset when a Stage-1 restart (disconnect recovery, switch-to-text, mic granted) tears down the coach session and re-asks from question 1.
• turn_number — last completed Stage 2 conversation turn (0 if none; partner turns are odd 1/3, user turns even 2/4). Resets when an auto-restart re-enters Stage 2 with a fresh conversation. Bookkeeping lives in src/utils/simulatorAnalytics.js.

Simulator Session Started

Fires when a simulator session begins (freeform or journey practice).

Source: SimulatorSection.jsx

Simulator Clarification Asked

Fires each time Dr Leo finishes delivering a clarifying question in Stage 1 (dynamic chapters and freeform/Tab sessions only — predefined chapters have no clarification phase). The count includes Leo's opening utterance, so question_number reads as "coach turn N". This is the key drop-localization breadcrumb for the dynamic-chapter mid-session churn analysis: Started with no Clarification Asked = died before Leo ever spoke (setup/mic/connection); last event = Asked {n} with no answer = quit while question n was on screen.

Source: SimulatorSession.jsx (bookkeeping in simulatorAnalytics.js)

Simulator Clarification Submitted

Fires when the user's answer to a clarifying question is finalized (voice transcription final or text send). question_number is the answer's own counter (answer N), pairing with Simulator Clarification Asked for engagement depth.

Same properties as Simulator Clarification Asked.

Source: SimulatorSession.jsx

Simulator Turn Completed

Fires each time a Stage 2 conversation turn finishes (partner utterance finalized / user reply transcribed or sent). Partner turns are odd (1, 3), user turns even (2, 4) — partner speaks first, two exchanges per session.

Source: SimulatorSession.jsx

Simulator Session Completed

Fires when AI evaluation is received and results are shown.

Source: SimulatorSection.jsx

Simulator Session Closed

Fires when user manually ends a session (via close dialog). Only covers in-app quits — a user who backgrounds/kills the app emits nothing; recover those drops from the last breadcrumb (see section note).

Source: SimulatorSection.jsx

Simulator Session Retried

Fires when user retries the session from the results screen.

Source: SimulatorSection.jsx

Simulator Session Error

Fires on unrecoverable session error. For the JSON-extraction boundaries (Stage 1, Stage 3), this only fires after parse retries are exhausted — see Simulator Issue Retry / Simulator Eval Retry below for the per-attempt signal.

Source: SimulatorSection.jsx

Simulator Mic Permission Denied

Fires when the mic-permission dialog (MicPermissionDialogs) is shown — either a live PERMISSION_DENIED from the realtime session or the predefined-chapter Start-practice preflight detecting an already-denied mic. Negative-signal counterpart to Simulator Mic Permission Granted; separates mic-friction drops from clarifying-question churn.

Source: SimulatorSession.jsx

Simulator Mic Permission Granted

Fires when the user returns from Settings and the visibility probe confirms mic access; the session silently restarts at the stage it was in. A Stage-1 restart tears down the coach session and re-asks from question 1 (clarification counters reset — see section note); a Stage-2 restart re-enters with a fresh conversation (turn numbering resets).

Source: SimulatorSection.jsx

Simulator Switch To Text

Fires when the user picks the text fallback from the mic-trouble dialogs; the session restarts stage-aware on the WebSocket transport (same Stage-1/Stage-2 reset semantics as Simulator Mic Permission Granted above).

Source: SimulatorSection.jsx

Simulator Eval Retry

Fires per attempt when the Stage 3 evaluation JSON fails to parse and we re-fire the silent response.create on the same session. After today's tool-calling change this should be near-zero in production — the model is structurally forced into schema-valid JSON. Kept as belt-and-suspenders.

Source: SimulatorSection.jsx

Simulator Eval Retry Recovered

Fires once when a Stage 3 eval succeeds after at least one retry. Lets analytics distinguish first-try clean sessions from "drift caught and recovered" sessions, both of which otherwise look identical at Simulator Session Completed.

Source: SimulatorSection.jsx

Simulator Issue Retry

Stage 1 (issue-extraction) counterpart to Simulator Eval Retry. Same shape, same near-zero post-tool-call expectation.

Source: SimulatorSection.jsx

Simulator Issue Retry Recovered

Stage 1 counterpart to Simulator Eval Retry Recovered.

Source: SimulatorSection.jsx

Coins Deducted

Fires when coins are spent — to unlock stage 2 of a freeform simulator session, or on the first paid turn of an Ask Dr Leo session.

via (journey_map | step_end | dr_leo_tab | deep_link) is sent on the context: 'ask' deduct so paywall attribution separates the ask entry points; the context: 'simulator' deduct does not carry it.

Source: SimulatorSection.jsx (simulator) · AskSession.jsx (ask)

Coins Gifted

Fires when the user receives a one-time coin gift (e.g. from the "Not Enough Coins" dialog).

Source: NotEnoughCoinsDialog.jsx

Activities

Activity Create Started

Fires when user initiates creating a new activity.

Source: ActivityView.jsx

Activity Created

Fires when generate_activity_insight returns an activity — the moment the user is charged. Pairs with Activity Create Started to give the fun-zone creation funnel: every Started resolves into exactly one Activity Created or one Activity Create Failed (unless the user leaves mid-flight, which fires neither — the client bails before the billable call). Added in BNS-1088 slice 2.

Source: ActivityView.jsx

Activity Create Failed

Fires when the creation call fails, or when the server rejects it for balance. Replaces the fun-zone use of Insight Generation Timed Out (the 90s poll timer that this migration deleted). Added in BNS-1088 slice 2.

insufficient_coins is the server's balance gate and means no charge and no activity — the client already gates on SPEND.funZoneAct before opening the view, so it only fires when the client's balance was stale. empty_content means the workflow charged and returned ok but the act parsed to zero steps — the (already applied) balance stands, but the unusable activity is not saved to history and the user gets the error/retry screen. The other four come from the shared failureReason enum (src/utils/failureReason.js), identical across every migrated LLM surface so the funnels stay comparable.

Source: ActivityView.jsx

Activity View Completed

Fires when user finishes viewing/listening to an activity.

Source: ActivityView.jsx

Activity View Closed

Fires when user closes an activity without completing it.

Source: ActivityView.jsx

Daily Question

Daily Question Viewed

Fires when the daily question appears on screen.

Source: DailyQuestion.jsx

Daily Question Voted

Fires when user selects an answer.

Source: DailyQuestion.jsx

Partner

Partner Connected

Fires when a partner is connected for the first time (partner_connected transitions false → true).

Source: UserContext.jsx

Payments

All payment events run on the React side via the Natively RevenueCat bridge and a direct RC REST read for entitlement state — Bubble is uninvolved.

Removed: Paywall Viewed / Paywall Dismissed — these only fired from RC's hosted paywall (EntitlementContext.showPaywall()), which has been removed. The app uses a single custom paywall (PlansScreen), tracked via Plans Screen Shown (see below).

Purchase Started

Fires when buy(packageId) is called.

• package_id (string)
• source (string)

Purchase Completed

Fires when the purchasePackage callback returns status: 'SUCCESS'.

• package_id (string)
• transaction_id (string|null)

Purchase Failed

Fires when the purchasePackage callback returns a non-SUCCESS status (or never fires — a null bridge response after the 10s timeout).

• package_id (string)
• reason (string) — best available failure signal, preferring error, then message, then status; bridge_timeout when the callback never fired, else unknown. (Natively reports cancels/errors via status/message, not always error.)
• user_cancelled (bool) — true when status is CANCELLED or any signal mentions "cancel"
• callback_status (string) — raw bridge status (missing if absent)
• callback_message (string|null) — raw bridge message
• bridge_elapsed_ms / total_elapsed_ms (number) — bridge callback time and total incl. entitlement re-poll

Genuine failures (not user cancellations) also emit a log.error → Sentry Issue; cancellations emit log.warn (queryable log, no Issue).

Purchase Pending

Fires when buy() can't confirm the outcome (callback returned no usable signal and the entitlement hasn't flipped within buy()'s window) — the purchase may still have succeeded. The recovery watcher keeps polling the entitlement.

• package_id (string)
• reason (string) — usually bridge_timeout/unknown
• bridge_elapsed_ms / total_elapsed_ms (number)

Purchase Confirmed Late

Fires when the recovery watcher confirms a pending purchase via the RevenueCat entitlement flip (after buy() already returned). Routes into the normal celebration. This is a success that the old code would have logged as Purchase Failed.

• package_id (string)
• elapsed_ms (number) — time from buy() start to confirmation
• recovered_via (string) — mount | foreground | backoff | poll

Purchase Unconfirmed

Fires once when a pending purchase is still unconfirmed after the active confirm window (~5 min) — the Refresh/Restore give-up affordance is shown.

• package_id (string)
• elapsed_ms (number)

Purchase Restore Tapped

Fires when the user taps Restore Purchases.

• source (string)

Purchase Restore Completed

Fires after the post-restore entitlement refresh.

• became_subscribed (bool) — true if restore flipped state from non-paying → paying

Plans screen events

Custom in-app paywall at PlansScreen.jsx. Pushed from Profile → Subscription.

• Screen Viewed { screen: 'plans' } — on mount.
• Element Clicked { screen: 'plans', element_type: 'card', element: 'plan_<label>' } — when a plan row is selected (<label> = key from APP_CONFIG.purchases.packages, e.g. monthly).
• Element Clicked { screen: 'plans', element_type: 'button', element: 'subscribe' } — Subscribe CTA tapped (followed by the standard Purchase Started/Purchase Completed/Purchase Failed chain).
• Element Clicked { screen: 'plans', element_type: 'link', element: 'restore' } — Restore link tapped (followed by Purchase Restore Tapped/Purchase Restore Completed).
• Element Clicked { screen: 'plans', element_type: 'button', element: 'refresh_pending' } — Refresh tapped on the purchase-pending give-up affordance (re-reads the entitlement).
• Element Clicked { screen: 'profile', element_type: 'button', element: 'subscription' } — Subscription row in Profile tapped (entry into the plans screen).

Purchase Started/Purchase Completed/Purchase Failed/Purchase Restore Tapped/Purchase Restore Completed already fire from EntitlementContext.buy/restore; the plans screen passes source: 'plans_screen' so the funnel can be segmented by entry point.

Entitlement Changed

Fires whenever isSubscribed flips on EntitlementContext (renewal, expiry, cross-device sync).

• is_subscribed (bool)

Also: is_subscribed is set as a Mixpanel People property every time EntitlementContext resolves, so the latest known state lives on the user profile for funnel segmentation.

Cohort coin-gate events

Fired by the shared useCoinGate hook (src/hooks/useCoinGate.js), which funnels every coin-spending action (chapter start, simulator session, activity creation, etc.) through one cohort-aware path. Replaces the legacy local if (coins < N) checks scattered across feature files.

Cohort ('A' | 'B' | 'C') is not encoded on these events — it lives on the Mixpanel user profile as the payment_variant People property (the effective value incl. admin overrides, set by <PaymentVariantSeeder>). Segment/break down any coin-gate event by payment_variant for cohort funnels. (The raw Statsig bucket is intentionally not mirrored to Mixpanel — Statsig keeps the exposure for experiment analysis.)

What these events add instead is gate_outcome — which branch the gate took, orthogonal to cohort:

• premium — subscribed, gate bypassed (no variant consulted).

• sufficient — enough coins, gate passed (no variant consulted).

• insufficient — balance short, the cohort drove the decision (A → auto-refill, B/C → paywall). Combine with payment_variant to see the A-vs-B/C split.

• Coin Gate Triggered — every time gate.request() or gate.requestAccess() fires. Properties: source, cost, coins_before, gate_outcome, is_subscribed. Use this as the top of any coin-gate funnel.

• Coin Gate Blocked — fires when the user is short on coins (always the insufficient branch). Properties: source, cost. Segment by payment_variant for the cohort.

• Coin Auto Refill Granted — Group A path (also fires for unbucketed users who fall through to A). Properties: source, amount (EARN.autoRefill = 20 since BNS-1118, was 30).

• Coin Grant Dialog Shown — the CoinGrantDialog bottom-sheet. Two variants (Properties: amount, variant):

  • variant: 'refill' — Group-A auto-refill notice; amount 20. Two divided parts since BNS-1149 (the old "out of coins / lucky day" copy read as a usage barrier):
    • Part 1 — "Here's 20 coins, on us / Coins are already added to your account. Keep going" with a Continue button that closes the sheet and fires Element Clicked { screen: 'coin_grant', element_type: 'button', element: 'continue' } (a CTA-driven close — no Dismissed event, same convention as the paywall CTAs).
    • Part 2 — the ambassador upsell, a bordered box reading "Become a {appName} ambassador / book a call and get a free / 1-year unlimited subscription" (BNS-1118, renamed from give_feedback) — opens a one-click call booking (Lior's Google Calendar, system browser) instead of Intercom, and fires Element Clicked { screen: 'coin_grant', element_type: 'link', element: 'book_ambassador_call' }.
  • variant: 'share' — the share-reward confirmation ("Thanks for sharing! +10 … come back tomorrow"); amount = EARN.share (10). No feedback link.

• Coin Grant Dialog Dismissed — the CoinGrantDialog was closed without a CTA (backdrop tap or swipe-down; the Continue button instead fires its Element Clicked — see above). Property: variant ('refill' | 'share'). Fires once per open. For the refill variant any close (Continue or dismiss) is load-bearing (BNS-1118): closing is what fires the deferred gated action (create act / start chapter), and both closes are the "declined the ambassador offer" negative signal — the booking link does not close the sheet. So the Coin Grant Dialog Shown funnel resolves into Element Clicked { element: 'book_ambassador_call' } (engaged) + Element Clicked { element: 'continue' } + this dismiss.

• Insufficient Coins Paywall Shown — Group B / C path. Properties: source. Segment by payment_variant for the cohort. Followed by the standard Purchase Started chain when the user taps Go Premium.

  • The paywall is a bottom-sheet (InsufficientCoinsPaywallDialog) with three CTAs, each firing Element Clicked { screen: 'insufficient_coins_paywall', element_type, element }: element: 'go_premium' (→ PlansScreen), 'daily_questions' (→ Fun Zone tab), 'give_feedback' (→ profile feedback).
  • Insufficient Coins Paywall Dismissed — fires when the sheet is closed without picking a CTA (backdrop tap), closing the Insufficient Coins Paywall Shown → CTA / dismiss funnel. Properties: source. A CTA-driven close does not fire this (the Element Clicked already records that outcome).

• Coin Balance Panel Shown — fires when the non-premium user taps the coin counter and the "Your coins" sheet (CoinBalancePanel) opens. Properties: coins. The counter tap itself fires Element Clicked { screen, element_type: 'button', element: 'coin_counter' } (screen ∈ the surface: home / journey / daily_question); the sheet's CTA fires Element Clicked { screen: 'coin_balance_panel', element: 'go_premium' }.

• Payment Variant Stamped — fires once when <PaymentVariantSeeder> seeds the Bubble payment_variant field on a fresh server-empty report. Properties: variant ('A' | 'B' | 'C'), source ('statsig' for a real assignment, or 'unbucketed_default' when the user is unbucketed and gets control 'A'). Does not fire for users who already have a value (Bubble source of truth / admin override) or when Statsig is unavailable (outage → retries next session).

Premium-user surfaces

• Premium Badge Tapped — fires when a subscriber taps the top-bar premium badge. Properties: surface ('home' | 'daily_question').
• Premium Status Viewed — fires when the PremiumStatusDialog opens. Properties: subscription_type, expires_at.
• Manage Subscription Tapped — fires when the user taps "Cancel subscription" in the status dialog (deep-links to the OS subscription manager). Properties: platform ('ios' | 'android' | 'web').

Subscription lifecycle screens

• Plans Screen Shown — fires every time the redesigned PlansScreen mounts or is surfaced as an overlay. Properties: source ('profile' | 'post_onboarding_b' | 'insufficient_coins' | 'coin_panel' | 'expired_modal' | 'badge_tap'). Coexists with the older Screen Viewed { screen: 'plans' } event for back-compat; new funnels should use Plans Screen Shown to segment by entry point.
• Plans Screen Dismissed — fires when the user leaves PlansScreen without converting (closes the Plans Screen Shown → subscribe / restore / dismiss funnel). Properties: source (same enum as Plans Screen Shown), reason ('back' = back chevron on the normal plans view; 'already_subscribed' = back chevron or Continue on the "You're Premium" state). Does not fire on the mandatory Group-B gate (back is hidden — the only exits are subscribe or restore).
• Subscription Success Shown — fires when the post-purchase celebration screen mounts. Properties: package_id, subscription_type. The Continue button that exits the screen fires Element Clicked { screen: 'subscription_success', element_type: 'button', element: 'continue' }.
• Subscription Expired Modal Shown — fires when the expired-notice dialog appears (RC entitlement flipped subscribed → not since last session). Properties: last_type ('yearly' | 'quarterly' | 'monthly' | null).
• Subscription Expired Action — fires when the user resolves the expired notice. Properties: last_type, action ('renew' | 'continue'), bonus_granted (bool — true if Bubble was expected to grant 10 welcome-back coins).

People + super properties

subscription_type is pushed as a Mixpanel People property by EntitlementContext on every entitlement refresh — RevenueCat is the source of truth (yearly/quarterly/monthly, null when not subscribed), set alongside is_subscribed. It is not sourced from Bubble/UserContext (that field was never reliably pushed).

The cohort variant is carried by a single People (user-profile) property:

• payment_variant: "A" | "B" | "C" — the effective variant (Bubble source-of-truth field, including admin overrides), people.set by <PaymentVariantSeeder> (src/hooks/usePaymentVariant.js). It's a profile property (not a super property) because the cohort is sticky and server-owned: it survives reset(), is queryable on the user level, and remains segmentable in event reports.

Use payment_variant for all cohort-segmented funnel analysis — break events down by it in reports; it reflects the experience the user actually got. The raw Statsig assignment is not mirrored to Mixpanel as experiment_payments (the payments experiment is suppressed in attachMixpanelMirror, src/utils/experiments.js, to keep one cohort property); use Statsig's own exposure data for randomized (intent-to-treat) experiment analysis.

System

Report Submitted

Fires when a bug report is sent (via clipboard copy or Slack relay).

Source: logCapture.js

Profile Photo Updated

Fires when user crops and saves a new profile photo.

Source: MainTabs.jsx

FTUE Walkthrough Completed

Fires when the user finishes all steps of the first-time user experience walkthrough.

Source: DrLeoWalkthrough.jsx

TTS Error Occurred

Fires when TTS streaming fails (network error, proxy down, etc.). Centralized in useTTS hook — all TTS consumers get tracking automatically.

Source: useTTS.js

Support Unread Badge Shown

Fires when the Intercom unread badge appears (count rises from 0 to n) — a red dot on the profile nav tab plus a count pill on the Profile → Support "Share feedback" row. Fires once per appearance (rising edge), not on every count change; the badge clears itself when the user opens the messenger (Intercom marks the conversation read). Only possible after Intercom boots (logged-in, JWT delivered).

Source: MainTabs.jsx (count from useIntercomUnread / utils/intercom.js)

Push Notification Prompt

Push Prompt Shown

Fires when the pre-permission dialog appears.

Source: MainTabs.jsx, useNotificationGate.jsx

Push Prompt Accepted

Fires when user taps "Enable notifications" in the pre-permission dialog. Tracked BEFORE the native OS prompt.

Source: MainTabs.jsx, useNotificationGate.jsx

Push Prompt Dismissed

Fires when user taps "Not now" in the pre-permission dialog.

Source: MainTabs.jsx, useNotificationGate.jsx

Push Settings Redirect Shown

Fires when the "previously denied" dialog appears in Profile.

Source: MainTabs.jsx

Push Settings Redirect Accepted

Fires when user taps "Open Settings" from the profile notification dialog.

Source: MainTabs.jsx

Store Reviews (rating prompt)

The custom Like/Dislike pre-prompt that gates the native OS store-review sheet. Screen: rating_prompt. See the plan: docs/superpowers/plans/2026-06-29-store-reviews-rating-prompt.md.

Rating Prompt Shown

Fires when the pre-prompt is shown (after the gate passes and the home surface settled).

Source: useRatingPrompt.js

Native Store Review Requested

Fires when the user taps "Rate Bonds in the store" and the native review sheet is invoked. Note: fire-and-forget — the OS decides whether to display it, and a submitted review is not detectable.

Source: useRatingPrompt.js → appReview.js

Rating Feedback Opened

Fires when the user taps "Not yet" → "Please tell us how we can do better" and the feedback flow opens.

Source: useRatingPrompt.js → openFeedback

Rating Prompt Dismissed

Fires when the pre-prompt closes without a response — either the user taps the X / backdrop (reason: 'user'), or the prompt auto-hides because the user left the settled home surface while it was visible (reason: 'left_surface', BNS-1115). Every Rating Prompt Shown therefore resolves into a response event or exactly one Dismissed (modulo app kills).

Source: useRatingPrompt.js

5. Element Clicked Reference

All Element Clicked events. Properties always include screen, element_type, and element. Extra context properties listed in the last column.

Welcome & Auth

FTUE Walkthrough

Main Navigation

Dr Leo

Ask hand (BNS-1067 — Ask Dr Leo PART 2)

The floating Ask affordance, on the journey map and at the end of the Learn, Insight and Practice steps. It is a two-tap control on first exposure only: the intro (unseen) hand reveals the "Tap to ask" label on tap 1 and opens on tap 2, whereas a settled hand (already exposed this session) opens on a single tap and never re-shows the explanation (BNS-1147). So the reveal leg is present only for the first-exposure funnel:

• First exposure (phase: 'intro'): Ask Hand Shown → ask_hand_reveal (tap 1) → ask_hand_open (tap 2)
• Settled (phase: 'settled'): Ask Hand Shown → ask_hand_open (single tap; no ask_hand_reveal)

A user who sees the hand and never opens it (ignores it, or reveals the label and walks away) fires Ask Hand Dismissed, so Ask Hand Shown fully resolves into opens + walk-aways — the negative branch is an explicit event, not just a derived gap.

Property notes:

• surface — journey_map, or step_end for the end of Learn / Insight / Practice. Cross-reference screen on the Element Clicked rows to tell the three step ends apart.
• step — the step just performed, NOT progress.currentStep (which is where the user goes next). At a step end it is that step (learn / insight / practice). On the map it is the most recently completed step of the chapter on screen — act for a completed chapter.
• chapter_id — the chapter the hand carries into Ask. On a paused ("To be revealed tomorrow…") or freshly-unlocked-but-unstarted map this is the previous, completed chapter, not the one the map is nominally showing.
• phase is deliberately reported rather than inferred: the intro plays once per app session, so intro vs settled distinguishes first contact from repeat exposure within that session.

No Act step end — by design. The PRD excludes it ("we have critical actions we don't want to compete with"), compensating with the map hand afterwards. So surface: 'step_end' will never carry step: 'act'; an act-related ask arrives as surface: 'journey_map', step: 'act'. A funnel that expects four step ends is mis-specified.

One intro per SESSION, not per surface and not per chapter (BNS-1147, product 2026-07-27 — this superseded the per-chapter scope shipped for BNS-1067). The "already tapped" flag lives in sessionStorage and is shared across all four surfaces, so a reveal at the end of Learn makes the map hand — and every later chapter's hand — report phase: 'settled'. Expect at most one phase: 'intro' per app session, and a fresh one after a relaunch.

Board warning: any funnel or breakdown that assumed one intro per chapter will see the intro count drop sharply from this release, with the difference landing in settled. The property values are unchanged; only how often each occurs is.

via on the Ask events (BNS-1067)

Every Ask domain event below carries via — where the ask was opened from:

Use via, not source. source is already taken on the Ask↔simulator funnel and means the opposite direction (source: "ask" on Simulator Session Started marks Ask → simulator outbound, see the Simulator section). Reusing it for inbound entry would corrupt that funnel.

via is on all ask events including the negative ones (Ask Session Error, Ask Voice Fallback, Ask Session Abandoned) — otherwise a contextual ask's failure paths would be unattributable and the per-entry funnel couldn't resolve.

An ask reached by tapping through the choice screen reports dr_leo_tab even if that tab was originally opened from the journey: walking back to the choice screen clears the context, so the ask genuinely is no longer about that chapter.

Ask Dr Leo (domain events)

Act (domain events)

Closing-the-loop telemetry for the Act step (commit → check-up reminder → outcome). The Element Clicked rows for these screens are in the Act table below; this table is the domain-event funnel. chapter is the chapter's 1-based index; dynamic is the chapter kind (Phase 2). (Documented retroactively — these shipped in #338 but weren't in the catalog.)

Deferred — days_since_commit (reminder-latency). Act Check-In Viewed / Act Outcome Reported would ideally carry days_since_commit (latency from Act Committed), but there is no client-durable commit timestamp that survives the cold-start return a days-later check-up triggers. Required to enable: add a server committed_date to the act and surface it on the chapter's reactive payload, then set days_since_commit = round((Date.now() − Date.parse(committed_date)) / 86_400_000) on the check-in event. reschedule_count is already derivable in Mixpanel by counting Act Reminder Rescheduled per user+chapter before the outcome — no denormalized property needed.

Onboarding

Journey

Learn Video

Practice

Act

Chapter Celebration

Step Review

Insight Questions

Insight Other Dialog

Insight Playback

Fun Zone

Activity View

Type Detail

Simulator Results

Profile & Settings

Account Info

Name Prompt

Partner Name Prompt

Profile Save (Account Info)

Daily Question

Share Viewer

Push Notifications