题目重点：分析新产品上线后的餐厅收入或平均收入下降，先验证指标再分解订单、客单价与构成。
题意与假设
这道练习题保留了面经中值得训练的核心约束，并将需要澄清的条件单独列出。现场拿到变体时，先和面试官确认这些条件。
- 先问total revenue还是average revenue per restaurant，gross/net、完成订单/退款、时间段与新老餐厅；平均下降不必然代表每家生意下降。
解题路线
- 先验证埋点、ETL/支付账本、时区和延迟，确认变化真实。平均收入分解为总收入/活跃餐厅数，开店增加低量新店会改变构成，需same-store cohort比较。
- 净收入可拆订单数×平均净单价，订单数拆流量×转化×可履约率；再分delivery/pickup、地区/类型、新老用户、餐厅与menu版本。不要凭整体相关性立即归因launch。
- 内部检查UI漏斗、价格优惠、搜索曝光/排序、缺菜/关店、配送延迟与技术错误；外部看季节、节假日、竞争与地区异常，提出可证伪假设和对应查询。
- 有实验优先比较随机对照，非实验可用可比未上线群与预趋势做谨慎差分。共享用户/市场溢出影响对照，曝光选择造成偏差，需要说明限制。
- 决策依据受影响范围和证据：故障明确先止损，再验证恢复；产品trade-off看用户体验、餐厅贡献利润与平台净收益，不只追gross revenue。
手动走一遍
上线新店后收入从100万到110万，活跃店从1000到1500，平均从1000降733；same-store未变时不是既有餐厅被损害。若same-store订单降再看转化/曝光/履约分解，区分构成与真实下降。
规模与取舍
按cohort×date×restaurant建立一致面板，数据量与事实扫描相关；少量维度切分先于任意高维挖掘。多重分群发现需要验证，不能因某个小切片显著就认定根因。
易错点与追问
容易失分的边界
- 只看到平均值下降，忽略新餐厅改变分母。
- 上线前后变化直接称因果，忽略同时发生节日/促销。
继续深挖
- 新feature如何设business goal与metric dimensions？在假设验证后选主目标并设计guardrails。
- 若日志故障同时影响体验和计数，怎样用独立支付/服务数据区分真实与测量下降？
