Product_A 全链路盈亏分析

要解决什么问题

Product_A 每月结算时，收入往往来自两套口径：旧方案（某指标 × 单价）与新方案（结算表 cost_gross）。同时要把 AppsFlyer 里的转化按产品线、Campaign 去重，再按 PID / Channel 分摊下游成本（阶梯价或 $1/conv），才能判断各渠道是赚是亏。手工拼表容易在 Tier 映射、双重去重和结算率敏感性上出错。

技能如何工作

技能围绕 ./scripts/revenue_audit.py 做全链路盈亏分析：

• 输入：AOS/iOS 的 AppsFlyer CSV（{package_name}_in-app-events_{start}_{end}_UTC.csv，且 Is Primary Attribution == True）与结算 xlsx（date, source, partner, tier, value_unit, quantity, cost_gross 等新格式列）。
• 核心逻辑：产品线 B 用 AF ID 最早事件去重；产品线 A 在 AF ID 去重后再对 Customer User ID 二次去重；PID 映射到 Channel 后，按方式 1（≤150 @ $4.5、>150 @ $5.5 并按 Channel 内占比分摊）或方式 2（$1/转化 × 结算率）算下游成本；收入以结算表 Tier / cost_gross 为准。
• 输出：带样式的 7 Sheet Excel（数据补充、收入对比、下游成本、盈亏总览、PID 维度、Channel 维度、产品线 A 在 50%/60% 结算率下的 Campaign 分析）。

典型流程：确认日期范围 → 定位 AF CSV 与结算 xlsx → 校验列名与映射 → 改脚本路径与参数 → 运行脚本并核对 Sheet 是否合理。

边界与注意点

• 结算表常缺高 Tier 或末 1～2 天数据，需与业务确认后再解读。
• 旧方案只覆盖部分收入，与成本对比前需统一币种（固定汇率需按结算周期更新）。
• 列名、阶梯成本、结算率或 PID→Channel 合并若变更，需改映射与脚本常量；merge 时 suffix 冲突要用 fillna 处理。