标签是“养”出来的：如何让沉睡数据变成消金公司的印钞机-程序员充电站

1. 撕开迷雾：消金业务的四层标签塔构建实战

做大数据的兄弟们都知道，标签这玩意儿，建起来容易，用起来难。很多公司搞了成百上千个标签，最后业务方只用“性别”和“年龄”，简直是资源的巨大浪费。在消费金融（消金）这个领域，钱是直接跟数据挂钩的，标签体系就是我们的作战地图。

咱们不整那些虚头巴脑的方法论，直接上干货。对于千万级用户的消金平台，我习惯把标签分为四层：基础属性（Fact）、行为特征（Action）、价值评估（Value）、风险预测（Risk）。这四层像盖楼一样，缺一层都会塌。

1. 基础属性层（Fact）：不仅仅是KYC

这一层是地基，主要来自用户的开户KYC数据、OCR识别结果和第三方征信数据。但注意，别把原始数据直接当标签。

原始数据：身份证号1101011990...
标签化：
- gender（性别）：不要只存男/女，要考虑到未知。
- age_group（年龄段）：消金风控对年龄极度敏感，建议切分为[22-25](职场新人/高风险),[26-35](黄金借贷期),[35-45](高净值/家庭负担重)。
- geo_tier（常驻地城市等级）：别只存“北京市”，要映射为“一线城市”。这直接影响授信额度。
- device_price_level（设备价值分层）：这是个很容易被忽略的强特征。用iPhone 15 Pro Max的用户和用千元安卓机的用户，逾期率在统计学上有显著差异。我们需要维护一个终端设备库，实时更新手机价格，映射为High,Medium,Low。

老司机经验：基础标签里要加一个“资料完善度”标签。很多用户注册了一半跑了，这类用户的召回策略和资料齐全的用户完全不同。

2. 行为特征层（Action）：捕捉“借钱的冲动”

这一层全是动态数据，主要源自埋点日志（Log）和交易流水。重点在于时效性和意图识别。

我们需要构建以下维度的标签：

App活跃度：
- last_login_time（最近一次登录时间）：T+0级别更新。
- visit_depth_7d（7日访问深度）：平均浏览页面数。如果是单纯只看“我的借款”页面的，目的性极强。
信贷意图（关键）：
- credit_click_cancel_cnt_30d（近30天点击授信但取消次数）：这人想借钱，但可能觉得利息高或者流程烦。这是运营介入的最佳时机。
- calculator_usage_cnt（费率计算器使用次数）：强烈的比价行为。
触达偏好：
- preferred_channel（偏好触达渠道）：Push点通率高？还是短信点击率高？别傻乎乎全发，浪费钱还招人烦。

3. 价值评估层（Value）：谁是你的金主爸爸

这里开始进入离线计算的深水区，通常用Hive跑批处理。

loan_balance_tier（在贷余额分层）：比如>5w,1w-5w,<1w。
total_interest_contribution（历史累计贡献利息）：这是实打实的利润贡献。
early_repayment_tendency（提前还款倾向）：注意！在消金里，特别喜欢提前还款的用户不一定是好用户，因为他们让我们赚不到后面的利息。给这类人打上标签，营销时要送“分期折扣券”而不是“免息券”。

4. 风险预测层（Risk）：生死线

消金的核心是风控。这部分标签通常由风控模型团队提供，数据团队负责特征工程和标签落库。

model_score_b（B卡评分）：申请评分卡，预测违约概率。
overdue_history（历史逾期标签）：
- M1_cnt（逾期30天以内次数）
- M2_cnt（逾期30-60天次数）
- ever_M3+（是否发生过90天以上逾期）：黑名单用户，直接熔断。
multi_platform_loan_cnt（多头借贷次数）：俗称“撸口子”。如果一个用户在7天内申请了10个网贷平台，这人极大概率要暴雷。

2. 跨越设备的幽灵：基于图计算的ID-Mapping OneID方案

搞定了标签定义，咱们得解决一个大数据领域最头疼的问题：“我是谁”。

在消金场景下，用户极其狡猾。他可能今天用iPhone借钱，明天用安卓备用机还款，后天在PC网页上查账，甚至为了躲避风控故意重置手机ID。如果我们不能把这些碎片化的ID串联成一个唯一的OneID（Global ID），那算出来的标签全是垃圾。

痛点分析：ID的碎片化

我们手里的标识符通常有这些：

Mac地址：乱七八糟，现在基本拿不到。
IMEI/IDFA/OAID：移动端设备指纹。Android 10以后限制很多，iOS更是把IDFA关了。
Phone：手机号，相对稳定，但存在换号、双卡情况。
Cookie/SessionID：Web端，生命周期极短。
AccountID：用户登录后的唯一标识（强ID）。

我们的目标是：只要这些设备或账号在某个时间点产生过关联，就把它们归一化为同一个自然人。

实战方案：基于Spark GraphX的连通图

别想着写一大堆if-else去匹配，数据量上千万的时候，必须上图计算（Graph Computing）。

Step 1: 构图（Edge Construction）

我们把每一个标识符（Phone, IMEI, Cookie, AccountID）看作图中的“点（Vertex）”。用户的一次行为，就是连接这些点的“边（Edge）”。

场景举例：

用户A在手机（IMEI_1）上用手机号（Phone_1）登录了账号（Account_1）。
- 产生边：IMEI_1 <--> Phone_1
- 产生边：Phone_1 <--> Account_1
第二天，用户A换了手机（IMEI_2），用同一个手机号（Phone_1）登录。
- 产生边：IMEI_2 <--> Phone_1

Step 2: 连通分量计算（Connected Components）

这时候，IMEI_1,Phone_1,Account_1,IMEI_2这四个点虽然没有直接全部两两相连，但通过Phone_1这个中间点，它们构成了一个连通子图。

我们要做的，就是用 Spark GraphX 的connectedComponents()算法，把这个子图里所有的点都打上同一个 ID —— 这就是OneID。

代码逻辑伪代码（Scala风格）：

// 1. 加载所有关联关系日志 // 格式：(src_id, src_type, dst_id, dst_type, timestamp) val relationships = spark.read.parquet("/dw/dwd/log_login/...") // 2. 构建点和边 // 注意：为了避免ID冲突，通常给ID加前缀，如 "phone_1380000" val vertices = relationships.flatMap(r => Seq( (r.src_id.hashCode.toLong, r.src_id), (r.dst_id.hashCode.toLong, r.dst_id) )).distinct() val edges = relationships.map(r => Edge(r.src_id.hashCode.toLong, r.dst_id.hashCode.toLong, "linked") ) // 3. 构建图 val graph = Graph(vertices, edges) // 4. 跑连通分量算法 val cc = graph.connectedComponents() // 5. 结果落表：每个原始ID对应一个 componentId (即 OneID) val oneIdMapping = vertices.join(cc.vertices).map{ case (vid, (originalId, oneId)) => (originalId, oneId) }

Step 3: ID-Mapping 的“坑”与优化

这里面有个巨大的坑，叫“超级节点（Super Node）”。

设想一下，如果有一个黄牛或者中介，用同一台手机（IMEI_X）帮1000个人注册了账号。或者是公司的测试手机，登录过几百个账号。

如果不做处理，这台IMEI_X会把这1000个互不相干的人强行拉成一个巨大的连通图，导致几千人的数据混在一起，标签完全失真。

解决方案：

黑名单机制：对连接数过多的节点（如连接超过50个账号的设备），直接剔除，不参与构图。
边权重衰减：给边加上时间属性。一年前的关联关系，权重降低。如果两个ID很久没有关联了，考虑断开边，分裂成两个OneID。

3. 掘金利器：金融版 RFM 模型与 LTV 预测

通用电商的RFM大家都会，但在消金领域，RFM的定义必须魔改。你不能照搬。

1. 金融 RFM 的重定义

R (Recency) - 近度：
- 传统电商：上次购物时间。
- 消金定义：距离上一次成功还款的时间或距离上一次提现的时间。
- 逻辑：刚刚还款的用户，资金回笼了，是再次营销借款的黄金窗口期（复贷）。刚刚提现的用户，近期资金需求已满足，不要骚扰。
F (Frequency) - 频度：
- 传统电商：购买次数。
- 消金定义：有效借款月数或循环授信使用频率。
- 逻辑：通过这个指标判断用户是“偶尔周转”还是“长期依赖”。长期依赖的用户贡献高，但风险也累积。
M (Monetary) - 额度（注意不是消费金额）：
- 传统电商：消费金额。
- 消金定义：日均在贷余额(Average Daily Balance, ADB)。
- 逻辑：消金公司赚的是利息。利息 = 本金 × 利率 × 时间。只有借得久、借得多，才是好客户。单纯借了10万第二天就还了，M值其实很低。

2. 基于RFM的用户分层策略

我们可以把用户划分为8个格子（2x2x2），但为了实战，我们通常简化为几类核心客群：

客群名称	RFM特征	业务话术	策略动作
高价值高风险	R高, F高, M高	"老油条，借得多还的慢"	维稳。不主动提额，密切监控负债率，防止坏账。
高价值低风险	R低, F中, M高	"优质金主，刚还完钱"	促复贷。发提额券，发免息券，诱导再次借款。
挽留客户	R远, F低, M中	"很久没来了"	召回。发送“您有一笔额度即将失效”短信。
羊毛党	R低, F低, M低	"借极少，蹭免息期"	降权。减少营销资源投入。

3. LTV（全生命周期价值）预测：算算他能让你赚多少钱

老板最喜欢看LTV。如果一个用户的获取成本（CAC）是500元，LTV预测只有300元，那这人注册一个亏一个。

怎么算？

对于存量老客户，直接统计历史贡献利润。

难点在于新客 LTV 预测。

建模思路（XGBoost回归）：

目标变量（Label）：用户未来360天的累计净利润。
特征变量（Features）：
- 基础：年龄、性别、城市等级。
- 征信：多头分、信用分。
- 早期行为：注册首日的App停留时长、点击次数、是否绑定信用卡。
模型训练：
- 取一年前注册的用户作为样本。
- 输入他们注册当天的特征。
- Target是他们随后一年的真实产出。
预测应用：
- 当一个新用户完成授信的那一刻，模型跑出Predicted_LTV。
- 如果Predicted_LTV<Channel_Cost（渠道成本），直接在广告端减少这类人群的投放出价（OCPC回传）。

4. 唯快不破：从 T+1 到 T+0 的实时标签进化

在传统的数仓架构里，标签通常是T+1更新的。也就是今晚跑批，明天早上你才能知道用户昨天做了什么。

但在消金场景下，T+1 约等于“尸体”。

场景A（风控阻断）：一个用户突然在半夜3点，在异地设备上，连续输错3次支付密码。如果你等第二天早上才打上“疑似盗号”的标签，钱早就被转走了。
场景B（实时营销）：用户刚刚结清了一笔大额贷款，额度恢复了。这时候是用户心理最轻松、也是最容易接受复贷的时候。必须在5秒内触发一条“恭喜您获得提额大礼包”的弹窗。等明天？黄花菜都凉了。

所以，我们需要构建一套实时标签工厂。

核心架构：Kafka + Flink + Redis/HBase

别被那些复杂的架构图忽悠了，实时标签的核心链路其实就一条：

APP埋点/业务库Binlog -> Kafka (消息队列) -> Flink (流计算) -> Redis (在线存储)

这里有几个关键的技术细节，全是坑，踩过才知道：

1. 状态管理（State）是灵魂

做实时标签最难的不是处理当前的一条数据，而是“跨时间窗口”的计算。比如标签：last_1h_login_fail_cnt（过去1小时登录失败次数）。

你不能每来一条数据就去查数据库，那样DB会被打挂。你必须利用 Flink 的KeyedState，把用户的中间状态存储在 Flink 本地（RocksDB）。

实战伪代码逻辑：

// KeyBy userId stream.keyBy(data -> data.getUserId()) .process(new KeyedProcessFunction() { // 定义一个State用来存计数 private ValueState<Integer> failCountState; public void processElement(LoginEvent event, Context ctx, Collector out) { // 获取当前状态 Integer currentCnt = failCountState.value(); if (event.isFail()) { currentCnt += 1; failCountState.update(currentCnt); // 核心：注册一个定时器，1小时后清理这个状态，或者利用滑动窗口 ctx.timerService().registerProcessingTimeTimer(System.currentTimeMillis() + 3600000); } // 实时输出标签更新 out.collect(new TagUpdate(event.getUserId(), "login_fail_1h", currentCnt)); } });

2. 存储选型：Redis 还是 HBase？

这是一个经典的吵架话题。在消金场景下，我的建议是混合双打：

Redis (Cluster模式)：存放高频、热点、强实时的标签。比如“当前地理位置”、“今日剩余授信额度”。
- 优点：快，毫秒级响应。
- 缺点：贵，内存有限。
HBase / Doris：存放全量、历史标签。比如“历史逾期记录”、“常驻地省份”。
- 优点：便宜，能存海量数据。

实时与离线的“Lambda架构”缝合

最痛苦的事情发生了：Flink 算出来的实时指标，和 Hive 跑出来的离线指标，数据对不上！比如total_loan_amount（累计借款金额）。Flink 算出来是 10000，Hive 算出来是 10005。

为了解决这个问题，我们通常采用“流批互补”策略：

T+0 实时流：负责计算“当天的增量”。
T+1 离线批：每天凌晨，用 Hive 的全量准确数据，去覆盖Redis 里的昨日数据。

这就好比记账，白天用脑子记个大概（实时），晚上回家一定要翻开账本对一遍（离线修正）。

5. 标签也会“腐烂”：构建硬核的质量监控体系

很多团队标签上线了就不管了。结果过了半年，发现某个核心模型的KS值（区分度）暴跌，查了三天三夜才发现，是因为某个上游系统的字段改名了，导致“是否有房产”这个标签，半年前就开始全是Null了。

标签质量监控，是数据资产的保命符。我们主要监控三个维度：

1. 覆盖率（Coverage）：别让标签空着

这是最基础的。公式：有值用户数 / 总活跃用户数。

监控策略：配置阈值告警。
- 比如gender标签，覆盖率应该是 99% 以上（除了极少数未实名）。如果某天突然掉到了 80%，立刻报警。
- 对于has_car这种稀疏标签，覆盖率可能只有 10%，如果突然涨到 50%，也要报警——可能是数据源搞错了，把“没车”的也算成“有车”了。

2. 稳定性（Stability）与 PSI 指标

这是风控模型最怕的。群体稳定性指标（PSI - Population Stability Index）是衡量标签分布是否发生剧烈偏移的神器。

场景：昨天：信用分>700的用户占比 20%。今天：信用分>700的用户占比突然变成了 60%。

这时候 PSI 会飙升。这通常意味着：

前端流量突变：渠道放水了，或者被羊毛党攻击了。
数据Bug：计算逻辑错了。

PSI 计算公式不用死记，大概逻辑是比较“预期分布（昨天）”和“实际分布（今天）”的差异。

PSI < 0.1：标签很稳，放心用。
PSI 0.1 - 0.25：有波动，需关注。
PSI > 0.25：红色警报！必须暂停模型调用，否则会造成大量误杀或漏放。

3. 准确率（Accuracy）：最难的验证

你怎么知道你打的标签是对的？比如你给用户打标is_pregnant（由于敏感性，现在一般不打这个，这里仅作举例说明原理），怎么验证？

我们通常采用“抽样回访” + “逻辑互斥验证”：

逻辑互斥：如果一个用户同时拥有student（在校大学生）和senior_manager（高级经理）标签，这显然是逻辑冲突的。写脚本定期扫描这种互斥规则。
抽样回访：对于关键的高价值标签（比如“有装修需求”），客服团队在电销时，侧面询问验证，把结果反馈给数据团队进行修正。

6. 最后一公里：标签服务化与 Bitmap 高速筛选

标签造出来了，怎么给业务用？如果业务方每次想找人都要写一段 500 行的 SQL，那这系统就废了。

我们需要提供两种服务模式：

1. 在线查询服务（Query Service）

给 APP 或风控系统用的。接口：getProfile(userId)性能要求：TP99 < 20ms。后端实现：直接查 Redis Cluster 或者 HBase 的 RowKey。

2. 人群圈选服务（Audience Selection）

这是给运营（Marketing）用的。他们会提出这种变态需求：

“给我找出：在北京、年龄25-30岁、近30天有过借款行为、且手机是iPhone的用户，马上要！”

如果你用 MySQL 或者 Hive 去JOIN四张表，千万级数据量直接跑死。这时候，Bitmap（位图）技术就是救世主。

原理：把每个标签的值，转换成一个二进制的位图（010101...）。

用户ID=1，在北京，那就是第1位是1。
用户ID=2，不在北京，那就是第2位是0。

ClickHouse或Doris这种现代 OLAP 数据库，都内置了RoaringBitmap。当你做人群交集（AND）、并集（OR）时，本质上是在做位运算。计算机做位运算的速度，比做传统的 Table Scan 快几万倍。

实测效果：在 5000 万用户中，筛选 10 个标签组合的人群，用 MySQL 可能要跑 10 分钟（甚至超时），用 ClickHouse 的 Bitmap 只需要200毫秒。

运营人员在后台拖拽标签，瞬间就能看到受众人数，点一下“发送短信”，整个流程极其丝滑。

7. 数据炼金术：高价值推断类标签的开发实战

事实数据是廉价的，经过算法加工的推断数据才是资产。

在消金领域，我们最想知道用户的三个核心隐私：真有钱吗？（还款能力）、在哪上班？（稳定性）、由于什么借钱？（动机）。用户填写的资料通常全是水分，我们需要用侧面数据去“逼近”真相。

1. 基于 LBS 的“职住分离”收入估算模型

用户填写的“月入 5 万”，大概率是吹牛。但他的 GPS 轨迹不会撒谎。

逻辑核心：利用用户授权的 GPS 经纬度数据，通过时间聚类算法，识别出“家”和“公司”。

职住识别算法：
- Home（家）：取22:00 - 06:00出现频率最高的 Geohash 网格。
- Work（公司）：取09:00 - 18:00（工作日）出现频率最高，且与 Home 距离大于 1km 的网格。
价值映射（Map Data）：
- 将Work坐标与第三方房价库/写字楼等级库匹配。
- 如果某用户的工作地点在“北京国贸三期”或“深圳南山科技园”，且连续 3 个月打卡正常，他的推断收入等级直接拉到Level_A。
- 如果工作地点在某些高风险区域（如老旧批发市场、疑似传销高发区），风控标签直接打上Warning。

代码实现思路（伪SQL）：

-- 这里的核心是剔除噪点，别把某次去酒吧的坐标当成家 SELECT user_id, geohash, COUNT(*) as dwell_cnt, -- 区分时段 CASE WHEN hour(event_time) BETWEEN 22 AND 6 THEN 'HOME_CANDIDATE' WHEN hour(event_time) BETWEEN 9 AND 18 THEN 'WORK_CANDIDATE' END as location_type FROM app_gps_log WHERE date >= date_sub(current_date, 30) -- 取近30天 GROUP BY user_id, geohash, location_type HAVING dwell_cnt > 10 -- 降噪阈值

2. 这里的“含贷量”超标：App List 竞争分析

Android 手机通常可以获取已安装 App 列表（需合规授权）。这是判断用户“饥渴程度”的核武器。

我们需要构建一个庞大的App 分类知识库，将市面上的 App 打标：

A类：头部消金/助贷（借呗、微粒贷、360借条）。
B类：高利贷/714高炮马甲包（这类App通常名字很怪，生命周期短）。
C类：赌博/博彩类（高危！）。
D类：高端消费（山姆会员店、星巴克、航旅纵横）。

衍生标签设计：

competitor_app_cnt（竞品安装数量）：如果装了超过 10 个借贷 App，说明他在“拆东墙补西墙”，多头借贷风险极高。
gambling_app_installed（是否有涉赌 App）：一票否决。
high_net_worth_app_ratio（高净值 App 占比）：如果用户手机里同时有“招商银行掌上生活”和“航旅纵横”，且没有借贷 App，这是白名单优质客户。

3. 社交网络图谱（SNA）：揪出“团伙作案”

以前我们讲了 ID-Mapping，那是为了识别“一个人”。现在我们要用图计算识别“一群人”。黑产中介通常会组织一群老头老太太，或者大学生，集中在同一个 WiFi 下，或者填写同一个虚假公司的电话进行骗贷。

构建同人/担保关系网络：

节点（Vertex）：用户ID、联系人手机号、公司电话。
边（Edge）：属于（User -> Contact）、同事（User A & User B 填了同一个公司电话）。

核心标签——PageRank 风险传导：如果一个用户的通讯录里，有 5 个联系人已经是我们的黑名单逾期用户，哪怕这个用户本身信用分很高，我们也通过Risk_PageRank算法，把黑名单的“毒性”传导给他。

标签名：black_list_contact_ratio（黑名单联系人占比）。

8. 拒绝“数据沼泽”：标签治理与生命周期管理

很多公司的标签库最后变成了垃圾场：几千个标签，没人知道是啥意思，没人敢删，跑批任务每天烧掉几万块钱云资源，最后业务方还在喊“缺标签”。

要避免这种情况，必须建立标签治理制度。

1. 标签的“生老病死”机制

标签不能只生不死。我们给每个标签强制设定生命周期属性：

TTL（Time To Live）：
- 行为标签（如“近7天浏览”）：数据过期自动清零。
- 偏好标签（如“母婴人群”）：如果用户连续 6 个月没有母婴相关行为，该标签自动衰减直至从 User Profile 中移除。不要让一个孩子已经上小学的用户，还挂着“孕期”的标签。
冷热分级与下线机制：
- 建立标签调用日志监控。
- 热标签（日均调用 > 10w）：放入 Redis Cluster，专人维护，SLA 99.99%。
- 温标签（周均调用 > 10）：降级存入 HBase/ES。
- 僵尸标签（近 90 天无调用）：发送下线预警邮件给标签负责人（Owner）。如果在 2 周内无人认领或申诉，自动停止计算任务，并从元数据中打上Deprecate标记。这是给计算资源止血的最有效手段。

2. 标签字典（Data Dictionary）与元数据管理

不要把标签含义写在 Wiki 里，Wiki 永远是过期的。要建立在线的标签元数据中心。

一个合格的标签注册信息必须包含：

Tag Name:is_overdue_M1
Business Definition: 当前在贷订单中，任意一笔逾期天数在 [1, 30] 区间内。
Technical Logic:sum(case when due_days between 1 and 30 then 1 else 0 end) > 0
Update Frequency: T+1
Owner: 贷后风控组-张三
Source Table:ods_loan_repayment_detail

只有注册了元数据的标签，才允许上线进入生产环境。

9. 带着镣铐跳舞：隐私计算与合规红线

在金融领域，数据安全大于天。《个人信息保护法》（PIPL）出台后，以前那种“裸奔”的数据使用方式就是找死。

1. 物理隔离与“可用不可见”

敏感数据加密：
- mobile、id_card、name在落库底层数仓（ODS层）的那一刻，必须经过Hash + Salt（加盐）处理。
- 开发人员在做 ETL 开发时，只能看到8f7b...这种乱码，无法反推真实手机号。
- 只有在最后触达发送短信的环节，通过特权的解密网关进行调用。

2. 联邦学习（Federated Learning）的应用

这在消金的联合建模中非常流行。场景：你想用某电商平台的数据来判断用户的购买力，但电商平台不可能把核心用户数据传给你，你也不可能把借贷数据传给它。

解决方案：双方不出库原始数据，只交换加密后的模型梯度（Gradient）。

你在本地训练风控模型的一部分。
电商平台在本地训练特征模型的一部分。
通过联邦学习协议，共同迭代出一个更准的模型。

这能让你在不触犯隐私法规的前提下，用上外部的高价值数据标签。

实战彩蛋：如何处理“空值”？

在模型训练时，标签的NULL值处理是门艺术。

数值型：千万别无脑填0。
- loan_balance（在贷余额）为空，可以填 0。
- age（年龄）为空，填 0 会毁了模型。建议填-1或者平均值，或者单独作为一个Unknown类别。
分类型：
- gender缺失，不要瞎猜，单独建一个gender_unknown组。有时候，“不愿意透露性别”本身就是一种风险特征。

10. 进攻之战：双11“临时额度”的精准突袭

双11是电商的狂欢，也是消金的修罗场。所有平台都在抢用户的钱包。我们的目标很明确：让用户用我们的钱去剁手。

核心策略是发放“临时额度”。发多了风控兜不住，发少了用户去用竞品。

1. 战前准备（T-7）：圈选“潜力股”

在双11前一周，离线数仓（Hive）开始疯狂运转。我们需要找出那些“有消费欲望但额度刚好不够”的人。

核心标签组合策略：

基础门槛：risk_levelIN ('Low', 'Medium') —— 风控红线不能碰。
活跃度筛选：last_active_date<= 7 —— 僵尸户发了也没用。
额度饥渴度（关键）：credit_utilization_rate(额度使用率) > 80%。
- 逻辑：一个总额度 10000 的人，已经用了 8500，剩下 1500 买个大件都不够。这时候你给他加 5000 临额，转化率极高。
电商偏好：sms_ecommerce_keyword_cnt_30d(短信中含淘宝/京东关键词次数) > 5。

2. 战时响应（T+0）：毫秒级截流

到了双11当天，离线标签不够快了。这时候Flink 实时标签进场接管。

场景：用户打开了我们的 App，或者在电商收银台犹豫（表现为频繁切换 App）。

实时触发逻辑：

Event: 用户打开 App。
Check:
- realtime_locationNOT IN (高危风险区)
- device_id没有关联黑名单。
- today_login_count> 3 (反复确认额度，说明想买东西)。
Action:
- 如果符合上述条件，后端直接下发弹窗：“双11特权！5000元临时额度已到账，有效期24小时！”
- 注意：有效期24小时这个文案非常重要，利用“损失厌恶”心理逼单。

3. 效果复盘

实战数据显示，经过这套标签组合筛选出的用户，临额动支率（Take Rate）比随机发放提升了300%，且坏账率仅上升了 0.05%（在可控范围内）。

11. 防守之战：春节“失联”大潮下的催收分层

做消金的都怕过年。过年意味着：用户回老家换号、钱花光了没钱还、甚至故意赖账。催收资源是有限的（客服电话打不过来），我们必须把有限的兵力投放在最可能回款的人身上。

我们要把逾期用户分为三类，制定不同策略：

第一类：还款意愿强，但暂时遗忘（首贷户为主）

标签特征：
- is_first_overdue= 1 (首次逾期)
- historical_repayment_habit= 'Early' (历史习惯提前还款)
- connection_stability= 'High' (一直在常用设备登录)
策略：温情提醒。
- 不要打电话骚扰！发一条短信：“亲，过年忙忘了吧？您的账单今日到期，不仅影响征信，还会产生罚息哦。”
- 这类人回款率通常 > 80%。

第二类：有钱但不想还（老赖倾向）

标签特征：
- app_installed_gambling= 1 (有博彩嫌疑)
- multi_platform_loan_cnt> 10 (多头借贷)
- contact_invalid_ratio> 50% (通讯录里一半电话打不通)
策略：高压施压。
- 直接上预测式外呼（Predictive Dialing）。
- 利用relationship_graph(关系图谱) 找出他的紧急联系人，合法合规地进行侧面施压。

第三类：想还但没钱（困难户）

标签特征：
- income_trend= 'Decreasing' (收入推断下降)
- job_industry= 'Construction/Catering' (建筑/餐饮等受季节影响大的行业)
策略：延期/重组。
- 如果你逼他，他就破罐子破摔了。
- 话术：“先生，考虑到您是老客户，如果您今天能还 10%，剩下的我们可以帮您申请延期 7 天。” ——以小回款保大资产。

12. 向上管理：如何用 ROI 让老板闭嘴（或鼓掌）

辛辛苦苦搞了半年标签，怎么汇报？千万别说：“我们上线了 500 个标签，覆盖率 99%。” 老板不关心这个。

老板只关心：赚了多少钱？省了多少钱？

请直接甩出A/B Test 实验报告：

汇报模板（建议背诵）：

项目背景：针对存量用户提额场景。
实验设计：
对照组（Control）：沿用旧规则（仅基于还款记录提额）。
实验组（Test）：引入“职业稳定性”和“消费偏好”两个新标签模型。
数据结果：
营销响应率：实验组提升15%（标签帮我们要到了对的人）。
户均授信额度：提升2000元。
风险表现（MOB3逾期率）：实验组反而降低了0.2%（剔除了潜在高风险人群）。
结论：新标签体系预计每年为公司带来3000万的新增利息收入。

这才是CTO和CEO想听的汇报。