第一次分析实际在做哪几件事
这些步骤主要在欧宝体育的云端完成，手机负责上传本地文件、显示进度和接收完成通知。每一步都依赖上一步的结果，所以无法并行跳过。第一次之所以慢，是因为每一步都要面对全部历史数据。
数据清洗：先把不能用的数据挑出来
不同系统导出的数据格式往往不一致：日期写法不同，手机号有的带区号有的不带，商品名称有简称也有全称。此外还有测试账号、内部员工订单、已经退款的订单、明显异常的批量购买。清洗环节会统一格式，并把这些记录标记出来，不纳入球迷行为计算。数据越久远，这类问题通常越多。
清洗不是简单地删除。被标记的记录会保留在原始数据里，并在分析报告中列出数量和原因，运营人员可以复查。比如某批订单被判定为异常批量购买，实际上可能是企业团购，这时可以手动取消标记，下次分析时把它计入。
身份合并：同一个球迷可能有好几个账号
这是首次分析最耗时、也最重要的一步。同一个球迷，可能在票务系统里用手机号购票，在商城用另一个账号买球衣，在会员系统里登记的是会员卡号。如果不合并，他会被当成三个人：一个只买票的人、一个只买商品的人、一个只有会员身份的人，画像就完全失真。
合并时，系统要在所有账号之间两两比对手机号、会员卡绑定关系、收货信息等匹配线索，计算量随数据规模快速增长。对于匹配证据不充分的情况，欧宝体育App不会强行合并，而是列入“待确认”清单，由运营人员人工判断。清单里的项目越多，首次分析的完成时间越依赖人工处理进度。
合并也可能出错。一家人共用一个手机号购票，系统可能把父亲和孩子合并成一个球迷，画像里就会同时出现成人球衣和儿童周边的购买记录。欧宝体育App在合并结果里会标出这类行为差异明显的身份，建议优先人工查看。宁可少合并几个，也不要把不同的人错误地合在一起。
特征计算和分群训练：为什么要反复迭代
身份合并完成后，分析引擎按不同时间窗口计算每个球迷的观赛、购买和互动特征，比如最近一个月、一个赛季、全部历史。然后聚类模型开始分群训练：它需要多轮迭代，调整分群数量和边界，直到分群足够稳定、彼此区分清楚。关于分群为什么不是越细越好，可以参考球迷分群为什么不能无限细分。
之后为什么会快很多
首次分析完成后，清洗规则、身份合并关系和分群模型都已经建立。后续更新采用增量方式：只处理新增和发生变化的数据，新订单只需要匹配到已知球迷身份，只有受影响的特征需要重新计算，分群模型在原有基础上微调。所以同样的项目，日常更新通常比首次分析快得多。例外是大版本更新带来的特征定义变化，这时需要整体重算，具体可参考更新以后球迷画像没有同步怎么办。
为什么建议Wi-Fi、充电和后台运行
- Wi-Fi：如果数据是从手机本地文件导入，上传阶段需要持续稳定的网络；移动网络切换基站时可能中断上传，导致需要重新上传。
- 充电：上传和进度同步期间App需要保持网络连接，电量过低时系统可能限制后台网络活动。
- 后台运行：上传完成后，计算在云端继续，不需要一直停留在App前台。开启通知权限后，分析完成或出现待确认项时会收到提醒。
等待期间也不必空等。可以先处理身份合并的待确认清单，或者提前整理营销项目的目标和预算，等画像生成后直接选择受众。如果还有其他数据源要接入，最好一次接齐再开始分析，否则后接入的数据会触发又一轮身份合并。
哪里可能判断错误
最常见的误判是把“身份合并耗时长”当成“程序卡住”而取消任务。判断方法是查看任务详情里的已处理记录数，只要在增长就说明仍在运行。另一个误区是为了追求速度，在设置里关闭身份合并。这样确实更快，但画像中的球迷人数会被高估，购买和观赛特征会被拆散，后续的受众和预测都会建立在错误的基础上。
怎样验证首次分析的结果可信
分析完成后，先看分析报告里的合并摘要：原始账号数、合并后球迷数、待确认数量。如果合并比例和你对业务的了解差距很大，需要检查匹配规则。然后随机抽取十来位熟悉的老会员，查看他们的画像是否同时包含票务和商城记录。最后留意分群人数是否集中在一两个大群，这可能说明特征计算缺少了某个数据源。
