讲一个你推动数据需求时和产品/算法产生分歧，最终如何解决的例子。
协作STAR影响力
考察意图
考察沟通、优先级与「用数据对齐目标」的软技能，不是让你抱怨合作方。
回答框架
- 用 STAR：情境→任务→行动→结果。
- 强调共同目标与证据，而非对错。
- 展示你的专业边界与妥协点。
- 沉淀机制避免重演。
参考答案（口述版）
建议按 STAR 准备真实项目（以下为结构示例，面试时换成你的经历）：
S：产品希望上线某活动并「用 GMV 证明成功」，算法希望先看实验期内的人均消费与留存护栏。
T：你作为数据侧需要在两天内给出可接受的评估方案与口径。
A：你拉齐成功标准——主指标 + 护栏；说明只看 GMV 可能被流量结构干扰；给出队列对比与简易实验设计；把取数成本与风险讲清楚；最终达成「先小流量实验，再看 GMV 与次留」。
R：避免了一次可能的错误全量；事后把评估模板沉淀进需求评审清单。
原则：不站队攻击；把分歧翻译成可验证假设；明确你能交付的数据与做不到的承诺。
关键词
STAR主指标+护栏书面对齐沉淀模板
面试官可能的追问
追问 1：如果对方强势坚持错误口径怎么办？
书面记录风险与备选口径，向上同步一次；在结果解读时并列展示「对方口径」与「推荐口径」的差异，让决策可见。
常见踩坑
- 故事变成吐槽大会
- 没有结果与沉淀，只剩过程情绪
记忆锚点
分歧用可验证假设消解；STAR 讲清你的判断与结果。