用户召回体系如何实现自动化

　　运营的最高境界是搭建好各版块运营模型，稳定可复用；然后团队价值溢出，去尝试更有意义的新事情，那么如何搭建一个不一样的用户流失召回体系？
　　一、用户回流策略
　　用户回流相应的策略及体系是一个大课题，从运营高度上我们可以划分为两个主方向：
　　1。做好产品活跃止流
　　不管你的产品流量池目前是大还是小，如果前面不能做好环环相扣的各项产品运营工作，后期，产品承担的流失召回成本就会越来越高。
　　一千条短信没多少钱，但每月3W、5W的短信成本就是显性的运营开支。
　　2。搭建流失召回体系
　　产品总是不断迭代，用户生命周期总会越来越长，将不断迭代的产品跟用户生命周期各阶段相匹配，流失率就会降低并保持稳定。
　　其次，早期，快速用最小化成本试错，制定或探索出有效的流失召回策略；后期，运营召回成本及团队压力就会逐渐最小化并保持稳定。
　　多说一句：运营的最高境界，不是一直重复的做活动、做留存、做召回等等，而是搭建好各版块运营模型，稳定可复用；然后团队价值溢出，去尝试更有意义的新事情，不是吗？
　　这里主要跟大家聊一聊后者，如何搭建一个不一样的用户流失召回体系？
　　在开始之前，我们还要先来了解下常见的召回触达渠道都有哪些特点：
　　二、用户触达渠道的选择
　　常见的召回渠道主要有push、短信、邮件三个渠道，各有优劣，需根据自身产品组合来打。
　　（1）短信
　　短信召回优势主要在于到达率高，对于召回已经卸载了APP的用户无疑是最好的选择。但由于短信召回存在发送成本，故在进行短信召回时，尽量筛选出更容易召回的人群，提高召回率，减少无效投入；
　　否则，大批量进行短信召回，会有一小部分非核心用户觉得自己的隐私被泄露了，频繁触达可能会产生一些负面情绪及影响（例如：在贴吧或论坛等多种渠道进行吐槽，该隐性成本也要考量）。
　　（2）邮件
　　邮件主要优势为无成本、量大。在国外邮件召回是较为普遍的方式，但由于国内用户的邮箱使用率较低，普通用户的使用率更是不高，所以我觉得SAAS教育类产品可尝试此种方式。
　　（3）APPpush
　　APP推送是日常最常见也是大家应用最多的一种推送方式，其优势主要为打开率高、无成本。
　　但由于其优势明显，所以该触达方式常常被某些产品滥用。如果用户被归为流失用户，但暂未卸载APP，这时候就对用户进行消息推送，进行沉默召回。
　　值得注意的是：不恰当的时间推送以及高频率的推送，会令用户反感，严重的还会直接卸载APP。
　　清楚了常见的三种用户触达渠道，那如何召回流失用户呢？
　　首要前提是：你现在能清楚地定义它！
　　三、梳理用户分类及流失定义
　　我司产品用户分类：基础版
　　（1）用户分类：每款产品根据用户量级不同，会划分为多层级和多维度用户角色，这里不展开叙述讨论。
　　以我司产品为例：用户基础分类可拆解为新用户（注册试用期内）、老用户（已开通付费会员）；
　　（2）流失定义：根据产品核心功能、指标行为等触发定义，来判断用户当前是否有消极沉默流失等状态。然后，根据时间波段进行引导、回流等动作，就一般行业而言，触发维度在3天、5天、7天、14天、30天等频次。
　　现在，你对产品的用户进行了分层及流失定义，那下一步就要思考的是：要怎么做，才能够让这个用户回来呢？
　　别急，我们不妨先来看看：他之前都在产品上都做了什么？再来思考他为什么要走？
　　四、结合用户画像，制定行为标签化
　　简单来说，这里的就是建立用户画像的精细化行为标签，可从四个维度进行划分：
　　用户属性：指用户的基础客观属性。比如：性别、年龄、地域、职业等。这一维度告诉了我们他是谁，帮助下一步制定推送文案：男生还是女生；20岁还是30岁；上班族还是学生，你的文案都不可能一样。
　　用户状态：指用户在产品上的当前状态。比如：是上图所示的免费流失用户、付费到期流失用户还是活跃有沉默预警用户等，这一维度告诉了我们哪些用户促发了哪些预警。
　　用户等级：指用户在产品内的活跃状态。按活跃度可将用户划分为高中低用户，按付费金额可将用户细分为高付费中付费低付费用户群或年卡季卡月卡用户等，这一维度告诉了我们他在平台上的价值。
　　用户行为：指用户在产品上有发生过重要行为。比如：有多次参与活动偏好（爱好交流及分享，对福利、免费、限量等标题敏感）、会员价格敏感偏好（在折扣促销的情况下进行多次续费购买，这就属于价格驱动）、活跃周期固定（用户有固定使用产品习惯，比如：周末在线时间会高于平日或仅在晚上活跃）等，这一维度告诉了我们用户在产品上的重要行为。
　　好了，截止到现在，你已经梳理清楚了什么是流失用户以及流失用户最后停留的行为状态，下面就开始搭建起自动化召回体系吧！
　　五、用户召回体系自动化
　　（该用户池分类为作者原创，思维图禁止用做商业用途，请勿转载）
　　1。用户池分类
　　（1）用户池：故名思议，用户池是整个产品体系的用户流量聚集池。
　　（2）预警池：当某一用户触达预警，系统将会自动筛选归类到预警池，并根据事先运营制定好的规则（推送文案及频次）进行自动化触达。
　　（3）维护池：当流失用户接收到短信召回文案后，并在3日内回流。
　　此时，系统不应将该用户自动归类到正常用户池内，我将其单拎出来，放进维护池，进行7日观察，以此进行监控：是否会二次流失？是否行为正常？是否较之前活跃等指标。
　　假如该用户回流表现稳定，则会回归用户池；如二次流失，则会进入流失池。
　　（4）流失池：主要放置二次或以上流失用户、30天以上触达未回流、零价值用户等，该类用户对产品无明显价值，因此不必浪费短信成本，应做好运营资源规划。
　　2。为什么要做用户池划分
　　（1）传统召回模型中，用户是从新增活跃流失召回来进行定义，但仔细想想，等到用户走掉了再召回还是在用户准备起身离开时就进行挽留，哪个几率会更大？
　　等到流失才进行下一步动作，是粗放式运营思维。
　　正确的运营思路是我全都要！
　　这就回到了开篇讲到的开源止流模块，通过数据我们可以对用户进行活跃监控，我举两个简单的例子：
　　用户连续四周，保持每周天活跃（触发关键行为），上周为天，该周为天。该用户有沉默或流失可能性，结合产品整体用户生命周期，可进行触发。
　　用户会员即将在三天后到期，连续两日登录未续费，是否有潜在流失行为，可进行触发。
　　通过止流召回双引擎模式，将会大大增加传统思维的召回率，这一板块按住不表，另开一篇。
　　（2）预警用户进入预警池，后台这时自动根据用户的当前状态及行为标签，进行分群，这一点类似PMF模型，但维度更精细化：
　　免费用户行为及标签较为单一，可以不多维度拆分。
　　付费用户可参照PMF模型进行多维度搭配，根据产品用户量级而定，一般8或16即可。
　　分群后，对低价值标签、维度用户进行清洗处理，例如：近30天低活跃、未付费、未参加活动、未触发核心功能等，该用户召回后也无法为产品带来价值，不建议浪费预算。
　　以此类推，触发预警行为放入预警池分类短信自触发。如此一来，就无需运营天天、周周、月月拉短信名单编辑短信文案提交触发，大大减少人工成本和时间。
　　（3）当用户通过短信链接或短信文案被召回后，不应直接正常回归用户池，为什么呢？
　　比如：用户召回后，此时系统会自动标记该用户为正常用户。假如七日内，该用户再次触发沉默或流失行为，又会自动对其进行一波短信触发，不适合精细化运营模式。
　　流失召回用户一般具有不稳定性。传统召回模型中，被召回用户触发短信后，日回流都算是召回成功。但该类用户日内是否二次流失？要不要跟进观察？算不算一个有效召回？需运营来回答。
　　如果你同意以上我的运营思维，那该维护池具有以下两个用途：
　　对召回用户进行统一放置，观察召回后七日行为，以此判断短信触达的文案、活动、产品引导等流程是否最优。
　　对召回用户进行统一放置，可区分：哪些用户七日内留存下来、哪些二次流失；七日内分别触发哪些行为，导致该结果相左，是否可引导用户进行啊哈时刻。
　　（4）如果维护池用户回流后的37日再次出现流失行为，则该类用户对产品无明显需求，反之也无意义，应该永久丢进流失池；如果将其归类正常用户，多频次短信还会造成骚扰，反倒对产品品牌不利。
　　六、设计有针对性的文案
　　将预警池用户进行清洗分群后，现在需要我们有不同的推送文案或活动刺激召回，我以自家产品为例，简要说明如下：
　　1。标题性内容
　　你知道一条短信内容字数的上限，但我知道一条短信推送出去，在常见机型内信息栏未打开的情况下，最多会显示多少字数，这个你肯定没统计过（其实，精细化运营不是做大事手起刀落，这才是精细化）。
　　因此，短信除了第一段必须自带产品名称外，后一段就要学会善用福利、限量、免费、促销、活动等较抢眼的字词，增加活动、会员到期这类用户的点开率。
　　2。联系性内容
　　对于活动标签用户使用较为常用的抢眼字外，对于活跃度高且会员未到期用户，更有效的还是让内容与用户需求进行连接。
　　简单评估来说，这类用户一般是因为产品体验及功能有暂时性问题，进入了短期休眠状态，可尝试最新、更新、迭代、修复等具有产品属性相关词。
　　3。表白性内容
　　当通过上诉内容进行召回后，用户仍无动于衷且已流失长达30天以上，该用户可自动放入流失池内，避免短信骚扰和成本浪费，因为该用户已明确态度。
　　最后一次短信可主打感情牌，既然无法成为朋友也要为自家产品留下一个好的印象：有温度、人性化，而不是那种到最后还疯狂推短信的产品。
　　例如：小主，您离开好久啦，小管家很感谢您对的使用和支持，忍不住悄悄为您续上了7天会员，期待您随时回来！要开心哦
　　更多内容触达效果，大家可根据产品调性多做文案及落地页活动AB测试即可。
　　最后，对于短信推送时间节点的把控，一般传统情况下会在1921点左右的时间段，你也可以根据自家产品用户活跃峰值段来进行自定义测试。还是同上，多改文案、多做测试，依照数据说话，直到最优。
　　读我文章的读者都知道，我的每篇文章都依据自身产品运营实战操盘经验而来，分享出来亦是对自身工作的复盘总结。因此，带数据讲实话，是我的文章调性及承诺；拒绝通篇理论见解，带领读者臆想。说一通不如附上自己一张图：
　　附部分产品流失召回体系回流效果，仅短信召回端