PRD Template for Analytics

Example: "Product decisions are currently made based on anecdotal feedback and gut instinct. We have basic page view tracking via Google Analytics but no event-level tracking of user actions. When asked 'how many users complete the onboarding flow?' or 'which feature has the highest adoption?' — the team cannot answer. Three recent product decisions (removing a feature, changing pricing, redesigning the dashboard) were made without data. Two of the three resulted in metrics decline."

Example: "Primary: Track all core user actions so the team can answer any product question within 5 minutes. Coverage: 100% of user-facing features have event tracking within 60 days. Accessibility: Any PM can create a funnel analysis or cohort comparison without SQL or engineering help. Compliance: All tracking compliant with GDPR, CCPA, and customer data processing agreements."

Example: "As a product manager, I want to see a funnel showing the conversion rate through my feature's core flow so that I can identify which step has the highest drop-off. Acceptance criteria: funnel supports any sequence of events; each step shows count, conversion rate, and median time; funnels can be filtered by date range, user segment, and platform; results load within 5 seconds."

Example: "FR-1: The system must capture events with a standard schema: event_name, user_id, timestamp, session_id, and a properties object with up to 50 key-value pairs. FR-2: The analytics UI must support funnel analysis with up to 10 steps, filterable by any event property. FR-3: The system must support cohort analysis based on signup date, first action, and any custom event. FR-4: All event data must be queryable via a SQL interface for advanced analysis. FR-5: The system must support event-level data export in CSV and JSON formats."

Example: "NFR-1: Event ingestion must handle 10,000 events per second without impacting product performance. NFR-2: Funnel queries must return results within 5 seconds for datasets up to 100M events. NFR-3: Event data must be available for querying within 5 minutes of occurrence. NFR-4: All personally identifiable information must be pseudonymized at ingestion time. NFR-5: Event data must be retained for 24 months, with the ability to delete specific user data within 72 hours per GDPR requests."

Example: "Metric 1: Event tracking coverage (features with complete tracking / total features). Target: 100% within 60 days. Metric 2: Weekly active analytics users (team members who query analytics). Target: 80% of PMs. Metric 3: Data-informed decision rate (decisions with supporting analytics / total product decisions). Baseline: ~20%. Target: 80%. Metric 4: Time to answer a product question. Baseline: days (requires engineering). Target: under 5 minutes self-service."

Example: "Event collection will use a lightweight client-side SDK that batches events and sends them to our ingestion endpoint every 10 seconds. Events are validated against a schema, then written to a Kafka topic for buffering. A consumer writes events to ClickHouse for fast analytical queries. The analytics UI queries ClickHouse directly for interactive analysis. For compliance, we will implement a data deletion pipeline that removes specific user events within 72 hours of a GDPR request."

Example: "Risk: Tracking code has bugs that produce incorrect event data, leading to wrong product decisions. Likelihood: High. Impact: Critical. Mitigation: Implement server-side event validation against a schema. Automated tests for all critical funnel events. Weekly data quality audit comparing analytics numbers against database queries. Risk: Analytics tracking degrades product performance. Likelihood: Medium. Impact: High. Mitigation: Client-side SDK uses async event batching — tracking never blocks UI rendering. Events are buffered in memory and sent every 10 seconds."