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

推荐订阅源

让小产品的独立变现更简单 - ezindie.com
让小产品的独立变现更简单 - ezindie.com
A
About on SuperTechFans
Y
Y Combinator Blog
V
V2EX
Engineering at Meta
Engineering at Meta
freeCodeCamp Programming Tutorials: Python, JavaScript, Git & More
V
Visual Studio Blog
博客园 - 叶小钗
博客园 - 聂微东
阮一峰的网络日志
阮一峰的网络日志
H
Help Net Security
小众软件
小众软件
奇客Solidot–传递最新科技情报
奇客Solidot–传递最新科技情报
The GitHub Blog
The GitHub Blog
WordPress大学
WordPress大学
OSCHINA 社区最新新闻
OSCHINA 社区最新新闻
MongoDB | Blog
MongoDB | Blog
B
Blog
G
Google Developers Blog
J
Java Code Geeks
博客园 - 三生石上(FineUI控件)
IT之家
IT之家
N
Netflix TechBlog - Medium
腾讯CDC

人人都是产品经理

为什么你的产品找不到差异化?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迎来强劲对手 – 人人都是产品经理,
用户运营实战:生鲜超市用户运营案例分享
运营观察 · 2023-02-23 · via 人人都是产品经理

当用户导入出现异常,找不到原因时,你都是怎么解决的?本文以某生鲜超市为例,解析如何解决老客留存率也低于正常新店基准值,帮助店铺提升用户的生命周期,希望对你有所启发。

运营背景:在过去一段时期内某生鲜超市一家新店有100万导入期用户,仅有15%用户进入成长期,老客留存率也低于正常新店基准值,如何帮助这家店提升用户生命周期?

解决这个问题,在用户策略上我们会分拆几步

1、 洞察用户从导入期到成长期的典型用户路径和特征是什么,去找发力点做优化

2、 去搭建补贴激励体系及触达体系

3、 去搭建防流失管理体系

一、基于最优路径做用户的1转N单策略

首先就是洞察已经进入成长期用户的典型路径和特征,这里先说一下成长期的定义,我们定义用户成长期的标志是用户在多长时间内达到多少单会进入一个稳定的复购周期,我们通过洞察发现35天内下完3单的用户流失率明显降低,这是我们定义成长期的一个北极星指标。

做用户路径洞察的目的是什么呢?

第一个目的是分析用户从导入期到成长期到底是路径1更优还是路径2更优。

第二个是基于最优路径去做运营策略的布局。

比如这家生鲜超市APP,用户完成1-3单转化有几条强路径。

  1. 路径1:优惠券列表-去使用-可用券商品区下单
  2. 路径2:首页搜索转化
  3. 路径3:首页活动专区

导入期优惠券路径用户完成三单的占比便达到了60%,说明一个新用户持续留存在APP的最优路径就是新人礼包的补贴策略,我们在券包策略方面做了一系列调整,比如我们上过一个新人任务进度提醒产品,用户每下一单,会在任意页面最顶端通栏显示下一单的优惠以及完成3单后的惊喜礼包,这便是一个非常简单的激励体系,这个产品,新客1转N漏斗提升效果挺明显,转2单及以上用户比例由40%提升到67%。

围绕“首单+每单购后即时激励”模式打造,提前锁定新用户认知,引导用户完成0-3单转化。

二、补贴和激励

补贴策略制定:

第一建立商品促销与用户的匹配策略。

第二建立用户补贴的评估体系。

第一个,商品促销用户匹配在触达体系中最为关键,比如今天是草莓活动,明天是苹果活动,运营每次推这种活动的时候最头大的问题就是push和短信该推给哪些用户,要不无差别覆盖,用户每次被打扰一次,要不就是基于用户点击数据做简单分层,但发现并不精准。

解决这个问题的核心就是用偏好时序模型,偏好预测是推荐场景下的一个重要任务,原理是给定用户先前购买的商品序列,以及商品交互行的时间衰减,利用模型对用户的下一笔购物行为进行预测。

偏好时序模型运营可以通过SPSS分析得到:

假如这个是用户订单底表数据,我们通过数据来建立一个分析模型:

目标是通过这个订单底表数据建立一个挖掘模型,挖掘用户的购买序列习惯,并预测用户下一个购买节点会购买什么

我们通过SPSS搭建一个时序分析流,由数据模型帮我们进行预测。

这个数据流输出结果是:

用户时序分析结果翻译一下

如果用户在购买了苹果和鸡蛋后,下一次购买苹果的置信度是100%(由于实验数据过拟合,所以是100%的概率,真实订单数据的话,置信度越高,表明用户在购买完苹果鸡蛋后,下一单很高概率购买苹果)

第二个如何建立用户的触达及活动补贴评估体系?

评价指标有两个,GMV提升率和ROI,比如成长期用户运营我们是这么AB测试的,把成长期用户筛出来分为实验组以及随机抽取部分用户作为对照组,比如实验组是100万人,对照组是10万人,实验组发20减5的补贴券并通过定向短信通知形式进行干预转化,对照组不干涉自然转化。得到干预组的转化率是10%,对照组是6%。

如果强行说干预策略有效也并不一定有说服力,因为发券必然会导致转化提升,所以我们要看GMV提升率和ROI的增益是否达到预期。

简单来讲就是这100万人在干预前和干预后的增益率对比

GMV提升率=GMV提升部分/GMV基线,比如我们这个案例中GMV基线如果不干涉自然转化下单是6万人,按照20元客单来计算,GMV是120万。干涉后按照15客单计算,GMV是150万,增益GMV是30万,GMV提升率25%。

然后计算成本部分 券成本是50万,短信成本以1毛来计算,10万元,总计成本是60万,发现ROI=0.5 发现20减5并没达到预期,对吧,然后相同思路再去测45减10券,把用户客单去拔高,直到ROI远远高出1,才证明这部分用户补贴有效。

最终我们可以把ROI和GMV提升率构成一个矩阵,把所有补贴折扣、券放入矩阵中,去看ROI和GMV提升率最大的气泡分布在哪里。这就是基于历史沉淀打法和策略。

三、用户流失预警管理项目

假如月均滚动流失率是在10%左右,预警项目前,每周会固定把符合流失定义的用户筛选出来,假如1000万MAU,每周的召回覆盖人数大约就是100万,短信点击率是0.4%左右,订单转化率5%,每次最多召回200人,可想召回效率有多低。

预警模型可以将月均滚动流失率降到6%左右,提前干预转化率提升到10%。我来讲下具体是怎么做到的。

  1. 第一部分是模型的搭建
  2. 第二部分是用户分层的预警
  3. 第三部分是召回策略

模型搭建涉及流失时间窗口定义、流失特征定义、算法建模三部分。

流失时间定义方法就是按照流失回归率的拐点来定,具体不讲了。

流失特征定义对于模型设计来说是核心,特征构建我们会从具体流失场景挖掘建模指标,比如某些用户流失原因是因为配送服务体验差,并且投诉后没有很好解决,这个场景下可以衍生几个指标用于预测用户流失,比如派送次数、投诉次数、投诉解决比例,可以分析和流失之间的关联关系,同理,因为优惠少、商品种类少等等场景都可以用指标来描述。

算法部分就是一个二分类预测建模问题,可以用到的算法逻辑回归、决策树等,评价算法指标像AUC值、精准率、召回率等,建模过程中基于这些数据进行样本特征的筛选。

召回策略方面,因为预警的用户并没有真正流失,这就有充分的时间去洞察用户历史偏好度,去做针对性的召回策略,但这里实施时候会遇到2个问题:

第一个就是所有的用户数据一同灌入模型,得出预测结果。但这样做往往会遇到一个问题,就是预测出来的流失用户,更偏向于低活,而高活用户预测流失召回却基本为0。所以为了避免这样的问题,可以将不同活跃度用户分别搭建模型。

第二个就是模型准确率和召回率很难同时达到双高水平,这个时候可以根据预警目标来进行参数调优,高成本的召回策略(消费券发放)更关注流失预警的准确率;高覆盖的召回策略(端内Push)更关注流失预警的召回率。

以上是我实战分享,用户运营离不开洞察和模型的搭建,洞察如用户行为路径、用户时序习惯分析和预测,模型更不用说了,搭建时序预测模型和用户流失预警模型,除了算法工程师建模之外,运营可以使用SPSS分析软件搭建用户模型,只需了解SPSS使用方法即可,这样可以基于结论迅速假设-执行-验证,而效率却远远高于算法工程师所谓的大数据挖掘,即使大数据挖掘的再精细也是一个漫长的过程,所谓效率决定一切!

专栏作家

赵文彪,公众号:用户运营观察(ID:yunyingguancha),人人都是产品经理专栏作家。用户运营、私域流量营销领域的资深从业者,专注分享场景化用户运营、社群营销的干货文章及独特见解。

本文原创发布于人人都是产品经理。未经许可,禁止转载

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

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