How would you instrument a 4-step onboarding wizard?

WHAT THIS TESTS: This question tests whether you treat analytics as a first-class system design problem rather than an afterthought. The interviewer wants to see that you understand the difference between raw telemetry and a structured tracking plan that a product manager or data analyst can query without writing custom SQL. Specifically, they are looking for awareness of funnel semantics: ordered steps, unique user attribution, and the ability to distinguish progression from completion.

A GOOD ANSWER COVERS: First, name two explicit events: Step Started and Step Completed. Step Started fires when the user lands on or renders a step, and Step Completed fires when they successfully submit or advance. Second, list critical properties on every event: step_index as an integer from one to four, step_name as a human-readable label, flow_variant if you are running an experiment, and error_message or error_code when validation fails. Third, explain identity: include distinct_id and timestamp on every payload so the analytics platform can sequence the journey and deduplicate refreshes. Fourth, mention instrumentation location: fire Step Started from the component mount or route entry, and Step Completed from the success callback of the API that persists the step, not from the click handler, so you do not count users who abandon while the network request is in flight.

COMMON WRONG ANSWERS: A red flag is proposing only generic page_view or screen_view events and assuming the analyst will infer the wizard steps from URLs. Another red flag is tracking only button clicks without confirmation that the backend accepted the data, which overstates progression. Some candidates suggest a single Wizard Completed event with no per-step granularity; this makes it impossible to identify which step causes drop-off. Finally, omitting session or device identifiers makes it hard to distinguish a user who returns tomorrow from a continuous session.

LIKELY FOLLOW-UPS: The interviewer may ask how you would handle users who refresh the page in the middle of step two, how you would instrument partial data saves for a long form, or how you would distinguish a user who skipped step three via a deep link from one who dropped off. They may also ask how you would validate the data before launch, referencing QA and data audits.

ONE CONCRETE EXAMPLE: Imagine a SaaS signup with steps: Account Info, Team Details, Integrations, and Invite Colleagues. You fire Step Started with step_index 2 and step_name Team Details when the route mounts. If the user fills in nothing and closes the tab, only Step Started is recorded. If they submit valid data and the API returns 200, you fire Step Completed with the same step_index and step_name plus a property team_size reflecting the input. In your funnel report, you filter Step Completed where flow_variant equals control and group by step_index. The conversion rate from step 2 to step 3 is the count of distinct distinct_ids with Step Completed at step_index 3 divided by those with Step Completed at step_index 2. If step 3 shows a 62 percent drop while others show 12 percent, you have isolated the problem.