Update from Sync Service
This commit is contained in:
FNS Service
@@ -0,0 +1,153 @@
|
||||
### 自我介绍
|
||||
|
||||
老师您好！我叫李振洋,过去1年多时间是在TEMU这边主要负责海外认证仓和客退仓的风控策略开发。
|
||||
|
||||
首先呢，我们主导搭建了TEMU海外认证仓和客退仓的日常业务监控与异动归因分析体系。我们会从业务量、异常单量比例、履约时效准确率等多个维度对业务进行日常的监控，并对业务异动进行异动归因，通过贡献度拆解等方法，下钻到区域、品类、物流商、店铺等维度，快速定位异动的根本原因，并与业务部门一起对异动进行及时干预。并且，我们还建立了对应的线上报表体系，可以支持业务部门快速查询日常运行数据和统计处罚进度等信息。
|
||||
|
||||
此外，我们设计并落地了一套客退仓的风控机制和运营策略。例如，在出库环节，我们有一个销毁出库的业务，这个业务分为按重量计费和按箱数计费两种计费方式，我们分别对方式建立了风控机制，对于按重量计费的，开发重量异常的识别方法，并设计了处罚机制。对于按箱数计费的，我们引入AI图像算法，对服务商上传的出库凭证进行粗筛，识别其中装载率不达要求的箱子，在这个基础上，我结合运营的人工复合结果，与算法同事一起对识别算法进行优化，显著提升监控准确率与召回率，形成“监控→识别→干预→迭代”闭环。
|
||||
|
||||
同时，我也建立了认证仓库履约质量评价体系，基于履约及时率、履约失效等信息为子仓的履约质量打分，此外，我们会对履约质量严重低于大盘、保证金不足等等一些情况进行自动预警，
|
||||
|
||||
提醒业务部门及时介入处理，对于长期不达标仓库自动发起处罚。同时，我们也会根据仓库的履约情况、异常单比例和其他的一些因素为业务部门提供巡仓优先级的建议，支持业务部门高效巡仓；
|
||||
|
||||
最后，我们会做一些专项的分析研究，对我们在日常监控过程中发现的，或者是业务部门反馈的异常案件进行进入分析，挖掘新的异常监控指标，对共性的问题建立新的识别和处罚体系，不断提高风控的准确性；
|
||||
|
||||
|
||||
|
||||
### 风控策略开发流程
|
||||
|
||||
* * *
|
||||
|
||||
**面试官您好，关于风控策略的开发流程，我想以“销毁出库异常重量识别”这个项目为例来说明。**
|
||||
|
||||
整个过程我遵循了“问题定义 -> 数据探查 -> 策略设计 -> 规则校准 -> 落地闭环”的标准流程。
|
||||
|
||||
**首先，是明确业务痛点和目标。** 我们发现，在按重量计费的销毁出库场景中，存在部分仓库虚报重量、套取费用的风险。我们的核心目标是：在有效识别并遏制这种违规行为的同时，也要避免对正常操作的仓库造成误伤，引发不必要的舆情风险。
|
||||
|
||||
**其次，进行深入的数据探查与分析。** 我们采集了海量的历史称重数据，并按SKU维度进行聚合分析。通过观察数据分布，我们发现单个SKU的重量虽然存在一定波动，但其历史中位数是一个非常稳健的参考基准。因此，我们初步决定以SKU的历史称重中位数作为该SKU的标准参考重量。
|
||||
|
||||
**接着，是核心的策略规则设计。** 识别逻辑很简单：当一笔出库订单的实际重量超过其对应SKU参考重量的某个阈值比例时，即被判定为异常。但关键在于，这个“阈值比例”如何科学设定？这里我做了两方面的精细化考量：
|
||||
|
||||
1. **数据层面**：我分析了各SKU历史重量的分布情况（比如标准差、分位数），确保阈值能覆盖绝大多数正常波动。
|
||||
2. **业务层面**：我模拟了不同阈值下，对全量子仓产生的处罚影响。通过测算罚单数量和预估罚金总额，我们找到了一个平衡点——既能有效覆盖高风险的异常行为，又能将对大多数合规子仓的处罚率和罚金控制在一个可接受的范围内，从而兼顾了风控效力和合作方的体验。
|
||||
|
||||
**最后，是策略的落地与闭环。** 规则确定后，我们将其部署到监控系统中，实现了对异常订单的实时预警和自动拦截。同时，我们建立了申诉和复核通道，并将人工核实的结果反馈回模型，用于未来对阈值或规则的持续迭代优化。
|
||||
|
||||
通过这套方法论，我们成功上线了该策略，不仅显著降低了异常重量订单的比例，也因为前期充分的校准工作，确保了策略执行过程中的平稳过渡，得到了业务和合作方的认可。
|
||||
|
||||
|
||||
|
||||
### 如何定义和量化异常
|
||||
|
||||
**面试官您好，“如何定义和量化异常”是风控工作的核心问题。我的原则是：异常不能仅靠统计直觉，而必须结合数据分布、业务影响和可操作性，进行量化定义。**
|
||||
|
||||
我以一个实际项目为例来说明——**合作仓发货履约质量的异常预警体系**中的“发货时长异常”模块。
|
||||
|
||||
我们的目标是及时发现履约效率持续下滑的子仓，避免影响终端客户体验。但“慢”是相对的，所以我们需要一个客观、公平且可执行的判断标准。
|
||||
|
||||
**首先，我们基于大盘数据建立动态基准。**
|
||||
每天计算全网子仓的平均发货时长作为当日大盘基准。然后，对每个子仓，判断其当日发货时长是否超过大盘均值的 **150%（即高出50%）**。这个阈值不是拍脑袋定的，而是通过分析历史数据中“子仓 vs 大盘”的发货时长差异分布得出的——它能覆盖掉绝大多数正常波动，同时保留对真正低效仓的敏感性。
|
||||
|
||||
**其次，我们引入时间维度过滤噪音。**
|
||||
单日异常可能是偶发因素（如系统故障、临时缺人），因此我们设定：**只有连续3天触发该条件，才生成正式预警**。这有效降低了误报率，确保预警对象是存在持续性问题的子仓。
|
||||
|
||||
**最关键的是，我们用业务指标对策略进行了量化校准。**
|
||||
在确定“50%”这个阈值时，我们不仅看了统计分布，还模拟了不同阈值下：
|
||||
|
||||
- 每天会触发预警的子仓数量；
|
||||
- 预计需要运营介入的工作量。
|
||||
|
||||
最终选择的参数，是在**风险覆盖度**（能抓到多少真正有问题的仓）和**运营可承载性**（预警量不至于让团队疲于奔命）之间取得的最佳平衡。
|
||||
|
||||
**最后，我们用历史数据做了完整回测，并与运营、商务团队对齐。**
|
||||
回测结果显示，该策略能提前3–5天识别出后续被投诉或降级的低效仓，准确率和召回率均达到预期。更重要的是，我们拿着回测报告和预警样例，与运营、商务同事一起评审，确认预警结果符合他们的业务感知，并就后续处置流程达成一致，才正式上线。
|
||||
|
||||
**所以总结来说，我对“异常”的量化，是一个从数据出发、以业务闭环为目标、经过多轮校准和验证的系统工程。** 它确保了风控策略既科学严谨，又能真正驱动业务行动。
|
||||
|
||||
### 主动发现风险点：
|
||||
|
||||
1. 物流商提前上传签收
|
||||
1. 过程：
|
||||
1. 发现：有多个客退仓子仓质检延迟的罚单和罚金异常激增；
|
||||
2. 异动分析：
|
||||
1. 发现质检延迟罚单在部分物流商上出现明显聚集，并且这些问题子仓其他物流商的退货单质检延迟没有出现明显上升；
|
||||
2. 对物流商逆向轨迹进行分析，发现了聚集物流商存在退货单激增且，大量退货单的轨迹存在异常(如： 最后一次转运轨迹操作时间和签收时间之间间隔极短)，且相同时间段内，其他物流商未出现轨迹异常的情况；
|
||||
3. 与商务、运营等讨论确认：
|
||||
1. 当时正处于黑五之后，退货量激增，部分仓库出现爆单问题；
|
||||
2. 问题物流商承认由于爆单，部分操作人员在没有送达仓库前提前点了签收，导致该问题出现；
|
||||
4. 后续处理：
|
||||
1. 筛选问题物流商的问题单，提交商务团队，由商务团队同事与物流商商议一次性的处罚；
|
||||
2. 与商务、运营确定范围，推动主动为仓库服务商进行免罚，防止舆论风险；
|
||||
3. 调整质检延迟的开始时间，由物流商上传的签收时间改为仓库上传的收包时间，并且要求仓库提供收包凭证；
|
||||
4. 增加对物流商轨迹异常的监控(只监控与仓库考核相关的轨迹节点)；
|
||||
|
||||
|
||||
|
||||
1. ### 风控策略开发都做了哪些事情，策略如何定义
|
||||
|
||||
1. 异常检测
|
||||
1. 欺诈收货
|
||||
1. 发现：商务发现反馈，发现原因：该子仓客退收货量激增，且有物流商举报(仓库操作问题导致物流商被处罚，无轨迹)；
|
||||
2. 复盘结果：
|
||||
1. 复盘的思路：
|
||||
1. 梳理整个退货流程各个环节，寻找可能存在的漏洞；
|
||||
2. 寻找可以检测漏洞的数据指标；
|
||||
3. 从每个环节的操作上入手，寻找典型的数据指标，比如时间、操作的凭证、操作所必然带来的信息；
|
||||
2. 发现：
|
||||
1. 时间类：
|
||||
1. 从退货申请到仓库质检完成时间：异常子仓该时间的中位数明显偏低；
|
||||
2. 从签收到仓库质检完成：异常子仓该时间的中位数明显偏低(但这个指标并不具有特异性，召回很低)；
|
||||
2. 操作凭证类：
|
||||
1. 点数视频无效率很高；
|
||||
3. 其他：
|
||||
1. 客退单无逆向物流轨迹的占比较高；
|
||||
2. 薅羊毛:
|
||||
1. 发现：问题子仓实收sku占比异常偏低， 视频无效率偏高，但操作时长无异常；
|
||||
2. 过程：
|
||||
1. 日常监控发现问题子仓出现数据异常，但不符合欺诈收货的特征；
|
||||
2. 与商务和运营沟通，并与子仓确认情况，子仓收到大量包装类似的包裹，并且包裹中均只有破旧衣服，没有退货的物品，判断子仓遭到灰产组织的薅羊毛行动；
|
||||
3. 同时，发现子仓确实存在点数拆包不规范的问题；
|
||||
3. 后续：
|
||||
1. 持续加强对问题子仓及其周边地区子仓的监控；
|
||||
2. 对服务商宣贯拆包规范，要求其加以改进；
|
||||
3. 客服侧上线对该地区异常账号的风控标示，对高风险用户，不以「点数视频无效」进行退款；
|
||||
3. 未拆包点数：
|
||||
1. 发现：排查子仓点数错误问题时发现；
|
||||
2. 策略制定：
|
||||
1. 相关性：与调拨回国空包调包的相关性分析；
|
||||
2. 以业务分析：
|
||||
1. 标签打印次数：与sku数量或种类相等；
|
||||
2. 上报黑码的退货入库单数量：极低；
|
||||
3. 最后一次打印标签与包裹入库完成时间差90分位数：较低；
|
||||
4. 商品类别：不包括服装类sku；
|
||||
3. 后续处理：
|
||||
1. 按策略逻辑进行粗筛，再有运营人工复核；
|
||||
2. 初始阶段只处罚流入的入库单，后续如果指标准确性得到证明考虑对高风险质检人按比例进行处罚；
|
||||
4. 物流商提前上传签收
|
||||
1. 目的：确认物流商违规，进行处罚；
|
||||
2. 过程：
|
||||
1. 发现：有多个客退仓子仓质检延迟的罚单和罚金异常激增；
|
||||
2. 异动分析：
|
||||
1. 发现质检延迟罚单在部分物流商上出现明显聚集，并且这些问题子仓其他物流商的退货单质检延迟没有出现明显上升；
|
||||
2. 对物流商逆向轨迹进行分析，发现了聚集物流商存在退货单激增且，大量退货单的轨迹存在异常(如： 最后一次转运轨迹操作时间和签收时间之间间隔极短)，且铜时间段内，其他物流商未出现轨迹异常的情况；
|
||||
3. 与商务、运营等讨论确认：
|
||||
1. 当时正处于黑五之后，退货量激增，部分仓库出现爆单问题；
|
||||
2. 问题物流商承认由于爆单，部分操作人员在没有送达仓库前提前点了签收，导致该问题出现；
|
||||
4. 后续处理：
|
||||
1. 筛选问题物流商的问题单，提交商务团队，由商务团队同事与物流商商议一次性的处罚；
|
||||
2. 推动物流商侧建立对提前签收问题的处罚；
|
||||
3. 与商务、运营确定范围，推动主动为仓库服务商进行免罚，防止舆论风险；
|
||||
4. 建立对物流商轨迹异常的监控(只监控与仓库考核相关的轨迹节点)；
|
||||
5. 手段：业务量，业务信息分布，异常单，操作或榴月时效等
|
||||
2. 运营策略
|
||||
1. 销毁出库重量异常:
|
||||
1. 策略制定：根据历史称重数据建立参考重量，并使用物流商上报重量作为兜底和校验，防止仓库故意将所有的称重都往高报；
|
||||
2. 对不满足称重次数的sku进行监控；
|
||||
2. 销毁出库装载率异常，这里要强调：
|
||||
1. 引入图像识别算法，利用算法对出库凭证数据进行粗筛，再由运营进行人工复合；
|
||||
2. 根据运营人工复合结果，整理反馈标签，推动图像算法优化；
|
||||
2. 日常报表体系
|
||||
|
||||
1. 支持业务快速查询数据
|
||||
2. 处罚量和处罚率
|
||||
3. 处罚进度跟踪
|
||||
Reference in New Issue
Block a user