feat(onboarding): track choose-provider click in auto-deploy flow - #3572
Conversation
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Path: .coderabbit.yaml Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (3)
📝 WalkthroughWalkthroughThe PR adds provider-selection analytics to ChangesProvider selection analytics
Estimated code review effort: 2 (Simple) | ~10 minutes Possibly related PRs
Suggested reviewers: ✨ Finishing Touches📝 Generate docstrings
🧪 Generate unit tests (beta)
Warning There were issues while running some tools. Please review the errors and either fix the tool's configuration or disable the tool if it's a critical failure. 🔧 ESLint
ESLint install timed out. The project may have too many dependencies for the sandbox. Comment |
Fire an analytics event when a user clicks "Choose my provider" during the auto-deploy flow, switching from autopilot to manual provider selection. The event sits in the onboarding funnel next to onboarding_deploy_click and carries the template name so the drop-off can be segmented per template.
e2e82b9 to
507f2a7
Compare
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## main #3572 +/- ##
==========================================
- Coverage 76.13% 75.34% -0.80%
==========================================
Files 1157 1067 -90
Lines 30057 27709 -2348
Branches 7440 6986 -454
==========================================
- Hits 22885 20877 -2008
+ Misses 6338 6028 -310
+ Partials 834 804 -30
*This pull request uses carry forward flags. Click here to find out more.
🚀 New features to boost your workflow:
|
There was a problem hiding this comment.
LGTM — straightforward analytics instrumentation addition.
Extended reasoning...
Overview
The PR adds a single analyticsService.track("onboarding_choose_provider_click", ...) call inside the existing onChooseProvider handler in AutoDeployFlow.tsx, adds the corresponding literal to the AnalyticsEvent union in analytics.service.ts, and adds a new unit test asserting the tracking call fires with the expected payload. No control flow, business logic, or existing behavior is changed — the new call is purely additive and sits before the pre-existing stopAutopilot() / setBidStrategy("select") calls, which remain untouched.
Security risks
None. This is a client-side analytics event with a static event name and non-sensitive properties (category, templateName, both already used elsewhere in the file/props). No user input is passed to the analytics call beyond the template name, which was already flowing through this component as a prop before this change.
Level of scrutiny
Low. This is a pure instrumentation addition (XS-sized PR) with no impact on the deployment flow logic, no new dependencies, and full unit test coverage of the new behavior (including verifying the exact event name and payload shape). The two candidate issues raised by the bug-hunting system (missing flush-before-navigation, double-click double-firing) are non-issues for a best-effort analytics event — losing or double-counting an occasional click event has no functional impact on the deployment flow, and the existing code has no debounce/flush pattern for the sibling onContactSupport tracking either, so this is consistent with existing conventions.
Other factors
Test coverage for the new behavior is included and follows the repo's setup() pattern with mock<T>(), matching the project's testing conventions. No outstanding review comments need addressing (only an automated CodeRabbit tool-failure notice, unrelated to code correctness).
Summary by CodeRabbit
New Features
Tests