Analytics Event

Analytics events exist only as vague tribal knowledge. An engineer mentions 'I think we fire something on signup' but nobody can list which events exist, what properties they carry, or where they are defined. When the product manager asks 'do we track add-to-cart?' the answer is 'let me check the code.' There is no written inventory of analytics events.

None — AI cannot analyze product behavior because no analytics event definitions or documentation exist anywhere.

Analytics events are scattered across implementation code, old wiki pages, and one-off tracking plans in Google Sheets. Event naming varies wildly — 'button_click', 'ButtonClick', 'btn_clicked' all exist. Some events have documented property schemas; most do not. Finding out what a specific analytics event captures requires reading the source code or asking the engineer who added it.

AI could scan code for event-firing calls, but cannot reliably map analytics events to business actions because naming is inconsistent and property documentation is missing or stale.

Analytics events are documented in a tracking plan with consistent naming conventions, property lists, and event descriptions. Engineers reference the tracking plan before adding new events. However, the tracking plan is a static document that drifts from implementation — events get added in code without updating the plan, and deprecated events linger. The PM can browse events by name but cannot easily query which events relate to a specific user journey or business metric.

AI can surface analytics event documentation and flag naming convention violations, but cannot validate whether documented events match actual implementation or reliably connect events to business outcomes because the tracking plan lacks links to product features and metric definitions.

Analytics events are well-documented, current, and contextually rich. Each event record includes the event name, property schema with types and allowed values, the product feature it instruments, the user journey stage, and which downstream metrics depend on it. A product analyst can query 'show me all analytics events in the checkout flow that feed our conversion metric' and get an accurate, complete answer.

AI can audit analytics event coverage against product features, identify instrumentation gaps, and recommend new events for under-tracked user journeys. Cannot yet auto-generate optimal event schemas because events lack formal ontological relationships to each other and to the behavioral model.

Analytics events are formal entities in a product intelligence ontology. Each event has typed relationships to the feature it instruments, the user journey stage, upstream trigger events, downstream metric impacts, and the user segment definitions it participates in. An AI agent can answer 'which analytics events in our activation flow have no downstream metric dependency and may be safe to deprecate?' with structured, validated results.

AI can autonomously design analytics event schemas for new features based on the existing ontology, detect redundant or orphaned events, and generate instrumentation specifications that engineers can implement directly.

Analytics events are self-documenting. The instrumentation code is the tracking plan — event definitions in code automatically generate human-readable documentation, validate property schemas at build time, and update the product intelligence graph in real-time. When an engineer adds a new analytics event, the tracking plan, metric dependencies, and coverage maps update themselves without manual intervention.

Can autonomously maintain the complete analytics event catalog, detect instrumentation drift at build time, generate optimal event schemas for new product features, and continuously validate that every user journey is fully instrumented.

Ceiling of the CMC framework for this dimension.