t_payment_order_apply 不过滤 is_delete 最关键
技术侧异常导致历史正常申请被置为 Y，过滤会损失 ~50% 数据。t_payment_order 仍过滤 is_delete='N'。
基于观远BI真实数据 · 2026-06-08 · 48个知识文件已入库
若错误过滤 is_delete='N'，丢失 49.6% 的提现申请记录。 这是技术侧历史数据异常导致，修复中。
日常说"产品维度"默认用 sub_product_type， 来自 t_credit_apply，非 product_code。
| 字段 | 含义 | 示例值 |
|---|---|---|
| loan_principal | 合同本金 | 3,000,000 |
| service_fee | 服务费 | 108,000 |
| vat_amt | 增值税 | 11,880 |
| actual_received | 实际到账 | 2,880,120 |
验证：3,000,000 - 108,000 - 11,880 = 2,880,120 ✅ 精确
技术侧异常导致历史正常申请被置为 Y，过滤会损失 ~50% 数据。t_payment_order 仍过滤 is_delete='N'。
所有节点必须发生在注册当日。看 T7/T14/T30 需单独定义 cohort 窗口。
ocr_record=开始OCR → match_record=进入人脸 → state='Success'=最终成功。不可用 state='Success' 作为授信前置。
默认取 t_credit_apply.sub_product_type，非 product_code。订单侧通过 credit_id = apply_id 关联获取。
当前样本通过率 22.5%。按通过日统计时用 pass_time，非 created_time。
排除规则：有效提现排除 1/WAIT_SIGN_CONTRACT/DAILY_LOAN_LIMIT_REFUSE；支用排除 2-2/WITHDRAW_DECISION/7/8/3-1/3-2。
仅适用已放款订单。放款前节点无此字段。日放款表复贷行只承载放款成功。
5/8起不优先白名单，直接取 t_channel_info。渠道表最早 2026-03-24。
用户→设备/OCR/eKYC/授信 都需先压缩。统计人数明确去重字段，统计金额明确粒度。
授信阶段=apply_id，支用阶段=payment_order.order_id。历史补刷规则不套普通统计。
业务从库(实时) vs 开发库(SP加工后)。先确认库层级→刷新时间→Kettle/SP状态。
loan_amt(放款金额) ≠ loan_principal(合同本金) ≠ trans_amount(实际放款)。已数据验证。
安装设备数按 appsflyer_id 去重。当前营销复盘不从安装作为漏斗起点。
如需排除需业务确认后同步更新 T0、钉钉监控和所有相关 SQL。
①存旧版→②新版草稿→③确认后覆盖→④记录归档路径和回滚文件。