KYC 分析表 · 建表需求与埋点 TODO

00 这文档是什么、为什么这么做

KYC 是 Botim Pay 所有金融功能(转账、预付卡、充值)的强制前置。KYC 一旦走坏,下游收入就被卡住。现在我们在已提交申请上有服务端成功率(~50% 完成,去重),但看不到顶部漏斗的流失 —— 约 40% 进来的人根本没启动验证方式。这份文档把前端漏斗和服务端完成拼起来看清全貌,并推动三件事:

• ① Insight 洞察 —— 量化 KYC 在哪里、为什么走坏,按渠道和客户端组合(国家 / App 版本 / 小程序版本)。
• ② TODO 埋点整改 —— 可靠度量所需的埋点修复(前端有已知缺口)。
• ③ Create Table 建表 —— 计算这些指标的表层,围绕下面的 Bad KYC 定义。

00·b Bad KYC — 定义 DRAFT · 待研发确认

Bad KYC = 表现出真实意图但未达成服务端成功完成的尝试,排除纯用户取消。一个 session 满足全部条件即为 Bad KYC:

• 到达 KYC Verification Started(已表现意图),且
• 未到达服务端 Completed,且
• 失败归因于:系统 / SDK 错误、SDK 握手流失(UAE Pass 黑盒)、pending 长期未解决、审核拒绝、或非取消类流失。

排除(不算 Bad KYC):用户 Cancel、"只是看看"、从未开始、"暂时没带 EID"(会重试)。

指标: Bad KYC 率 = Bad KYC sessions / 到达 Verification Started 的 sessions,按渠道 × 客户端维度切。(session_id 上线后用 session 级;之前用 user 级。)

00·c KYC 订单全分解(MECE)

每个 KYC order 落在唯一一个桶 —— A + B + C + D = 100%:

变量: Entered = Flow Entered distinct uid(分母)· Started = Verification Started · KYC_passed = journey_flag=1 或 step IN ('DOWN','PRE_EID_EXPIRY') · Cancel = 用户取消(user-reject / give-up / not-comfortable,从 Bad KYC 剔除)· Audit_reject = tm_audit_task status=R。

审核漏斗(30d): 进审 2,016 → 拒绝 1,120(55.6%)/ 通过 886(44%);97% 由 CHANNEL_HINT_REVIEW 触发。拒绝原因 Top:Portrait Inspection Failed 66%、Document & ICP mismatch — expiry 17% / DOB 9%。

洞察: 两大损耗 = 无意图(~40%) + Bad KYC(~25%);人工审核(C)极小(月 ~2k 单)。Bad KYC 主要由 UAE Pass job check timeout + UAE KYC "EID not scanned" 构成。

01 表架构

logs_footprint_mp (原始 JSON)  +  kyc.* 服务端表
        │  拍平 / 解析
        ▼
  ① vew.kyc_event_flatten_di        DWD 拍平表(一行一事件)
        │  GROUP BY
        ▼
  ② ads_kyc_channel_funnel_di       分渠道成功漏斗
  ③ ads_kyc_failure_reason_di       失败原因
  ④ ads_kyc_leave_reason_di         流失原因
        +
  ⑤ dim_kyc_entry_point             意图 code → 业务名(可选)
        +
  ⑥ dwd_kyc_apply_di                服务端 apply 镜像(TiDB tm_kyc_apply)— 算 Bad KYC 必需

现在能算 Bad KYC 吗? Bad KYC 需要服务端 completion(is_passed),前端拍平表没有 —— 所以它来自 ⑥ dwd_kyc_apply_di(镜像 TiDB tm_kyc_apply)。服务端口径 Bad KYC(按 channel/天)= started − kyc_passed − cancel,建好 ⑥ 即可算。完整分解(含无意图 + 客户端筛选)还需 uid ↔ member_id join key(P0)。

02 三个渠道

每个渠道流程/页面不同,必须分渠道建漏斗 —— 同一事件不可跨渠道横比。

03 结果表

② 分渠道成功漏斗 — ads_kyc_channel_funnel_di(长表)

粒度:dt × channel × 组合维度 × funnel_step。指标:users(distinct uid;session 上线后改 distinct session)。

③ 失败原因 — ads_kyc_failure_reason_di

粒度:dt × channel × failure_source × failure_reason × 维度。来源:frontend_error(Error Type)、server_callback(错误码)、audit_reject(tm_audit_log.memo)、status_page(Page Code)。必须区分用户取消(Cancel) vs 系统错误。

④ 流失原因 — ads_kyc_leave_reason_di

粒度:dt × channel × leave_source × leave_page × leave_reason × 维度。主口径是 Exit Bottom sheet Viewed —— 不用 Leave 点击事件(多数用户直接关 App)。

03·b 各表 Schema 与示例数据

完整 DDL 见 analysis/schema-ddl.sql。②③④ 示例为示例量级(06-01 分布);error_code/server 值待研发确认。

① vew.kyc_event_flatten_di — DWD 拍平表(分区 dt · PARQUET)

业务字段: uid, event, entry_point, verification_type, kyc_flow_type, kyc_vendor, error_type, page_code, kyc_status, reason, page_dropped_from, cta_clicked, industry, renewal_flow, uri_path
客户端维度: client_version, mp_version, os_version, device_brand, device_model, device_type, net_type, language, region, uid_region, ip_region, ip_isp, event_ts + 分区 dt(均 STRING;event_ts BIGINT)

② vew.ads_kyc_channel_funnel_di — 分渠道漏斗(长表 · 分区 dt)

字段: channel, entry_point, kyc_flow_type, verification_type, client_version, mp_version, os_platform, region, net_type, step_order INT, step_name, users BIGINT, events BIGINT, dt

③ vew.ads_kyc_failure_reason_di — 失败原因(分区 dt)

字段: channel, failure_source, failure_reason, error_code, is_user_cancel BOOLEAN, entry_point, kyc_flow_type, verification_type, client_version, mp_version, region, users BIGINT, events BIGINT, dt

④ vew.ads_kyc_leave_reason_di — 流失原因(分区 dt)

字段: channel, leave_source, leave_page, leave_reason, entry_point, kyc_flow_type, client_version, mp_version, region, users BIGINT, dt

⑤ vew.dim_kyc_entry_point — 意图字典(无分区 · 可选)

字段: entry_point_code, entry_point_name, category, is_tech_source BOOLEAN, note

04 计数口径

1. 用 distinct users(session 上线后改 distinct session)—— 前端有 10–28% 双触发,事件量不可直接用。
2. 完成与错误以服务端为准 —— 前端 Completed 在跳转流程不触发。
3. 分渠道漏斗里程碑不同 —— 同一事件不可跨渠道比。
4. 流失用 Exit-sheet —— Leave 点击量严重偏低。
5. channel 从 step 1 起算(Verification Started),Flow Entered 时还未知 —— 顶部 Entered→Started 流失是全渠道口径。

05 埋点 TODO(给研发)

06 依赖 — 建表前需研发拍板

1. channel 判定规则:kyc_vendor + verification_type → 3 渠道。
2. signzy 的里程碑事件。
3. 服务端错误回调表(channel / error_code / member_id / 时间)。
4. 服务端完成口径(tm_kyc_apply 能否带 channel / entry_point)。
5. session_id 在服务端关联 member_id / apply。
6. Entry Point code → 业务名字典(归并 mp-ogold/mpogold、MANDATORY_KYC/_V2)。
7. UAEPASS 流失:服务端是否有记录(tr_leave_record 不含它)。