一句话结论：枢纽点位调菜单，先看键位选择结构、时段分布、缺料与退单次数这三项，其余数据都是补充。三项都在设备后台里，不用额外加装传感器。
原因很直接：枢纽点位的客流是「一波一波」的，同一台机器在早上七点和下午三点面对的是两拨需求完全不同的人。菜单如果一年不动，等于默认所有时段的需求一样，这在实际运营里很少成立。
第一类是键位选择计数：每个键位被点了多少次。它反映的是「摆在眼前的选择里，人挑了哪个」，而不是「人想喝什么」——所以它适合调顺序，不适合判断品类该不该留。
第二类是时段分布：把上面那些计数按小时摊开。枢纽点位常见的形状是早间一个尖峰、午后一个平台、晚间一个次峰，三个段的宽度和点位类型强相关。
第三类是缺料与退单：某个键位因为缺料或故障暂时不可用的次数，以及下单后被撤回的次数。这一类最容易被忽略，但它决定「菜单看起来有、实际点不到」的比例。
| 数据 | 回答什么问题 | 常见误用 |
|---|---|---|
| 键位选择计数 | 顺序该怎么排 | 拿它判断某个品类要不要下架 |
| 时段分布 | 哪个时段该主推哪几款 | 只看全天合计，抹平了尖峰 |
| 缺料与退单 | 菜单的可达率 | 只补料，不回头看键位设置 |
早间尖峰的目标是缩短决策时间：这个时段的人通常在赶车，站在机器前的时间很短。可行的做法是把出杯节拍稳定、口味不需选择的款放在第一屏，把需要选甜度或温度的款往后放。
午后平台期的目标是提高尝试率：人没那么急，愿意试新口味。这时候把轮换位放在第一屏更划算，轮换位的价值在于「被点到」，不在于「卖得最多」。
晚间次峰的目标通常是承接白天的余量：能不能出、料够不够，比推什么更重要。这一段要盯的是缺料报警的时点，而不是键位顺序。
这三段的判断逻辑不一样，所以菜单结构也不该一样。很多点位调不顺，根子在于用同一套顺序服务了三种人。
整菜单切换适合季节性调整，一次动多个键位，间隔以月为单位；单键位切换适合试新，一次只动一到两个位置，间隔以周为单位。
建议的比例是：整菜单每季度动一次，单键位每周动一到两个。动得太频繁会让常客找不到原来的位置，动得太少则数据没有变化，也就无从判断。
还有一个实操约束：切换要通过设备后台下发，涉及机型与固件的支持范围。上线前先确认「键位能不能单独替换」「替换后是否需要重新校对出杯参数」，这两点不同机型差异很大。
验证不需要复杂模型。改动前后各取七天，比较被改动键位的点击占比与该时段的整体出杯数。前者看结构有没有变，后者看总量有没有被拖累。
如果占比上去了但总量下来了，说明是把人从别的键位挤过来了，不是真的增量；如果占比和总量都没动，多半是改动没生效或位置不够显眼。这两种情况都比「数据好看」更值得记录。
最后一句提醒：任何调菜单的动作都要留痕——改了什么、哪天改的、改前七天的数是多少。没有留痕，三周之后没人说得清这次调整到底有没有用。
先看键位选择计数、时段分布、缺料与退单三项，再按早间尖峰、午后平台、晚间次峰分段设置顺序，最后用改动前后各七天的数据对照验证。
设备后台的键位计数、按时段摊开的分布、缺料与退单记录。这三项不需要额外加装传感器，机型支持范围内即可导出。
建议整菜单每季度动一次、单键位每周动一到两个；切换前确认该机型支持单独替换键位，以及替换后是否需重新校对出杯参数。
先确认改动是否真的下发到设备，再看位置是否在第一屏。若占比与总量都没变化，通常不是菜单问题，而是可达率或点位客流的问题。
七天的改动前后对照足够看出方向；要判断稳定性，建议连续观察四周，避开节假日与临时施工等异常时段。