惯性聚合 高效追踪和阅读你感兴趣的博客、新闻、科技资讯
阅读原文 在惯性聚合中打开

推荐订阅源

钛媒体:引领未来商业与生活新知
钛媒体:引领未来商业与生活新知
Stack Overflow Blog
Stack Overflow Blog
云风的 BLOG
云风的 BLOG
G
Google Developers Blog
J
Java Code Geeks
C
Check Point Blog
Last Week in AI
Last Week in AI
Microsoft Azure Blog
Microsoft Azure Blog
Blog — PlanetScale
Blog — PlanetScale
月光博客
月光博客
Vercel News
Vercel News
The GitHub Blog
The GitHub Blog
L
LangChain Blog
有赞技术团队
有赞技术团队
Cyber Security Advisories - MS-ISAC
Cyber Security Advisories - MS-ISAC
博客园 - 司徒正美
IT之家
IT之家
Martin Fowler
Martin Fowler
让小产品的独立变现更简单 - ezindie.com
让小产品的独立变现更简单 - ezindie.com
T
Tailwind CSS Blog
U
Unit 42
Jina AI
Jina AI
Microsoft Security Blog
Microsoft Security Blog
I
InfoQ

人人都是产品经理

为什么你的产品找不到差异化?90%的失败都卡在第一步上(下) – 人人都是产品经理, 3年从30万到1300万用户、获2200万美元融资,这个AI教育产品用“抽卡”破解了获客难题 – 人人都是产品经理, 园区招商系统怎么做才能真正帮到去化?我加了这一个功能,推广链接转发400次阅读过万 – 人人都是产品经理, AI大事件:OpenAI发完网络安全模型又搞药物研发,小鹏汽车要抓”DeepSeek时刻” – 人人都是产品经理, 电商不是卖货,是一场更残酷的产品经理实战 – 人人都是产品经理, 没想到,活动营销又回来了! – 人人都是产品经理, 为何All-in海外KOC:一场关于AI时代窗口期的豪赌 – 人人都是产品经理, 重新理解企业的内部协作 – 人人都是产品经理, 苹果的 AI 战略到底是什么? – 人人都是产品经理, 医疗智能体·第2讲——合规护城河:等保、PIPL与HIPAA的架构实战 – 人人都是产品经理, 向量知识库五步法:从“答非所问”到“精准回复” – 人人都是产品经理, 鸿蒙PC三方库构建总指挥HPKBUILD(sha)库为例 – 人人都是产品经理, 何时该用LLM?AI产品经理的LLM设计指南 – 人人都是产品经理, 医疗信息领域的需求方、决策方、准入方以及关注点(二) – 人人都是产品经理, 即梦涨价:一场被误读的「傲慢」 – 人人都是产品经理, 面试AI PM必答题:Hermes和OpenClaw的区别,如何讲清楚业务价值 – 人人都是产品经理, AI的下一张船票:世界模型——AI产品经理必须理解的技术拐点 – 人人都是产品经理, 小红书做GEO,怎么让AI信你?记住这 3 个重要信息 – 人人都是产品经理, 5 家印度 AI 初创公司,看看印度 AI 再做什么 – 人人都是产品经理, AI项目跨团队协作:产品技术业务如何不打架 – 人人都是产品经理, Agentic Workflow(智能体工作流):让AI从”答案生成器”变成”数字员工” – 人人都是产品经理, lycium_plusplus 项目全景解读:OpenHarmony 三方库构建的“大管家” – 人人都是产品经理, 从爆单救火到前置履约:两套预采策略,把生鲜大促履约效率拉满 – 人人都是产品经理, 什么时候该补货?我用一轮数据做了一个决定 – 人人都是产品经理, 从“机械兜底”到“动态分流”:AI客服重复进线治理的4大底层逻辑 – 人人都是产品经理, 抖音拼效率,红书拼洞察 – 人人都是产品经理, 全民狂欢与退潮——为什么龙虾这波热潮冷却得如此之快? – 人人都是产品经理, Stripe押注!MPP重塑全球支付 – 人人都是产品经理, 小红书GEO:AI引用你的内容,不是因为你对,而是因为你看起来可信 – 人人都是产品经理, 前百度副总裁押注办公Agent,日韩付费爆发,Manus迎来强劲对手 – 人人都是产品经理,
年放贷200亿的互金项目怎么做运营(贷中篇)
运营学记 · 2023-08-30 · via 人人都是产品经理

本文是某次培训的讲稿,主要面向的对象是不了解或刚入行互联网信贷行业(下面简称互金)的运营、产品和分析师。主要是作者在运营多个互金业务后,对互金业务、数据、运营的经验总结,本文讲述贷中篇,希望对您有所帮助。

我经手的项目有某支付公司年放贷200亿的现金贷项目,同公司的年放贷2亿左右的消费分期项目,也有某头部卡贷公司贷超项目。对入行3年以内的朋友应该还有借鉴意义,业务经验较丰富的朋友可能需要自行判断是否跳过。原文超过一万两千字,拆成贷前贷中贷后三篇发出来,希望文章的价值可以值得大家的阅读时间。

本文按互金业务阶段顺序拆解内容,每个阶段我一般会分成4个方向去讲,第一是该阶段的业务特征或流程,第二是该阶段关注的指标,第三是这个业务阶段,行业内都是怎么做的,或者流程是怎么样的,第四是这个阶段主要关注的运营场景。

下面我开始讲贷中,贷中主要是两个环节,一个是授信,一个是请款跟放款

一、授信

1. 业务

先看授信阶段,授信更多是资方或者大的助贷方在做的,我大致讲一下授信和风控的原理。有个行业的大佬讲过,现代信贷和传统信贷不同的地方,就在于风控的一体两翼。它的一体说的是“以群体风控为主体”,两翼则是“以定价覆盖风险,以催收覆盖不良”。

这个话怎么理解呢?传统信贷的风控主要是一人一策,一人一价,而现代的人群定价,则是一群人一个策略。风控会根据用户提交的信息,以及在征信平台、第三方平台的数据源,查到的用户的收入数据、消费数据,以及其它历史数据等各种信息,根据这些信息,判断用户的需求强度、借款能力、还款能力,然后对用户进行人群的对号入座。比如说典型的分层像蓝领阶层,白领阶层,管理阶层,都会根据人群整体,形成对应的风控策略。

因为这些不同的分层,用户的整体情况是不一样的,他的收入水平、消费水平、还款能力其实都是不一样的,就导致客群基本的逾期概率是不一样的。风控模型就会在客群初始逾期几率的基础上,对这个客群对放款金额和放款利率进行调控。比如说白领客群的逾期几率只有0.5%,信贷产品的生产方就会在0.5%的基础上,加上自己的资金成本。假如资方是4%利率把这个资金借入的,那就加一个4%,助贷方的获客营销等运营成本是4%,就再加一个4%。基于基础的费率,再加上一个自己希望的收益费率,比如说5%,那给白领人群的最低费率就是0.5%+4%+4%+5%=13.5%。然后再根据个体在白领人群中的具体情况,再决定更进一步的费率调整。

另外因为不同客群收入和消费的能力也不一样,所以他的额度肯定也是不一样的。这就是群体风控,就是定价覆盖风险。至于催收覆盖不良,我稍后讲到催收那块再讲。

2. 指标

在授信这块,关注的核心指标就有两个,授信额度和授信通过率。因为国内现金贷授信一般都是策略+模型风控,没有更多的环节。从业务侧来说,拆分的维度很有限,助贷侧通常会拆解不同资方来看。

3. 行业

在授信阶段,有一个比较典型的行业案例,可以帮助大家理解授信的风控模型。蚂蚁信用的模型可以进行学习参考,它有非常强的风控借鉴意义。因为17年之前,市面上有1/3以上的信贷产品是不查征信,也基本没有风控系统的。他们只查蚂蚁信用分,只要是580分或者600分以上,都可以获得3000元左右的额度。从这些产品当时的不良情况来看,蚂蚁的模型还是有相当强的借鉴意义的。

另一个值得一说的,是授信风控所处的技术阶段,在17年的时候,某信已经做了大数据风控,这也是某信上市的一个卖点,目前大数据风控已经是行业基础了。20年某支付拿到了小贷牌照,有牌照后按政策要求,就必须要做自己的风控系统了,当时某支付已经做到了智能风控,通过机器学习去训练自己的风控算法。整体来说,风控这块技术应用还是比较领先的。

4. 运营

在风控这边的运营可能参与的场景,主要有两个,一个是通过用户行为数据识别监控欺诈用户,另一个是通过周边业务数据采集辅助风控。但是这两个其实都是风控和大数据主导的,运营主要配合使用,所以也不再详细讲了。

二、请放款

1. 业务

下面讲一下请放款阶段。请款放款之所以放在一起,是因为它其实是一体两面的,用户请款,平台放款,所以把它放在一起。请放款的流程,也是相对较简单的。用户去申请提现,资方进行贷中风控,如果风控没有问题,就会进入到第三个阶段放款。从提现到放款中间,资方会再次查用户的信息,比如征信,来判断用户在申请到放款期间,资质有没有变化。如果资质有下降,他很可能会面临额度下降、额度冻结、放款失败之类的情况。

2. 指标

这个阶段关注的指标,主要是支用率和支用金额。支用率拆解下来有借款申请率和借款通过率,还可以分成新老用户的不同客群指标,还可以按用户注册或授信时间,拆分成近期新户、远期新户、近期老户、远期老户。支用金额可以拆解成支用用户数、支用件均,客群侧的拆解,可以参考支用率。

3. 行业

这个阶段有一个需要注意的点,就是借款通过率下降的问题。像某支付,资方最开始接的是众安,众安这个产品上线的第一年,借款通过率基本上都是在90%以上的。但是从第二年开始,借款通过率就出现了比较大幅度的下降,而且是持续性的下降,6个月内就迅速从90%直接降到60%多。通过率的下降,对于助贷平台或者是资方来说,都是一个比较头疼的问题,因为它本质来说是用户质量的下降。它的下降原因,可以分成两种类型的用户来看。

一种是新用户,新用户借款通过率下降,主要可能客群的问题。因为这部分用户很可能同时向多个信贷产品申请借款,他就会存在多条的征信查询记录。因为用户操作的时间差会导致信息不同步,会出现授信的时候征信还没有问题,等到放款时候,这个用户已经有多条征信查询记录了,就会导致放款失败。另外一种是老用户,老用户会有两种情况,一种是授信完没有发起借款,授信跟首次借款之间相差的时间比较久,用户的信息在这段时间内发生了变化,导致最终贷中风控不成功。

另外一种,是用户已经借款了,他复贷借款时候被拦截。复贷风控被卡的原因,常见于用户多次借款,已经到了逾期危险次数的情况。资方根据复贷次数判断这个用户的资质是否下降到了危险区间,如果是,就会风控拦截。

之前在某信的时候,他们的风控专家有一个在行业里边都比较有名的论断,他认为一个正常的用户,在复贷过4次之后,这个用户的价值就开发完了,因为复贷4次后,用户的逾期风险会大幅度的提升。这个结论是通过某卡贷自己的授信、逾期数据得到的。

我们去分析这个结论的时候,认为现金贷用户,有借款次数的危险边界或者叫生命周期。一个正常的用户,不可能连着不断的去借款。如果累积借款到4次,就说明这个用户收入和支出的匹配上,大概率存在问题。这些问题,可能是赌博、无法节制的消费欲望,也可能是想借钱创业、投资,改变命运,无论他的原罪是什么,这种类型的用户,一定是非常容易逾期的,也就需要风控的重点关注。

当然,这是18-20年左右的结论了。现在很多助贷平台为用户开多卡授信,以提升用户综合授信额度,以提升整体放款金额,实质上是鼓励用户多头。这种情况下,即便是一个好的用户,质量也是在飞速下降的。资方风控稍微紧一些,贷中被拒也就不奇怪了。

4. 运营

接着看下这个阶段需要做的一些运营工作。一般来说用户完成授信后,在一定的时间内,一定会产生借款。因为他经过前面那么繁琐复杂的步骤,完成了授信的过程,就可以说明他是一个有需求的用户,有需求就一定会去借款。所以其实运营侧想推动用户主动去借款,是比较困难的事情。因为现金贷用户本身就是强需求驱动,当前比较紧急,有需求的用户都已经去借款了。用户当前没有借款,可能只是还没有到需求节点。

这个阶段的运营触达主要有几种。一是纯内容的触达,有的用户过了一段时间会忘记他在这边还有一个额度,纯内容触达就是对他做一定的提醒。第二种是还款券,还款券逻辑比较简单,助贷方自己出成本做功能就可以,可以最先上线。第三种是免息券,免息券因为要跟资方做成本和功能上的合作,又有各种信息传输,一般是最后才能上的。这几种触达内容整体看下来,免息券会比还款券或内容触达,效果好很多。即便是免息券的最高减免金额和还款抵扣金额一致的情况下,免息券效果也会比还款券要好。

这个阶段的用户分层逻辑是比较简单的,按用户的行为深度、沉默周期、需求强度评估等,进行防沉默、失活召回、沉默召回触达就行。

这个阶段的触达通道主要有APP内弹窗、PUSH、短信、智能外呼、人工外呼等手段,其中PUSH效果最差,短信效果其次,智能外呼效果会好一些,然后是人工外呼和APP内弹窗。在运营时,APP内弹窗是实时触达,基于用户旅程定点触达即可。PUSH和短信要基于文案的“六大元素”(称谓、欢迎语、卖点权益、时效限制、社会证言、行动号召)进行AB正交实验,相同人群的不同文案转化可能相差10倍,而且结果也可能是反直觉的(不一定权益描述越清楚效果越好)。智能外呼和人工外呼则需要不断AB测试优化话术SOP,并控制好智能外呼和人工外呼的顺序。

触达的形式,第一阶段通常是手动AB。得到较好结果后,第二阶段做触达策略的自动化固化,再配合对特殊或重要客户的手动取数触达。第三阶段要基于对用户旅程的实时数据,基于用户在业务流中的旅程节点和时间节点,进行分层分类的实时自动化触达。这块儿大家如果有兴趣,后面我单独开一篇来讲。

本文由 @超级个体计划 原创发布于人人都是产品经理。未经许可,禁止转载

题图来自Unsplash,基于CC0协议。

该文观点仅代表作者本人,人人都是产品经理平台仅提供信息存储空间服务。