feat(admin): add frontend onboarding analytics - #2977
Conversation
|
Warning Review limit reachedYou’ve reached a temporary PR review limit under our Fair Usage Limits Policy. Next review available in: 25 minutes Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available. How can I continue?After more reviews become available, a review can be triggered using the To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews. How do review limits work?CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability. For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window. Please refer docs for additional details. Review details⚙️ Run configurationConfiguration used: Organization UI Review profile: ASSERTIVE Plan: Pro Run ID: 📒 Files selected for processing (3)
📝 WalkthroughWalkthroughAdds a read-only platform-admin frontend onboarding dashboard for version 1 ChangesFrontend onboarding analytics
Estimated code review effort: 4 (Complex) | ~45 minutes Sequence Diagram(s)sequenceDiagram
participant Admin
participant FrontendOnboardingPage
participant AdminDashboardStore
participant admin_stats
participant PostHog
Admin->>FrontendOnboardingPage: select date range
FrontendOnboardingPage->>AdminDashboardStore: request analytics
AdminDashboardStore->>admin_stats: dispatch metric category
admin_stats->>PostHog: execute HogQL query
PostHog-->>admin_stats: grouped onboarding rows
admin_stats-->>AdminDashboardStore: analytics response
AdminDashboardStore-->>FrontendOnboardingPage: display KPI and funnel data
Possibly related PRs
Suggested labels: Suggested reviewers: 🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (4 passed)
✨ Finishing Touches 💡 1📝 Generate docstrings 💡
Comment |
There was a problem hiding this comment.
Stale comment
Risk: medium. Left a non-blocking comment — this admin analytics change (frontend dashboard + private PostHog aggregation) is above the low-risk auto-approve threshold, and Cursor Bugbot was not present to provide a clean signal. Human review is needed; assigning a reviewer.
Sent by Cursor Approval Agent: Pull Request Approver External
Merging this PR will not alter performance
Comparing Footnotes
|
There was a problem hiding this comment.
2 issues found across 17 files
Confidence score: 4/5
- In
src/pages/admin/dashboard/frontend-onboarding.vue, theAdminFunnelChartandAdminStatsCardloading states use unprefixed DaisyUI spinner classes, so date-range refreshes can appear blank and make users think data failed to load—switch those spans tod-loading d-loading-spinner d-loading-lg(or the configuredd-variants) to restore visible loading feedback.
Prompt for AI agents (unresolved issues)
Check if these issues are valid — if so, understand the root cause of each and fix them. If appropriate, use sub-agents to investigate and fix each issue separately.
<file name="src/pages/admin/dashboard/frontend-onboarding.vue">
<violation number="1" location="src/pages/admin/dashboard/frontend-onboarding.vue:135">
P2: KPI cards show an empty loading area during date-range refreshes because `AdminStatsCard` uses unprefixed DaisyUI spinner classes. Update that component’s spinner classes to `d-loading d-loading-spinner d-loading-lg` so this page has a visible loading state.</violation>
<violation number="2" location="src/pages/admin/dashboard/frontend-onboarding.vue:176">
P2: The funnel becomes blank rather than visibly loading after a date-range change because `AdminFunnelChart` uses unprefixed DaisyUI spinner classes. Update its loading span to use the configured `d-loading` class names.</violation>
</file>
Tip: cubic can generate docs of your entire codebase and keep them up to date. Try it here.
Re-trigger cubic
…ding-dashboard # Conflicts: # src/constants/adminTabs.ts # src/stores/adminDashboard.ts # supabase/functions/_backend/private/admin_stats.ts # supabase/functions/_backend/utils/builder_analytics.ts # supabase/functions/_backend/utils/posthog_read.ts # tests/posthog-read.unit.test.ts
There was a problem hiding this comment.
Stale comment
Risk: medium. Left a non-blocking comment — this admin analytics change (dashboard UI + private PostHog aggregation) is above the low-risk auto-approve threshold, and Cursor Bugbot was not present. Human review is needed; riderx is already assigned.
Sent by Cursor Approval Agent: Pull Request Approver External
There was a problem hiding this comment.
Actionable comments posted: 4
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@docs/superpowers/plans/2026-08-10-frontend-onboarding-admin-dashboard.md`:
- Around line 1413-1422: Update the validation instructions in
docs/superpowers/plans/2026-08-10-frontend-onboarding-admin-dashboard.md at
lines 1413-1422 to run bun run lint:fix before bun run lint and bun run
typecheck:frontend, and update lines 1454-1462 to run bun run lint:fix before
the repository validation commands; ensure both validation sequences and the
frontend commit workflow always apply the auto-fix first.
- Around line 1511-1518: Update the PR creation instructions in the onboarding
admin dashboard plan to require AI-generated sections titled Summary,
Motivation, Business Impact, and Test Plan before creating the pull request.
Include the existing PR description requirements in the Test Plan or appropriate
sections, and ensure Task 7 explicitly enforces these sections.
In `@tests/admin-stats.unit.test.ts`:
- Around line 63-70: Update the test case for the frontend onboarding analytics
metric to use the concurrent test variant by changing its `it` declaration to
`it.concurrent`, while preserving the existing schema parsing and assertion.
In `@tests/frontend-onboarding-analytics-model.unit.test.ts`:
- Around line 23-193: Convert the independent tests in
tests/frontend-onboarding-analytics-model.unit.test.ts (lines 23-193) and
tests/admin-frontend-onboarding-dashboard.unit.test.ts (lines 127-343) from it()
to it.concurrent(), using it.concurrent.each() for parameterized cases. Leave
the four already-concurrent adapter tests unchanged.
🪄 Autofix
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: ASSERTIVE
Plan: Pro
Run ID: 75994039-1ead-406d-a162-b58be37fb38f
📒 Files selected for processing (15)
docs/superpowers/plans/2026-08-10-frontend-onboarding-admin-dashboard.mddocs/superpowers/specs/2026-08-10-frontend-onboarding-admin-dashboard-design.mdmessages/en.context.jsonmessages/en.jsonsrc/constants/adminTabs.tssrc/pages/admin/dashboard/frontend-onboarding.vuesrc/services/adminFrontendOnboarding.tssrc/stores/adminDashboard.tssupabase/functions/_backend/private/admin_stats.tssupabase/functions/_backend/utils/frontend_onboarding_analytics.tssupabase/functions/_backend/utils/frontend_onboarding_analytics_model.tstests/admin-frontend-onboarding-dashboard.unit.test.tstests/admin-stats.unit.test.tstests/frontend-onboarding-analytics-model.unit.test.tstests/frontend-onboarding-analytics.unit.test.ts
🔗 Linked repositories identified
CodeRabbit considers these linked repositories for cross-repo context during reviews:
Cap-go/capacitor-updater(manual)
There was a problem hiding this comment.
Stale comment
Risk: medium. Left a non-blocking comment — admin onboarding analytics (UI + private PostHog aggregation) is above the low-risk auto-approve threshold, and Cursor Bugbot was not present. Human review is needed; riderx is already assigned.
Sent by Cursor Approval Agent: Pull Request Approver External
There was a problem hiding this comment.
Stale comment
Risk: medium. Left a non-blocking comment — admin onboarding analytics (UI + private PostHog aggregation) is above the low-risk auto-approve threshold, and Cursor Bugbot was not present. Human review is needed; riderx is already assigned.
Sent by Cursor Approval Agent: Pull Request Approver External
There was a problem hiding this comment.
Risk: medium. Left a non-blocking comment — admin onboarding analytics (UI + private PostHog aggregation) is above the low-risk auto-approve threshold, and Cursor Bugbot was not present. Human review is needed; riderx is already assigned.
Sent by Cursor Approval Agent: Pull Request Approver External
There was a problem hiding this comment.
1 issue found across 12 files (changes from recent commits).
Confidence score: 4/5
- In
docs/superpowers/plans/2026-08-10-frontend-onboarding-admin-dashboard.md, the stage-to-stage conversion summary logic appears to report 100% when a prior stage count is zero, which can misstate funnel health and mislead onboarding decisions. Update the conversion rule to treat zero-predecessor transitions as 0% or N/A so later-stage percentages can’t appear artificially perfect.
Prompt for AI agents (unresolved issues)
Check if these issues are valid — if so, understand the root cause of each and fix them. If appropriate, use sub-agents to investigate and fix each issue separately.
<file name="docs/superpowers/plans/2026-08-10-frontend-onboarding-admin-dashboard.md">
<violation number="1" location="docs/superpowers/plans/2026-08-10-frontend-onboarding-admin-dashboard.md:1414">
P2: The stage-to-stage conversion summaries show 100% for any later stage whose immediate predecessor reached zero, which misrepresents the funnel: with reached [10,8,0,0] the Organization stage shows 0% but Setup shows 100% even though nobody reached it. Guard the conversion so a zero-reached previous stage reports 0% (or null) instead of 100% — this case (a stage collapsing entirely while the cohort has attempts) is plausibly common in onboarding dropoff and is not covered by the existing zero-cohort test.</violation>
</file>
Tip: Review your code locally with the cubic CLI to iterate faster.
Re-trigger cubic
|





Summary
pre_org/onboarding_version = 1flow.Motivation
The existing admin views do not show where new users leave the first app-creation wizard. A dedicated funnel makes the early Intent → Details → Organization → Setup path measurable without mixing it with existing-organization or demo flows.
Business Impact
This gives the team a day-by-day view of onboarding volume, completion, time to setup, and the largest transition drop-off. It should make confusing steps easier to identify and prioritize, helping improve first-app activation.
Test Plan
Analytics contract:
onboarding_attempt_id, cohort-started by its first Intent view.setupas early-onboarding completion; CLI execution is intentionally outside this funnel.Verification:
Summary by CodeRabbit