核心内容摘要
Witchcraft核心概念解析：从Functor到Monad的完整入门
撕开迷雾消金业务的四层标签塔构建实战做大数据的兄弟们都知道标签这玩意儿建起来容易用起来难。
很多公司搞了成百上千个标签最后业务方只用“性别”和“年龄”简直是资源的巨大浪费。
在消费金融消金这个领域钱是直接跟数据挂钩的标签体系就是我们的作战地图。
咱们不整那些虚头巴脑的方法论直接上干货。
对于千万级用户的消金平台我习惯把标签分为四层基础属性Fact、行为特征Action、价值评估Value、风险预测Risk。
这四层像盖楼一样缺一层都会塌。
基础属性层Fact不仅仅是KYC这一层是地基主要来自用户的开户KYC数据、OCR识别结果和第三方征信数据。
但注意别把原始数据直接当标签。
原始数据身份证号
..标签化gender性别不要只存男/女要考虑到未知。
age_group年龄段消金风控对年龄极度敏感建议切分为[
](职场新人/高风险),[
](黄金借贷期),[
](高净值/家庭负担重)。
geo_tier常驻地城市等级别只存“北京市”要映射为“一线城市”。
这直接影响授信额度。
device_price_level设备价值分层这是个很容易被忽略的强特征。
用iPhone 15 Pro Max的用户和用千元安卓机的用户逾期率在统计学上有显著差异。
我们需要维护一个终端设备库实时更新手机价格映射为High,Medium,Low。
老司机经验基础标签里要加一个“资料完善度”标签。
很多用户注册了一半跑了这类用户的召回策略和资料齐全的用户完全不同。
行为特征层Action捕捉“借钱的冲动”这一层全是动态数据主要源自埋点日志Log和交易流水。
重点在于时效性和意图识别。
我们需要构建以下维度的标签App活跃度last_login_time最近一次登录时间T0级别更新。
visit_depth_7d7日访问深度平均浏览页面数。
如果是单纯只看“我的借款”页面的目的性极强。
信贷意图关键credit_click_cancel_cnt_30d近30天点击授信但取消次数这人想借钱但可能觉得利息高或者流程烦。
这是运营介入的最佳时机。
calculator_usage_cnt费率计算器使用次数强烈的比价行为。
触达偏好preferred_channel偏好触达渠道Push点通率高还是短信点击率高别傻乎乎全发浪费钱还招人烦。
价值评估层Value谁是你的金主爸爸这里开始进入离线计算的深水区通常用Hive跑批处理。
loan_balance_tier在贷余额分层比如5w,1w-5w,1w。
total_interest_contribution历史累计贡献利息这是实打实的利润贡献。
early_repayment_tendency提前还款倾向注意在消金里特别喜欢提前还款的用户不一定是好用户因为他们让我们赚不到后面的利息。
给这类人打上标签营销时要送“分期折扣券”而不是“免息券”。
风险预测层Risk生死线消金的核心是风控。
这部分标签通常由风控模型团队提供数据团队负责特征工程和标签落库。
model_score_bB卡评分申请评分卡预测违约概率。
overdue_history历史逾期标签M1_cnt逾期30天以内次数M2_cnt逾期
天次数ever_M3是否发生过90天以上逾期黑名单用户直接熔断。
multi_platform_loan_cnt多头借贷次数俗称“撸口子”。
如果一个用户在7天内申请了10个网贷平台这人极大概率要暴雷。
跨越设备的幽灵基于图计算的ID-Mapping OneID方案搞定了标签定义咱们得解决一个大数据领域最头疼的问题“我是谁”。
在消金场景下用户极其狡猾。
他可能今天用iPhone借钱明天用安卓备用机还款后天在PC网页上查账甚至为了躲避风控故意重置手机ID。
如果我们不能把这些碎片化的ID串联成一个唯一的OneIDGlobal ID那算出来的标签全是垃圾。
痛点分析ID的碎片化我们手里的标识符通常有这些Mac地址乱七八糟现在基本拿不到。
IMEI/IDFA/OAID移动端设备指纹。
Android 10以后限制很多iOS更是把IDFA关了。
Phone手机号相对稳定但存在换号、双卡情况。
Cookie/SessionIDWeb端生命周期极短。
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_1Step 2: 连通分量计算Connected Components这时候IMEI_1,Phone_1,Account_1,IMEI_2这四个点虽然没有直接全部两两相连但通过Phone_1这个中间点它们构成了一个连通子图。
我们要做的就是用 Spark GraphX 的connectedComponents()算法把这个子图里所有的点都打上同一个 ID —— 这就是OneID。
代码逻辑伪代码Scala风格//
加载所有关联关系日志 // 格式(src_id, src_type, dst_id, dst_type, timestamp) val relationships spark.read.parquet(/dw/dwd/log_login/...) //
构建点和边 // 注意为了避免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) ) //
构建图 val graph Graph(vertices, edges) //
跑连通分量算法 val cc graph.connectedComponents() //
结果落表每个原始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。
掘金利器金融版 RFM 模型与 LTV 预测通用电商的RFM大家都会但在消金领域RFM的定义必须魔改。
你不能照搬。
金融 RFM 的重定义R (Recency) - 近度传统电商上次购物时间。
消金定义距离上一次成功还款的时间或距离上一次提现的时间。
逻辑刚刚还款的用户资金回笼了是再次营销借款的黄金窗口期复贷。
刚刚提现的用户近期资金需求已满足不要骚扰。
F (Frequency) - 频度传统电商购买次数。
消金定义有效借款月数或循环授信使用频率。
逻辑通过这个指标判断用户是“偶尔周转”还是“长期依赖”。
长期依赖的用户贡献高但风险也累积。
M (Monetary) - 额度注意不是消费金额传统电商消费金额。
消金定义日均在贷余额(Average Daily Balance, ADB)。
逻辑消金公司赚的是利息。
利息 本金 × 利率 × 时间。
只有借得久、借得多才是好客户。
单纯借了10万第二天就还了M值其实很低。
基于RFM的用户分层策略我们可以把用户划分为8个格子2x2x2但为了实战我们通常简化为几类核心客群客群名称RFM特征业务话术策略动作高价值高风险R高, F高, M高老油条借得多还的慢维稳。
不主动提额密切监控负债率防止坏账。
高价值低风险R低, F中, M高优质金主刚还完钱促复贷。
发提额券发免息券诱导再次借款。
挽留客户R远, F低, M中很久没来了召回。
发送“您有一笔额度即将失效”短信。
羊毛党R低, F低, M低借极少蹭免息期降权。
减少营销资源投入。
LTV全生命周期价值预测算算他能让你赚多少钱老板最喜欢看LTV。
如果一个用户的获取成本CAC是500元LTV预测只有300元那这人注册一个亏一个。
怎么算对于存量老客户直接统计历史贡献利润。
难点在于新客 LTV 预测。
建模思路XGBoost回归目标变量Label用户未来360天的累计净利润。
特征变量Features基础年龄、性别、城市等级。
征信多头分、信用分。
早期行为注册首日的App停留时长、点击次数、是否绑定信用卡。
模型训练取一年前注册的用户作为样本。
输入他们注册当天的特征。
Target是他们随后一年的真实产出。
预测应用当一个新用户完成授信的那一刻模型跑出Predicted_LTV。
如果Predicted_LTVChannel_Cost渠道成本直接在广告端减少这类人群的投放出价OCPC回传。
唯快不破从 T1 到 T0 的实时标签进化在传统的数仓架构里标签通常是T1更新的。
也就是今晚跑批明天早上你才能知道用户昨天做了什么。
但在消金场景下T1 约等于“尸体”。
场景A风控阻断一个用户突然在半夜3点在异地设备上连续输错3次支付密码。
如果你等第二天早上才打上“疑似盗号”的标签钱早就被转走了。
场景B实时营销用户刚刚结清了一笔大额贷款额度恢复了。
这时候是用户心理最轻松、也是最容易接受复贷的时候。
必须在5秒内触发一条“恭喜您获得提额大礼包”的弹窗。
等明天黄花菜都凉了。
所以我们需要构建一套实时标签工厂。
核心架构Kafka Flink Redis/HBase别被那些复杂的架构图忽悠了实时标签的核心链路其实就一条APP埋点/业务库Binlog - Kafka (消息队列) - Flink (流计算) - Redis (在线存储)这里有几个关键的技术细节全是坑踩过才知道
状态管理State是灵魂做实时标签最难的不是处理当前的一条数据而是“跨时间窗口”的计算。
比如标签last_1h_login_fail_cnt过去1小时登录失败次数。
你不能每来一条数据就去查数据库那样DB会被打挂。
你必须利用 Flink 的KeyedState把用户的中间状态存储在 Flink 本地RocksDB。
实战伪代码逻辑// KeyBy userId stream.keyBy(data - data.getUserId()) .process(new KeyedProcessFunction() { // 定义一个State用来存计数 private ValueStateInteger 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()
; } // 实时输出标签更新 out.collect(new TagUpdate(event.getUserId(), login_fail_1h, currentCnt)); } });
存储选型Redis 还是 HBase这是一个经典的吵架话题。
在消金场景下我的建议是混合双打Redis (Cluster模式)存放高频、热点、强实时的标签。
比如“当前地理位置”、“今日剩余授信额度”。
优点快毫秒级响应。
缺点贵内存有限。
HBase / Doris存放全量、历史标签。
比如“历史逾期记录”、“常驻地省份”。
优点便宜能存海量数据。
实时与离线的“Lambda架构”缝合最痛苦的事情发生了Flink 算出来的实时指标和 Hive 跑出来的离线指标数据对不上 比如total_loan_amount累计借款金额。
Flink 算出来是 10000Hive 算出来是 10005。
为了解决这个问题我们通常采用“流批互补”策略T0 实时流负责计算“当天的增量”。
T1 离线批每天凌晨用 Hive 的全量准确数据去覆盖Redis 里的昨日数据。
这就好比记账白天用脑子记个大概实时晚上回家一定要翻开账本对一遍离线修正。
标签也会“腐烂”构建硬核的质量监控体系很多团队标签上线了就不管了。
结果过了半年发现某个核心模型的KS值区分度暴跌查了三天三夜才发现是因为某个上游系统的字段改名了导致“是否有房产”这个标签半年前就开始全是Null了。
标签质量监控是数据资产的保命符。
我们主要监控三个维度
覆盖率Coverage别让标签空着这是最基础的。
公式有值用户数 / 总活跃用户数。
监控策略配置阈值告警。
比如gender标签覆盖率应该是 99% 以上除了极少数未实名。
如果某天突然掉到了 80%立刻报警。
对于has_car这种稀疏标签覆盖率可能只有 10%如果突然涨到 50%也要报警——可能是数据源搞错了把“没车”的也算成“有车”了。
稳定性Stability与 PSI 指标这是风控模型最怕的。
群体稳定性指标PSI - Population Stability Index是衡量标签分布是否发生剧烈偏移的神器。
场景 昨天信用分700的用户占比 20%。
今天信用分700的用户占比突然变成了 60%。
这时候 PSI 会飙升。
这通常意味着前端流量突变渠道放水了或者被羊毛党攻击了。
数据Bug计算逻辑错了。
PSI 计算公式不用死记大概逻辑是比较“预期分布昨天”和“实际分布今天”的差异。
PSI
1标签很稳放心用。
PSI
1 -
25有波动需关注。
PSI
25红色警报必须暂停模型调用否则会造成大量误杀或漏放。
准确率Accuracy最难的验证你怎么知道你打的标签是对的 比如你给用户打标is_pregnant由于敏感性现在一般不打这个这里仅作举例说明原理怎么验证我们通常采用“抽样回访” “逻辑互斥验证”逻辑互斥如果一个用户同时拥有student在校大学生和senior_manager高级经理标签这显然是逻辑冲突的。
写脚本定期扫描这种互斥规则。
抽样回访对于关键的高价值标签比如“有装修需求”客服团队在电销时侧面询问验证把结果反馈给数据团队进行修正。
最后一公里标签服务化与 Bitmap 高速筛选标签造出来了怎么给业务用 如果业务方每次想找人都要写一段 500 行的 SQL那这系统就废了。
我们需要提供两种服务模式
在线查询服务Query Service给 APP 或 风控系统 用的。
接口getProfile(userId)性能要求TP99 20ms。
后端实现直接查 Redis Cluster 或者 HBase 的 RowKey。
人群圈选服务Audience Selection这是给运营Marketing用的。
他们会提出这种变态需求“给我找出在北京、年龄
岁、近30天有过借款行为、且手机是iPhone的用户马上要”如果你用 MySQL 或者 Hive 去JOIN四张表千万级数据量直接跑死。
这时候Bitmap位图技术就是救世主。
原理 把每个标签的值转换成一个二进制的位图
..。
用户ID1在北京那就是第1位是1。
用户ID2不在北京那就是第2位是0。
ClickHouse或Doris这种现代 OLAP 数据库都内置了RoaringBitmap。
当你做人群交集AND、并集OR时本质上是在做位运算。
计算机做位运算的速度比做传统的 Table Scan 快几万倍。
实测效果 在 5000 万用户中筛选 10 个标签组合的人群用 MySQL 可能要跑 10 分钟甚至超时用 ClickHouse 的 Bitmap 只需要200毫秒。
运营人员在后台拖拽标签瞬间就能看到受众人数点一下“发送短信”整个流程极其丝滑。
数据炼金术高价值推断类标签的开发实战事实数据是廉价的经过算法加工的推断数据才是资产。
在消金领域我们最想知道用户的三个核心隐私真有钱吗还款能力、在哪上班稳定性、由于什么借钱动机。
用户填写的资料通常全是水分我们需要用侧面数据去“逼近”真相。
基于 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天 GROUP BY user_id, geohash, location_type HAVING dwell_cnt 10 -- 降噪阈值
这里的“含贷量”超标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这是白名单优质客户。
社交网络图谱SNA揪出“团伙作案”以前我们讲了 ID-Mapping那是为了识别“一个人”。
现在我们要用图计算识别“一群人”。
黑产中介通常会组织一群老头老太太或者大学生集中在同一个 WiFi 下或者填写同一个虚假公司的电话进行骗贷。
构建同人/担保关系网络节点Vertex用户ID、联系人手机号、公司电话。
边Edge属于User - Contact、同事User A User B 填了同一个公司电话。
核心标签——PageRank 风险传导 如果一个用户的通讯录里有 5 个联系人已经是我们的黑名单逾期用户哪怕这个用户本身信用分很高我们也通过Risk_PageRank算法把黑名单的“毒性”传导给他。
标签名black_list_contact_ratio黑名单联系人占比。
拒绝“数据沼泽”标签治理与生命周期管理很多公司的标签库最后变成了垃圾场几千个标签没人知道是啥意思没人敢删跑批任务每天烧掉几万块钱云资源最后业务方还在喊“缺标签”。
要避免这种情况必须建立标签治理制度。
标签的“生老病死”机制标签不能只生不死。
我们给每个标签强制设定生命周期属性TTLTime To Live行为标签如“近7天浏览”数据过期自动清零。
偏好标签如“母婴人群”如果用户连续 6 个月没有母婴相关行为该标签自动衰减直至从 User Profile 中移除。
不要让一个孩子已经上小学的用户还挂着“孕期”的标签。
冷热分级与下线机制建立标签调用日志监控。
热标签日均调用 10w放入 Redis Cluster专人维护SLA
9
99%。
温标签周均调用 10降级存入 HBase/ES。
僵尸标签近 90 天无调用发送下线预警邮件给标签负责人Owner。
如果在 2 周内无人认领或申诉自动停止计算任务并从元数据中打上Deprecate标记。
这是给计算资源止血的最有效手段。
标签字典Data Dictionary与元数据管理不要把标签含义写在 Wiki 里Wiki 永远是过期的。
要建立在线的标签元数据中心。
一个合格的标签注册信息必须包含Tag Name:is_overdue_M1Business Definition: 当前在贷订单中任意一笔逾期天数在 [1, 30] 区间内。
Technical Logic:sum(case when due_days between 1 and 30 then 1 else 0 end) 0Update Frequency: T1Owner: 贷后风控组-张三Source Table:ods_loan_repayment_detail只有注册了元数据的标签才允许上线进入生产环境。
带着镣铐跳舞隐私计算与合规红线在金融领域数据安全大于天。
《个人信息保护法》PIPL出台后以前那种“裸奔”的数据使用方式就是找死。
物理隔离与“可用不可见”敏感数据加密mobile、id_card、name在落库底层数仓ODS层的那一刻必须经过Hash Salt加盐处理。
开发人员在做 ETL 开发时只能看到8f7b...这种乱码无法反推真实手机号。
只有在最后触达发送短信的环节通过特权的解密网关进行调用。
联邦学习Federated Learning的应用这在消金的联合建模中非常流行。
场景你想用某电商平台的数据来判断用户的购买力但电商平台不可能把核心用户数据传给你你也不可能把借贷数据传给它。
解决方案 双方不出库原始数据只交换加密后的模型梯度Gradient。
你在本地训练风控模型的一部分。
电商平台在本地训练特征模型的一部分。
通过联邦学习协议共同迭代出一个更准的模型。
这能让你在不触犯隐私法规的前提下用上外部的高价值数据标签。
实战彩蛋如何处理“空值”在模型训练时标签的NULL值处理是门艺术。
数值型千万别无脑填0。
loan_balance在贷余额为空可以填 0。
age年龄为空填 0 会毁了模型。
建议填-1或者平均值或者单独作为一个Unknown类别。
分类型gender缺失不要瞎猜单独建一个gender_unknown组。
有时候“不愿意透露性别”本身就是一种风险特征。
进攻之战双11“临时额度”的精准突袭双11是电商的狂欢也是消金的修罗场。
所有平台都在抢用户的钱包。
我们的目标很明确让用户用我们的钱去剁手。
核心策略是发放“临时额度”。
发多了风控兜不住发少了用户去用竞品。
战前准备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。
战时响应T0毫秒级截流到了双11当天离线标签不够快了。
这时候Flink 实时标签进场接管。
场景用户打开了我们的 App或者在电商收银台犹豫表现为频繁切换 App。
实时触发逻辑Event: 用户打开 App。
Check:realtime_locationNOT IN (高危风险区)device_id没有关联黑名单。
today_login_count 3 (反复确认额度说明想买东西)。
Action:如果符合上述条件后端直接下发弹窗“双11特权5000元临时额度已到账有效期24小时”注意有效期24小时这个文案非常重要利用“损失厌恶”心理逼单。
效果复盘实战数据显示经过这套标签组合筛选出的用户临额动支率Take Rate比随机发放提升了300%且坏账率仅上升了
05%在可控范围内。
防守之战春节“失联”大潮下的催收分层做消金的都怕过年。
过年意味着用户回老家换号、钱花光了没钱还、甚至故意赖账。
催收资源是有限的客服电话打不过来我们必须把有限的兵力投放在最可能回款的人身上。
我们要把逾期用户分为三类制定不同策略第一类还款意愿强但暂时遗忘首贷户为主标签特征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 天。
” ——以小回款保大资产。
向上管理如何用 ROI 让老板闭嘴或鼓掌辛辛苦苦搞了半年标签怎么汇报 千万别说“我们上线了 500 个标签覆盖率 99%。
” 老板不关心这个。
老板只关心赚了多少钱省了多少钱请直接甩出A/B Test 实验报告汇报模板建议背诵项目背景针对存量用户提额场景。
实验设计对照组Control沿用旧规则仅基于还款记录提额。
实验组Test引入“职业稳定性”和“消费偏好”两个新标签模型。
数据结果营销响应率实验组提升15%标签帮我们要到了对的人。
户均授信额度提升2000元。
风险表现MOB3逾期率实验组反而降低了
2%剔除了潜在高风险人群。
结论新标签体系预计每年为公司带来3000万的新增利息收入。
这才是CTO和CEO想听的汇报。