QBUS6600 Exploratory Data Analysis Project - Future Financial Value|先把每位会员压成一行
🧭 合表前先定一行代表谁
P1 后面要解释的是会员的未来财务价值,所以分析表的一行要稳定地代表一名会员。members 与训练标签已经接近这个粒度,attendance、sales、bookings 记录的却是刷卡、销售明细和预订事件。同一个人出现多次很正常;直接按 HashID 横向连接,次数就会相乘。
🧪 假设某位会员有 3 条 attendance 和 2 条 sales。两张明细表直接连接会形成 6 行,未来收入标签也跟着复制 6 次。活动记录较多的会员因此多出几票,均值、相关关系和分组图都会继承这份额外权重。
这个错误很隐蔽:每列都有值,代码也不会报警。等你比较分组均值时,活动频繁的人已经因明细较多获得更大权重,图形回答的对象也从会员变成了连接组合。
💥 分析单位一旦从「每名会员」滑成「每条连接组合」,后面的计算就换了分母。
🕒 时间先停在预测切点
会员粒度定下来以后,接着卡住 T0 = 2024-07-19 00:00:00。时间边界决定哪些信息在预测时已经知道,也决定一个空白代表未知结果,还是已经发生但没有记录。
- sales 按
RaisedDate判断交易发生时间,再用Amount × Quantity整理金额。 - bookings 分开 T0 前已经创建的预订意图,以及 T0 前已经开始、结果也已知的活动。
- T0 后才开始的活动保留未知状态,不把空白
AttendedInd写成未出席,也不把Price当作已实现收入。
📌 比如一笔预订在 T0 前创建,活动安排在 T0 后。预测时可以知道这名会员有预订意图,当时还不知道活动结果。把两件事拆开,特征就不会偷看未来。
如果还要做 30、90 或 365 天窗口,都从 T0 往前数,并在报告里交代选择依据。换一个相邻窗口复算,可以检查主要关系会不会被单一阈值推着走。
🧱 三张事件表各自压成会员级
时间过滤完成后,再做各表内部聚合。三张表的一行含义不同,整理动作也要分别设计:
| 数据对象 |
|---|






