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

推荐订阅源

J
Java Code Geeks
Engineering at Meta
Engineering at Meta
GbyAI
GbyAI
MongoDB | Blog
MongoDB | Blog
Blog — PlanetScale
Blog — PlanetScale
腾讯CDC
U
Unit 42
freeCodeCamp Programming Tutorials: Python, JavaScript, Git & More
Apple Machine Learning Research
Apple Machine Learning Research
M
MIT News - Artificial intelligence
人人都是产品经理
人人都是产品经理
Hugging Face - Blog
Hugging Face - Blog
MyScale Blog
MyScale Blog
小众软件
小众软件
博客园 - 三生石上(FineUI控件)
N
Netflix TechBlog - Medium
阮一峰的网络日志
阮一峰的网络日志
博客园 - Franky
Recent Announcements
Recent Announcements
A
About on SuperTechFans
Stack Overflow Blog
Stack Overflow Blog
The GitHub Blog
The GitHub Blog
D
Docker
H
Hackread – Cybersecurity News, Data Breaches, AI and More

人人都是产品经理

为什么你的产品找不到差异化?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迎来强劲对手 – 人人都是产品经理,
费米估算在风控场景中的应用
熊老板日记 · 2022-08-22 · via 人人都是产品经理

在建设风控,需要用一些工具来帮助业务决策,这里常用的是用费米估算在风控场景中的应用。本文以北京胡同口一天能卖出多少煎饼为例,分析如何应用费米估算,以期帮助大家提升自我数据思维。

通常新业务在进入快速发展期,业务同学更关注的是用户拉新、业务增长等直接业务指标。

对于场景中的刷单用户数、订单数等健康度指标关注相对较少。

回过头来看的时候,发现平台已经被薅取了很多的营销资金,便开始着手去建立风控治理能力。

在什么时候开始建设风控,需要一些工具来帮助业务进行决策。

一、费米估算

百度上解释:费米估算指的是解决未知结果的估算问题,将复杂的问题拆解成小的、可知结果的部分。

直白一点,就是把复杂的大问题,拆分成一个个复杂的小问题。

同时将小问题的求解逻辑,转变为熟悉的业务因子和计算逻辑。

将已知的业务因子进行代入,即可计算出该问题的估算值。

说的很绕口,要入门的同学,可百度搜索:芝加哥有多少个钢琴调音师。

基本看一遍就知道咋用了。

二、北京胡同口一天能卖出多少煎饼

了解基本用法后,用一个习题来进行巩固:北京胡同口一天能卖出多少个煎饼?

解题思路:

从需求侧出发:

煎饼数量 = 购买人数 * 购买数量;

购买人数 = 胡同口覆盖人数 * 购买率

因胡同主要集中在北京中心区,胡同口覆盖人数 = 北京中心区可购买人数 * (胡同数量 / 道路数量)/ 胡同数量

可购买人数 = 北京中心区人数 * (1 – 婴幼儿比例)

按照21年高德统计数据,北京总人口为2188W,胡同数量1004条,道路数量14848条,北京中心区人口占比50%,婴幼儿占比20%;

通常一个人每周吃煎饼的次数,最多不会超过7次,最少不会超过1次,平均下来一周7天吃3次,购买率 = 3 / 7 = 43%

煎饼的季节性干扰很低,但时间段干扰较严重,通常集中在早饭,且一个为主。因此购买数量 = 1;

以上数据,可得出:

可购买人数 = 2188W * 50% *(1 – 20%)= 875W;

胡同口覆盖人数 = 875W * (1004 / 14848) / 1004 = 569;

购买人数 = 569 * 43% = 244个;

煎饼数量 = 244 * 1 = 244个;

从供给侧出发:

煎饼数量 = 摊主工作时长 / 每个煎饼耗时

煎饼的售卖集中在早上6:00 – 9:00,3个小时 = 10800秒;

每个煎饼的制作时间约为30秒;

以上数据,可得出:煎饼数量 = 10800秒 / 30秒 = 360个;

煎饼生意明显是个供大于需的生意,因此主要是需求侧来驱动,整体量级会接近需求侧量级。

三、业务场景中存在多少的刷单

到这里,我们可以借用费米估算,来估算交易场景中存在多少的刷单订单,以此来辅助业务进行决策。

解题思路:

从需求侧出发:

  • 刷单订单数 = 刷单用户数 * 户均刷单数
  • 刷单用户数 = 新客刷单数 + 老客刷单数
  • 新客刷单数 = 新客注册数 * (1 – 新客正常流失率)
  • 老客刷单数 = 老客活跃数 * (1 – 老客正常流失率)
  • 户均刷单数 = (总订单数 – 正常订单数)/ 完单用户数
  • 正常订单数 = 预估订单数 * (1 + 预估浮动比例)
  • 预估订单数 = 预估完单用户数 * 户均订单数

从供给侧出发:

  • 刷单订单数 = 总订单数 * 实际优惠补贴差值
  • 实际优惠补贴差值 = 实际优惠率 – 预估优惠率

这是一个需求侧驱动场景?还是供给侧驱动场景?

四、总结

这里,培养的是数据分析思路。

在实际业务场景中,经常会碰到很多问题:比如常见的“DAU下降问题”、“支付转化率下降问题”等。

其实每个答案都不是唯一,重要的是思考的逻辑和数据的推理。

即便有些事情看上去无法确定,但可以通过分析拆解,逐步逼近结果。面对不确定性,我们不应停滞不前,而是要懂得抓住身边有价值信息,快速决策。

最后,留个习题:中国有多少个出租车司机?

本文由 @话多的熊仔 原创发布于人人都是产品经理,未经许可,禁止转载。

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

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