tracking-planlisted

# Tracking Plan ## Goal Create an analytics plan that engineering and analytics can implement and QA can verify. ## Workflow 1. Load tracking taxonomy from product context when it exists. 2. Map measurable entry, meaningful operation, important result, and value behavior from the confirmed user journey. 3. Name each event as a unique lowercase semantic `feature_action` identifier. 4. In a PRD, create only `事件`、`事件名称`、`上报时机`、`附加参数`、`备注`; use `/` for empty parameters or notes. 5. Keep `上报时机` to one observable sentence and include only event-external properties in `附加参数`. 6. Omit unsupported events instead of marking them as proposed, inferred, or pending in the PRD. 7. Create a detailed event table, property dictionary, validation notes, and privacy notes only when the user explicitly requests `tracking-plan.md`, CSV, or analytics/engineering handoff. 8. For sensitive domains, explicitly state which raw properties are excluded in the requested detailed handoff, such as health status, pregnancy details, hospital, payment details, government IDs, document titles, expiry dates tied to identity, notification body text, raw contact data, holdings amount, cost basis, trade detail, investment preference, and exact alert threshold. 9. For reminder or notification features, track delivery state, trigger type, and permission-safe category only. Do not track raw reminder content, exact sensitive dates, document names, addresses, or recipient contact details unless the user has supplie