Design an analytics event schema

WHAT THIS TESTS This evaluates whether you treat analytics as a designed schema with governance, not a pile of ad-hoc calls. Good taxonomy is what makes funnels and cohorts possible later.

A GOOD ANSWER COVERS Naming: pick one pattern, object then action, in lower snake_case, like video_played, and apply it everywhere. Properties: use stable typed keys, include units in the name, like duration_seconds, prefer enums for categoricals, and never reuse a key for two meanings. Maintain a tracking plan as the single source of truth and validate events against it. Every event should carry shared context automatically: a stable user id and an anonymous id for stitching, a session id, an ISO timestamp, platform, and app version. Keep payloads flat and small. Version the schema so changes are traceable.

COMMON WRONG ANSWERS Inconsistent casing and tense like PlayVideo, videoPlayed, video_play. Putting values into event names, such as video_played_30s, which explodes cardinality. Untyped free-form properties. Omitting identity and timestamp so events cannot be joined or ordered.

LIKELY FOLLOW-UPS How do you enforce the tracking plan in CI? How do you handle high-cardinality properties? How would you evolve duration_seconds to a richer object without breaking consumers?

ONE CONCRETE EXAMPLE A video_played event payload: event is video_played; properties include video_id of v_8842, video_title, duration_seconds of 212, position_seconds of 0, autoplay of false, quality of 720p. Context includes user_id, anonymous_id, session_id, timestamp in ISO 8601, platform of ios, app_version of 4.2.1. video_id joins to the catalog, position_seconds distinguishes a start from a resume, autoplay separates intentional plays, and the context block makes the event attributable and orderable.