Промпт для PRD — план эксперимента и метрики

Create a comprehensive, data-focused Product Requirements Document (PRD) ready for engineering, analytics, product, and design teams. Deliver two parts: (A) a reusable PRD template with clearly labeled sections and placeholders; (B) a fully filled, concrete example PRD for a single feature (use the example: "Personalized Home Feed to increase Daily Active Users"). Include explicit, implementable data artifacts (event tracking plan, data contracts, SQL examples, measurement and experiment plans, dashboards, instrumentation checklist, rollout plan, and success criteria). Use plain text and section headers.

Required sections and content (for both template and filled example):

1) One-line title and one-paragraph summary (goal, primary hypothesis, scope, target users, timeline).

2) Goals and success metrics
- Primary metric (definition, numerator, denominator, measurement window, baseline, target).
- Secondary metrics and guardrail metrics (each defined).
- Impact estimate and business rationale.

3) Background and user problem
- Short context, user pain points, key research evidence or assumed insights.

4) Personas and user journeys
- 2–3 personas and 2–3 key user flows that the feature affects.

5) Product approach and requirements
- High-level approach and design principles.
- Functional requirements (must-have / should-have / nice-to-have), each with acceptance criteria.
- Non-functional requirements (latency, availability, scale targets, accessibility, localization).

6) Data & analytics specification
- Event tracking plan: for each event include event_name, description, trigger, required attributes (name, type, example values), owner, and data retention.
- User identifiers to use and privacy considerations (hashed/PII).
- Data contract: schema definition (field, type, nullability), expected volumes, and SLAs for event delivery.
- Data sources and ETL/warehouse locations.

7) Measurement plan and SQL
- Exact metric definitions and canonical SQL queries (BigQuery-compatible) to compute primary and key secondary metrics, with comments explaining cohorts and time windows.
- Baseline numbers and how to compute them from historical data.

8) Experimentation plan
- Hypothesis statement.
- Randomization unit, treatment variants, allocation, and sample ratio.
- Minimum Detectable Effect (MDE) assumptions, baseline conversion, power (e.g., 80%), significance (e.g., 95%), and resulting sample size and experiment duration calculation. Show the calculation and numeric result.
- Stopping, monitoring, and sequential testing guidance, invariant metrics to validate randomization.
- Analysis plan and metric aggregation window.

9) Instrumentation and QA checklist
- Implementation checklist for developers (exact event names, attribute types, required fields).
- QA test cases and expected results.
- Data validation queries to run post-deploy.

10) Dashboards, reporting, and alerts
- List of dashboard panels (title, metric, visualization type, filters, owner).
- Alerting rules (metric, threshold, frequency, on-call).
- Weekly and executive reports to produce.

11) Release, rollout, and rollback plan
- Phased rollout steps, percent rollout schedule, monitoring during rollout, ramp criteria, rollback criteria and procedure.

12) Risks, assumptions, and dependencies
- Key technical, data, user, and compliance risks and mitigations.
- Cross-team dependencies and owners.

13) Timeline, milestones, and stakeholders
- High-level milestone timeline (design, dev, instrumentation, experiment, rollout).
- Stakeholders and responsibilities.

14) Appendix
- Example SQL queries, sample dashboard panel JSON-like spec, full event schema list, and links placeholder for design assets and data docs.

Deliverable formatting requirements:
- Provide the template first with placeholders and brief instruction per placeholder.
- Provide the filled example immediately after using the feature "Personalized Home Feed" with realistic baseline numbers, concrete SQL queries, a full instrumentation table (at least 6 events/attributes), a power/sample-size calculation with numbers, and specific rollout percentages and monitoring thresholds.
- Ensure all metric definitions are unambiguous and SQL-ready.
- Include explicit QA queries and one sample SQL that computes the primary metric for the example.
- Keep language concise and use plain text section headers.