一个模拟场景：同一份销售数据，放错项目会得出什么结论
以下为模拟示例。某运动零售团队的运营同事拿到一份覆盖30家门店、约1200个SKU的周销售表，想看篮球品类最近的变化。他在App里随手新建了一个场馆项目，把表格导入进去。结果系统提示“缺少分区与场次信息”，生成的看板里大部分指标是空的，只剩一个按日期汇总的总销售额曲线。
他换成商品趋势项目重新导入，同样的数据立刻被识别为“门店 × SKU × 日期”的结构，系统自动按品类归并，并提示可以接入搜索热度数据做对照。两次导入的原始数据完全一样，差别只在于项目类型决定了系统用什么方式理解这份数据。
这个例子说明，项目类型不是一个可有可无的分类标签，而是后续所有计算的起点。系统需要先知道数据属于哪种业务结构，才能决定哪些列是维度、哪些列是度量、缺了哪些字段需要提醒你补充。跳过这一步，得到的往往不是“更简单的看板”，而是一张缺字段、口径混乱的报表，后面花在修正上的时间反而更多。
三类项目分别加载哪一套数据模型
BB体育App在创建项目时，会根据类型加载不同的数据结构和分析模型：
- 商品趋势项目：基本单位是SKU、款式和品类，时间粒度通常到日。主要调用Demand Model和Forecast Model，关注搜索、社交讨论、销量与趋势之间的先后关系。
- 供应链项目：基本单位是仓库、门店库存点和供应商，核心字段包括在途库存、补货周期、最小起订量。主要调用Supply Chain Analytics，计算Lead Time、安全库存和缺货风险。
- 场馆项目：基本单位是空间分区和活动场次，例如入口、大厅通道、座席区、餐饮点、零售点和停车场。主要调用Spatial Analytics、Consumer Analytics和Venue Intelligence，关注客流、停留和非票务收入。
三套模型对“一条数据”的理解方式不同。一笔交易在商品项目里是某个SKU的销量，在场馆项目里则是某个餐饮点在某场活动某个时段的消费，它需要挂靠到空间和场次上才有意义。
为什么同一个指标在不同项目里口径不一样
最常见的困惑来自“销量”“转化率”这类名字相同的指标。在商品项目中，转化率通常指搜索或浏览之后的购买比例；在场馆项目中，转化率更接近“进场观众中实际消费的人数比例”。如果允许在一个项目里随意混用，报表上两个同名数字放在一起，很容易被误读成同一件事。
因此App在项目创建时就锁定一套指标口径，并在每个指标旁标注计算方式。需要跨类型对比时，建议分别建项目，再通过项目关联功能引用对方的结果，而不是把所有数据塞进同一个项目。
权限跟着项目类型走，而不只是跟着账号走
项目类型还会影响默认的成员角色。商品趋势项目通常开放给商品、市场和电商团队，敏感度相对较低；供应链项目涉及采购成本、供应商条款，默认只有创建者和被邀请的供应链成员可以查看成本字段；场馆项目往往包含租户营业额、招商合同信息，默认把收入明细设为仅管理员可见。
也就是说，同一个账号在不同类型的项目里能看到的字段可能不同。这是有意为之的设计，避免一份商品看板被转发时顺带暴露了场馆租户的经营数据。
拿不准选哪一类时，先回答三个问题
- 你最终要做的决策是什么？决定上新、追单或下架哪些款，选商品趋势；决定补多少货、从哪个仓调拨，选供应链；决定场馆里的餐饮、零售、广告或招商怎么调整，选场馆。
- 你手上最完整的数据是按什么组织的？按SKU组织的偏商品，按库存点组织的偏供应链，按区域和场次组织的偏场馆。
- 谁会参与这个项目？如果主要成员是场馆运营和招商同事，即使讨论的是场馆零售商品，也更适合建场馆项目。
三个问题指向不同答案时，以第一个问题为准，决策目标比数据形态更重要。
选错了怎么办：转换、复制还是重建
如果项目刚建好、还没有做过人工修改，最省事的方式是删除后按正确类型重建。如果已经上传了数据并做了一些标注，可以使用“复制为其他类型”，系统会保留原始数据文件，但需要你重新确认字段映射，因为不同模型需要的字段不一样。
需要注意，复制时人工修改标注和版本记录不会跨类型迁移，因为它们依附于原模型的计算结果。已经在报告里写过判断的，建议先导出备份。
项目建好之后，建议先做这三步
第一步，检查字段映射。系统自动识别的列名不一定准确，尤其是“日期”“场次”“门店编码”这类字段，映射错了后面的趋势会整体偏移。第二步，设置对照基线，例如选定去年同期或最近四周均值作为参照。第三步，邀请成员并确认角色，避免后期再调整权限时出现字段可见性不一致的问题。
如果你的项目是商品类，下一步可以阅读怎么在App里查看搜索、销量和库存变化；想先了解App整体能做什么，可以回到BB体育App页面。AI模型给出的结果仍然需要人工复核，项目类型选对，只是让后续判断建立在正确的口径上。
