Data Requirements Template for Product Analytics

Detailed enough that the analytics team can answer the business questions without going back to engineering. A good rule: if you need to join the event data with another table to answer a listed question, you are missing a property. Over-instrumenting is cheaper than under-instrumenting. Adding a property later requires a code change and a new release. Adding it now costs an extra line in the schema.

Server-side is the source of truth for anything that involves data integrity: purchases, account creation, subscription changes. Client-side is appropriate for UI interactions that have no server component: button clicks, page views, tooltip hovers. When both are possible, prefer server-side. Client-side events can be blocked by ad blockers and lost during network failures.

Include a `schema_version` property on every event (e.g., `"1.0"`). When the event schema changes (new required property, renamed property), bump the version. This lets the analytics pipeline handle old and new formats gracefully. Never remove a property without bumping the version.

A data requirements document defines the schema for a specific feature or initiative. An [event tracking plan](/templates) defines org-wide naming conventions, property standards, and governance rules. The data requirements doc references the tracking plan's conventions and adds feature-specific detail. Use both together.

At minimum: the PM (owns the business questions), the engineering lead (owns implementation feasibility), and the analytics or data team lead (owns data quality). If the events feed into financial reporting or compliance systems, include the data governance owner as well. ---