互动数据能用来干什么：从出杯计数到菜单优化，不含任何身体信息

1先划边界：哪些东西从来不是「互动数据」

谈数据应用，第一步不是讲能做什么，是讲清楚不做什么。无人饮品设备的互动数据只包括三类：交易与出杯计数（什么时候、哪个品类、出了几杯）、设备事件（缺料、故障、清洁周期）、以及聚合后的品类偏好分布——注意是「今天选 A 口味的有多少杯」这种计数，不是「谁选了什么」的名单。

设备不建立任何个人档案：不存储可识别个人身份的信息，不把单次互动与具体的人关联起来，更不采集、不分析任何身体信息。交互入口（面部、手部动作、语音、触屏）只用来完成一件事——触发一次交互与口味选择；动作识别是「有没有人做完了动作」的即时判断，判断完即丢弃，不留存画面与轨迹。这是设备数据设计的边界，也是一切应用的前提。

2互动数据的三层范围：计数、事件、状态

三层的作用不同：计数层回答「卖得怎么样」，事件层回答「哪里需要人」，状态层回答「机器好不好」。运营方打开后台，看到的应该是这三层各自成表，而不是混在一起的一堆数字。判断一台设备的数据能力是否合格，就看这三层能不能分开看、能不能按时间拉出来。

3四个正经用途：菜单、补货、点位、预警

用途一：菜单优化。品类选择的计数按周聚合后，把长期垫底的品类撤下、高频品类保持满仓，就是最朴素也最有效的菜单迭代。每月留一个空仓试新品，用数据决定它是转正还是撤下，而不是凭感觉。

用途二：补货计划。出杯量按时段分布 + 料位余量，可以推算每种原料的消耗速度，补货从「凭经验隔天去」变成「按消耗速度排班」。多点位运营时，这一条直接决定运营人效。

用途三：点位运营。不同点位的品类偏好分布不同——写字楼与社区的时段曲线、品类比例都不一样。偏好分布看什么：看相对比例而不是绝对数字，看工作日与周末的差，看新品上架后的曲线变化。三个视角合起来，就能判断这个点位适合什么菜单、什么价格档位。

用途四：故障预警。制作失败率连续抬升、某温区温度波动变大，这些往往比整机停机早出现几天。事件层与状态层数据的价值就在于把「突然坏」变成「提前修」，运维从救火变成巡检。

4把数据用起来：一个 30 天的最小闭环

方法论讲完，给一个能直接照做的最小闭环——不追求精细，追求「每个月都转一圈」：

1. 第 1 周：看基线。导出近 30 天数据，记下各品类销量比例、时段分布、失败率，这就是这个点位的基线，先不改任何东西；
2. 第 2 周：砍尾。把长期垫底的一到两个品类撤下，释放料仓，观察补料工作量是否下降；
3. 第 3 周：试新。在空出的仓位上一个新品类，记下上架首周的曲线变化，与基线对比；
4. 第 4 周：复盘。新品转正还是撤下、补货班次要不要调、失败率有没有异常抬升，四个问题答完，进入下一个循环。

这个闭环的价值不在单次决策多准，而在口径稳定地积累：每一轮都沿用同样的统计口径，三个月后你手里的数据就足以回答「这个点位适合什么菜单」这种选型期最贵的问题。数据能力从来不是后台功能多不多，是有没有人按节奏用它。

5数据归属与导出：运营方拿到的应该是什么

「设备数据能导出给运营方吗」——能，而且应该。运营方购买的是设备与运营能力，点位维度的经营数据理应完整可见：后台看板按点位查看，导出为表格自行分析，是现制设备数据能力的合格线。要注意两点：一是导出的应当是聚合数据，不含任何个人信息（本来也没有）；二是数据口径要稳定——品类怎么归类、失败怎么计数，口径变了历史数据就不可比，厂商有义务把口径写进文档。

至于「饮品机数据会不会保存个人信息」：交互链路上，动作判断即用即弃，交易依赖支付平台完成，设备侧不落地个人身份信息。这也是为什么本文通篇讲的都是「杯」与「次」，而不是「人」。