乔巴：公司领导让我规划用户画像体系，我之前从没做过，现在感觉就像丈二和尚摸不着头脑。用户画像体系规划是怎样的？整个画像体系有哪些模块？在实施过程中先做哪些，后做哪些？需要哪些人来参与，协作流程是怎样的？有没有一些模板可以套用？   索隆：你现在遇到的这些问题确实很多人都遇到过，用户画像这个词很热火，但是市面上能够有能力做用户画像的公司还很少，相关专业的人也较少，因此缺乏专业的知识体系。接下来，我系统性介绍一下用户画像体系产品规划过程，圈出过程中要把握的中心要点。   乔巴：好呀好呀，搬个小板凳坐着听。   01 一个中心，一条主线 建设画像体系，最主要的是把握一个中心，一条主线。   一个中心 一个中心，以经济建设为中心。这是国家向前发展的要义，企业存活的基础，自然也是用户画像部门存在的立根之本。建立用户画像体系本质上是要服务商业活动，需要秉持“降本提效创收”的基本准则。   一条主线 一条主线，产品研发的基本流程主线。建立画像体系在实施层面，本质上是一个产品化的过程，因此用户画像体系的搭建符合产品研发的基本套路，分为需求阶段、画像产品规划阶段、画像产品设计阶段、开发测试阶段、运营阶段5大阶段。   1.需求阶段：注重内外相济，把握3个要点。 一是调研业务方的需求，明确业务的需求是什么，为什么要搭画像体系，打算怎么用？此步骤十分重要，紧紧围绕着1个中心来开展，草帽小子之前写到了需求调研阶段的相关文章《数据产品索隆，坎坷的标签体系建设之路》   二是盘点清楚底层的数据，清晰的知道跟用户相关的数据渠道来源有哪些，落在哪些表里？有哪些数据分类？详情可查看《标签构建过程中，如何快速盘点业务及数据需求？》   三是放眼外界，看市面上优秀的画像产品是如何搭建的？整个画像体系有哪几个常用模块？每个模块的建设过程是怎样的？草帽小子调研了画像体系中不可或缺的3个模块，包含ID体系、标签体系、画像系统，详情可查看《阿里/网易/美团/58用户画像中的ID体系建设》、《干货 | 阿里/网易/汽车之家画像标签体系》、《如何构建用户画像系统？》   需求调研清楚后，你的脑子里对整个画像体系也就有了基础的认识，再结合公司的实际情况进行分析，因地制宜，来制定下一步的产品规划。   2.产品规划阶段：一头一尾两手抓，把握整体架构，制定执行计划。 一头抓整体规划，包含业务架构和产品架构。一尾抓落地计划，包含产品阶段性计划，人员配合流程。   3.产品设计阶段：清晰落地，把握流程规范，注重功能设计。 4.开发测试阶段：规范作业 5.运营阶段：持续监控运营效果   后续文章会展开用户画像设计、开发测试运营等细节，接下来主要介绍如何做好用户画像产品规划。   02 一头抓整体规划 要做好用户画像产品规划，一头抓整体规划，绘制蓝图，包含自上而下来梳理业务架构、以及自下而上来梳理产品架构。   01 业务架构 从框架层来看，梳理清晰的业务架构，有助于帮助产品经理清晰的了解用户有哪些，解决了用户什么问题？产品的价值，产品的功能优先级？以及要做成这个产品需要哪些资源投入？   下边就由草帽小子来介绍如何采用“六层次”方法，进行业务架构的梳理。   整个业务框架围绕着两方面展开，一方面是用户需求，用户在什么场景下使用画像服务，解决了什么问题，或是说给用户带来了哪些价值；另一方面是画像产品实现，要实现该画像产品服务需要哪些资源，需要哪些部门协同配合。   1.用户场景价值层 明确目标用户，清晰地知道画像体系设计出来后给谁用，通常画像体系的目标用户有精准营销人员、产品经理、搜索推荐产研、用户运营人员、客服人员等。用户画像体系的应用场景上包含精准广告投放、智能运营、个性化推荐等。   a.精准广告投放 用户画像在精准广告投放过程中至关重要，画像可以完美地抽象出一个用户的全貌，为进一步精准、快速的预测用户行为提供了全面的数据基础。 早在2007年，雅虎就根据画像标签，推出了smartads广告方案。雅虎掌握了海量用户信息，如用户性别、年龄、收入水平、地理位置及生活方式等，再加上对用户搜索、浏览行为的记录，使得雅虎可以为用户呈现个性化的横幅广告。这是画像在独立广告平台上的应用。   那对于企业来说，使用用户画像进行广告投放，可以精准触达目标用户，提升广告点击到激活转化率，降低广告投放成本。   b.智能运营 传统的运营采用无差别营销、轰炸式营销的方式，对每个潜在的用户一而再、再而三地推送同样的信息。从用户角度来看，用户对这种轰炸式营销十分反感，用户体验差；从企业的角度看，这是对企业成本的极大浪费，隐形成本开销巨大。 如何将合适的内容在合适的时间，用合适的方式推送给合适的用户？这是困扰运营的一个问题。 而用户画像平台，可利用其人群标签能力，帮助运营结合市场、渠道、用户行为，对用户展开有针对性的运营活动。其中端内触达人群，可采用个性化推荐的方式；端外触达可采用push/短信推送的方式。 c.个性化推荐 应用的运营者，可以通过个推用户画像中的性别、年龄段、兴趣爱好、浏览购买行为等标签，给用户推荐不同的内容。如今日头条上的个性化文章内容推荐、抖音上基于用户画像做的个性化视频内容推荐、淘宝上基于用户浏览行为等画像数据做的个性化商品推荐等。    2.产品运营资源层 a.产品/服务层 梳理清楚了用户在哪些场景使用画像产品，那画像能提供的核心功能也就十分清晰了，其核心在于数据采集、用户ID标识、标签体系、画像系统。   b.运营管理层 而要实现这个庞大的画像体系，需要多方协作完成。在组织层面，包含产研团队、运营团队；在绩效层面，需要对清楚组织的绩效目标，多方协作发力；在系统层面，列举出画像体系相关联的系统；在流程层面，需考虑整体研发流程，画像体系与其他业务业务系统的对接流程；   c.资源层 考虑到哪些人来做，服务器资源成本，是否需要购买第三方数据等。   02 产品架构 业务架构会更加宏观，并注重自上而下，从业务场景应用层面来进行整体架构的搭建；而到了产品架构这一层面则更注重于落地，自下而上盘点清楚数据现状来搭建用户画像体系，以满足核心业务场景的需要。包含数据采集、ETL数据预处理、数据分析与挖掘、画像系统建设、应用层面。     1.数据采集层 数据采集讲究大而全：要想更全面的描绘用户画像，则需要想法设法采集用户相关的所有数据。     a.业务数据：伴随着业务产生，包含用户的基础信息，在平台上的购买业务数据、评价数据等 b.埋点行为数据：通过埋点的方式，采集到的一些行为数据，如浏览、点击、停留时长等 c.日志数据: 一般是web端日志记录的数据 d.第三方数据：业务线较为单一的情况下，能拿到用户的数据也就不多，这种情况下可以考虑接入第三方数据，如个推数据等，来进一步丰富标签画像   2.数据预处理：对一些不符合标准的数据进行清洗、转换，得到标准数据   3. 数据分析与挖掘：对预处理后的数据进行标签建模，得到具有商业价值的标签。 a. 统一用户ID标识 很多人对用户ID标识没什么概念，在用户画像体系建设之初，往往会漏掉这个关键步骤。   举个简单的场景，阿里是一家包含多条业务线的公司，如电商、金融、广告、文化、教育、娱乐、设备和社交等领域。若是消费者乔巴在支付宝上进行了基金理财操作，同时在钉钉里发布了自己的动态，并在web淘宝上浏览了棉花糖商品。 这个过程他登录了不同的账号，你怎么把这些行为关联到乔巴身上呢？   这里要做的就是统一ID标识，详情可以参考阿里、美团、网易这类的大厂都是怎么建设的《阿里/网易/美团/58用户画像中的ID体系建设》。   b. 用户档案 建设用户档案，前期可进行数仓主题层的建设，将与用户相关的表汇集在一起，建设一个用户集市，包含用户基础信息表、用户行为表、用户交易行为表等基础表。   c. 标签建模 标签建模则包含不同类型的标签的计算，如事实类标签、规则类标签、预测类标签的计算。   d. 标签宽表存储 标签宽表存储主要为将标签数据统一落在几张大宽表中，如用户基础信息宽表、用户行为宽表、用户偏好宽表等。   4.服务层 服务层需描述清晰画像体系能对外提供的服务，包含业务性服务和系统性服务两大类。   a.业务服务 业务服务包含画像系统需具备的能力，分为画像看板、单用户画像、群体用户画像、相似性人群拓展、标签市场、人群洞察、标签管理如标签上下线以及标签的管理、权限管理等。   b.系统服务 系统服务主要为接口服务，将用户分群以接口的形式对接至各个业务系统。 03 一尾抓落地计划 在绘制完浩浩荡荡的用户画像蓝图之后，接下来就需要制定切实可行的项目计划，梳理版本计划等，以申请相关资源。     01 版本计划 整体用户画像体系的搭建涉及面巨大，无法一蹴而就，应循序渐进地进行。在制定版本计划的过程中既需要结合业务当前的需要，争取快准狠的在业务上有所应用，如此才能走的更快；也需要考虑系统基础建设，如此才能走的更远。   用户画像的版本计划可分阶段进行，设定每个版本，如V1.0、V2.0、V3.0的用户画像体系建设目标，迭代的时间计划。并依照二八原则，建设MVP版本，先推出一版，快速满足业务需要。   02 项目计划   确定好产品版本规划后，基本的产品形态也就确定下来了，接下来就需要制定切实可行的项目执行计划。   乔巴：这里我感到十分疑惑，数据产品经理还需要负责项目执行计划吗，这些不是交给项目经理去做就好了？ 索隆，仰天长叹一声，说道：要知在实际项目执行过程中，项目经理难以清楚掌握相关数据需求，所以在整体项目过程中，其执行粒度会比较粗糙，最后项目的执行结果通常不尽人意。 而为了达到目标上线时间，最后砍需求的事也是屡见不鲜。所以数据产品经理还是需要轻装上阵，把握好整体开发测试运营节奏，衔接好每个关键的节点，这样才能最大限度的保护好自己的需求如期上线。   如上图所示，项目执行过程中有4个关键的评审时间点。   一是立项评审，此时需要项目经理/数据产品经理输出立项PPT，主要包含业务背景需求描述、业务架构、产品架构、产品版本计划、项目执行计划、所需资源情况等。   二是需求评审，需要数据产品经理输出详细的需求说明文档，主要包含需求背景、产品流程、功能需求说明、数据需求说明、原型设计等。   三是提测演示，需要数据产品经理/前端演示开发完成的情况，演示前需要保障页面业务流程、数据上报流程可以跑通，无重大问题方可提测，否则就打回继续开发。   四是产品发布，需要相关运营同学输出运营计划，对外介绍产品功能，使用方式，收集用户反馈等。   制定清楚项目计划后，我们来看看做好用户画像整体计划需要哪些人参与，其配合关系又是怎样的。   03 人员配合流程 搭建用户画像体系的产研人员主要包含，运营/业务产品经理、数据产品经理、数据分析师、数仓工程师、算法工程师、前端工程师、后端工程师、数据测试人员、功能测试人员。     运营/业务产品经理：提出画像需求，说明清楚目标用户、场景及价值，提出明确的数据需求，包含所需的标签名、标签含义及分段逻辑。   数据产品经理：分析业务方所提的需求，结合画像体系的整体考虑输出产品方案，并进行标签及画像系统的设计，输出功能及数据需求说明文档。特别注意的是，在进行标签设计时，需与运营/业务产品经理共同确定标签逻辑，在验收时也需与业务方协同验收。   数仓/算法/前后端工程师：数仓工程师主要负责数据仓库结构的设计，数据表设计，以及事实类、统计类标签的计算；算法工程师主要负责算法预测类标签的计算；前后端工程师主要负责画像系统功能层面的建设。   测试工程师：主要负责系统功能层面的测试，以及标签数据层面的测试。   04 总结 总结而言，用户画像体系产品规划的重点在于一头一尾两手抓，一头绘制整体架构的蓝图，一尾制定清晰的执行计划。   一头抓整体规划，包含业务架构和产品架构，先自上而下从业务场景应用层面来进行整体架构的搭建；再自下而上，盘点清楚数据现状来搭建用户画像体系，以满足核心业务场景的需要 。   一尾抓落地计划，包含产品阶段性计划，项目执行计划以及人员配合流程等，来保障用户画像体系规划按一定的节奏落实下来。

—————— BEGIN —————— 花花是某电商公司的一名产品运营，如果新上线一款产品他的一贯做法都是做活动、蹭热点、做营销等等。但是，这些做法引来了大量的羊毛党，获取的真实客户却是屈指可数。   正在花花为此事头疼之际，同组的前辈豆豆给他支个招，运用 AHP 和 RFM 构建用户评分体系，精细化运营，能带来很好的效果。开心之余，花花赶紧使用度娘搜索，AHP 和 RFM 究竟是什么东西？又怎么运用呢？接下来作者就给你唠叨唠叨。   1 AHP制定权重   1.1 AHP是什么？ 层次分析法（Analytic Hierarchy Process）简称 AHP，20 世纪 70 年代中期由美国运筹学家托马斯·塞蒂（T·L·Saaty）提出。   AHP 是指将与决策有关的元素分解成目标、准则、方法等层次，主要用于定性的问题进行定量化分析决策。   比如，某电商平台根据用户行为数据对用户做综合评分模型，找出忠诚用户、活跃用户、沉默用户等等，进而对各类用户进行精细化运营。   1.2 AHP基本原理 AHP 的思路是密切的和决策者的主观判断以及推理联系起来，也就是对决策者的推理或者判断过程进行量化，从而避免决策者在结构复杂或方案较多时逻辑推理失误。具体步骤如下： 1）建立评分体系 构建用户价值评分体系，对各类用户进行精细化运营。   设定目标，列出影响目标的所有元素。采用专家打分、用户问卷等方式，逐一列出所有的影响因素，比如活跃度、忠诚度、购买力等。   2）构建层次结构、判断矩阵 列出影响因素的指标或方案。 判断影响用户活跃度的指标有浏览页面次数、停留时长、浏览商品次数、下单次数。 判断影响用户忠诚度的指标有最近访问时间、访问频率、主动评价次数。 判断影响用户购买力的指标有单笔最高金额、平均订单金额、购买次数。   3）算出权重系数 分别算出各个指标层、准则层的指标权重，然后再算出决策公式（如下图）。   4）一致性校验 若一致性指标 CR<0.1，就进入下一环节；否则，对各指标权重重新赋值（即，重新构建判断矩阵）。   5）层次排序 层次排序分为层次单排序和层次总排序。所谓层次单排序，指对于上一层某因素而言，本层次各因素的重要性的排序；所谓层次总排序，指确定某层所有因素总目标相对重要性的排序权值过程。   层次排序是从最高层到最底层依次进行的。对于最高层次而言，其层次单排序的结果也是总排序的结果。   1.3 确定权重 1.3.1 构建判断矩阵 在确定各层次各因素间的权重时，如果仅是定性的结果，则通常不容易被其他人接受，因而 Saaty 提出一致性矩阵法，即两两因素相互比较，采用标度，尽可能减少不同因素相互比较的困难，以提高准确度。   运用专家打分将所有因素两两比较确定合适的标度。建立层次结构后，比较因子及下属指标的各个比重，实现定性向定量转化。   比如，采用 1-9 分标度法，构建决策层的打分矩阵 A，如下图。 实际上，上述打分矩阵就是层次分析法中的判断矩阵。   1.3.2 一致性检验 一致性检验是为了检验各元素重要程度之间的协调性，避免出现 A 比 B 重要，B 比 C 重要，而 C 又比 A 重要，这样的矛盾情况。   1）相关理论 （1）一致性矩阵 （2）判断矩阵是否为一致性矩阵   在判断矩阵的构造中，并不要求判断矩阵一定具有一致性，这是由客观事物的复杂性和人的认识多样性决定的。但判断矩阵是计算排序权向量的依据，因此要求判断矩阵应该满足大体上的一致性。   2）对判断矩阵一致性校验 先求解特征向量，采用手工计算方法——和积法：   手工计算矩阵 A 的特征值： （1）求特征向量   （2）求最大特征值 手工求解精确度较低，只是求得最大特征值的近似值。一般情况下，可以采用在线计算工具 Matlab，链接地址：https://wis-ai.com/tools/ahp   （3）一致性校验   1.3.3 计算指标层权重 1）计算活跃度的权重 因此，准则层相对活跃度的权重依次为： 浏览页面次数的权重：b1=0.63231 停留时长的权重：b2=0.21452 浏览商品次数的权重：b3=0.10961 下单次数的权重：b4=0.04357   2）计算忠诚度的权重 因此，准则层相对忠诚度的权重依次为： 最近访问时间的权重：c1=0.61935 访问频率的权重：c2=0.28423 主动评价次数的权重：c3=0.09642   3）计算购买力的权重   因此，准则层相对购买力的权重依次为： 单笔最高金额的权重：d1=0.70706 平均订单金额的权重：d2=0.20141 购买次数的权重：d3=0.09153   4）列出全部权重   5）如果一致性校验没有通过，怎么办？ 作者在实际构建评分矩阵时，发生了好几次一致性校验不通过（如 CR>=0.1）。这可能由于一些主观因素导致，也可能是由于构建模型不合理导致。所以需要专家重新构建打分矩阵，甚至需要重新构建层次分析模型。   （1）构建模型影响 因素是否合理、含义是否清晰、要素间是否重叠，这都会有影响。建议每层要素尽量不超过 7 个；如果元素之间的强度相差很大，尽量不要放在同一个层级。   （2）计算精度影响 特征值求解方法的不同（比如和积法、方根法等）、Excel 计算值的误差、计算工具的误差等，都可能导致一致性校验结果有些偏差，可以使用 Matlab 等精度更高的计算工具（https://wis-ai.com/tools/ahp），如下图。   6）结论 运用 AHP 模型得出和公式： 活跃度=b1*浏览页面次数+b2*停留时长+b3*浏览商品次数+b4*下单次数； 忠诚度=c1*最近访问时间+c2*访问频率+c3*主动评价次数； 购买力=d1*单笔最高金额+d2*平均订单金额+d3*购买次数； 用户价值评分=0.64339*活跃度+0.28284*忠诚度+0.07377*购买力。   AHP 方法使用较少的定量数据，就可以构建模型，最终的结论只能表明因素的重要程度，不能得出用户价值的评分值是多少。   因此，将 RFM 模型和 AHP 模型相结合，算出各个因素的分值，得出每个用户的评分。   2 RFM计算分值   2.1 RFM是什么？ RFM 模型是衡量客户价值和客户创利能力的重要工具和手段。该模型通过一个客户的近期购买行为（Recency）、购买的总体频率（Frequency）以及消费金额（Monetary）3 项指标切分出多类客户，最后根据不同类型客户（如下图）占比情况来评估客户的整体分布，并针对不同类型的客户进行有针对性的营销。   一个 RFM 用户分层模型，重要发展客户到底多少分？一般价值客户多少分？作者将用某电商公司 2018 年 11 月 1 日-2019 年 4 月 30 日共 5 个月的交易数据来讲述，为了保护隐私，数据经过脱敏处理。   2.2 构建RFM模型的步骤 2.2.1 获取与清洗数据 RFM 模型主要用于分析用户购买行为，通常获得的数据包含付款时间、实付金额、订单状态等等信息的数据，部分数据如下图。   获得数据后，其中可能存在空值、异常值等情况，这类脏数据无法进行分析，需要通过简单的数据清洗去除。数据清洗的方式有两类：异常值处理，如删除、均值补差等；异常值识别，如按业务规则查找、语义冲突等。   比如，作者获得交易数据后，发现 “发货时间” 为空，是脏数据，需要剔除；对应 “订单状态” 的值是 “付款以后用户退款成功，交易自动关闭”，退款用户数据不该纳入模型，需要去除。   清洗完之后，分别对 “发货时间”、“订单状态” 进行筛选，这时发现 “发货时间” 为空或订单状态为 “付款以后用户退款成功，交易自动关闭” 这类数据已经不存在了，说明已经筛选干净了。   2.2.2 建立模型 接下来，作者需要提取 R、F、M 的值：R（最近一次购买距今天的天数）、F（购买了几次）和 M（平均购买金额）。   构建一张透视表，将 “买家昵称” 分别拖到行位置和值位置，对 “买家昵称” 进行计数汇总，也就是得出买家的消费次数，即 F 值。将 “付款时间” 拖到值位置，设为最大值，将 “实付金额” 拖到值位置，设为平均值，即 M 值，如下图。   将初步透视好的数据复制到一张新的表格（选择性粘贴「值和数字格式」）。接着处理 R 的值，由于订单截止日期是 2019 年 4 月 30 日，作者将建模时间设为 2019 年 5 月 1 日，求距离 5 月 1 日这一天客户最近一次付款时间的间隔天数，就是求每个客户的 R 值，如下图。   用 RFM 的计算方式，对所有因素（R、F、M）进行 0-5 评分区段的映射。   或者用下面的公式归一化处理（如下图），正相关使用第一个公式，负相关使用第二个公式，R 属于负相关，因为最近一次购买时间距越小，那么越重要。F 和 M 都是正相关。   规范化计算也可以使用 (X-Xmin)/均值(X) 和 (Xmax-X)/均值(X) ，需要注意的是，如果真实数据分布不平均的话，均值就可能出现偏差，比如有人消费 100 万元，有人消费 1000 元，平均数的偏差就很大。所以，可以使用三分位、中位数或者（Xmax-Xmin）等方式进行归一化。   由于获取的数据字段有限，无法通过指标层得到准则层的权重，所以直接使用 AHP 算出活跃度、忠诚度和购买力的权重，依次分别是 0.64339、0.28284、0.07377。得出标准化的数据以及一定权重的用户价值，如下图。   把 R、F、M、用户价值按照 0、1 区分，如果大于均值为 1，否则为 0，得到 16 种用户类型，如下图。   将用户类型代入数据中，得出的部分结果，如下图。   2.3 模型可视化 2.3.1 分析各类客户占比 对刚刚完成 RFM 模型表格进行透视，将 “客户类型” 拖至行区域，再把 “客户类型” 拖至值区域两次，第一次是为了计数，第二次是为了查看客户占比，如下图。   绘图，更清晰的查看不同客户类型的用户数占比，如下图。   2.3.2 分析客户金额占比 对 RFM 模型表格进行透视，将 “客户类型” 拖至行区域，再把 “累计金额” 拖至值区域两次，第一次是为了计算每类客户的累计消费金额，第二次是为了查看每类客户的金额占比，如下图。   绘图，更清晰的查看不同客户类型的金额占比，如下图。     3 总结与建议   1）从各类客户占比图中看出，次一般挽留客户（0000）的人数最高，竟达 8725 人，人数占比 34.52%，此类客户近期没有购买，购买频次低于平均值，下单平均金额比较低，并且用户价值也较低，大约在 2018 年 双11 下的单，属于价格敏感性客户，所以可以在促销活动（如国庆节、六一等）时试着唤醒他们。   2）次重要挽留客户（0010），最近没有购买商品，消费频率较低，消费金额较大的一类客户，有 6905 人，人数占比 27.16%，支付金额占比最高。换句话说，对于该商家销售额贡献率最高的一批客户，下单时间远，购买次数低，已经处于流失的边缘，但是不同于次一般挽留客户，这类客户的平均销售额较高。   对于这类客户，运营人员需要获取他们的联系方式，进行回访，询问客户沉睡的原因；或者说商品本身就属于复购率低、消费金额占比高的商品；或者从商品本身入手，试着比较客户购买时间与商品的回购日期，是不是上次购买的商品还没有用完。   3）重要发展客户（1011），最近购买，购买频次低，消费金额大，用户价值大的客户有 2614 人，占总人数的 20.28%，支付金额相对较高。这类客户大致是新客户。   对于这类客户，运营人员近期适当的进行短信推送，优惠券发放等形式，来提高他们的购买频率，争取提高这类用户的忠诚度，最终将他们转变成重要价值客户。  

01 选品的场景 又见面了，我是热情依旧但一不小心就拖稿的Snowki。 这次想和大家聊聊选品，选品其实是一个“宝藏”话题，你深入探索后会发现需要学习的东西越来越多，应接不暇。我仅能在有限的认知下，说说自己的理解，供大家开拓思路，或者娱乐也行。   选品包含了很多大的场景，常见的有以下： 电商平台选品推荐。 根据商品画像和用户画像做千人千面推荐 电商小B型商家选品。 这在网上能找到很多相关信息，教大家如何根据市场热度、用户需求和心智，再结合一些分析套路选对热品，“发家致富”。 例如亚马逊上火了的中国痰盂-老外尊享水壶（虽然好笑但很成功的例子） 新零售选品。 新零售概念很抽象，炒的也热（题外话，对新零售概念感兴趣的同学可以读读刘润老师写的《新零售： 低价高效的数据赋能之路》，算比较通俗易懂的），比较主流的模式为线上线下一体化，选出的商品大多同时满足线上和线下场景的售卖，同质同价，比如盒马、便利蜂，售卖生鲜日百等生活相关的商品，并有线下本地商超。   不同场景的选品策略、限制条件、影响因素等都大相径庭，需要细化场景，分开详述。本篇选品策略适用于有本地商超的大B商家，并在线上售卖日常消费品的新零售场景。   02 案例和基础概念 新晋产品汪Snowki进入商品管理部门后，老板给了她首个任务：现有一个大卖场和一个便利店，线上线下销售表现均不理想，看看能否通过选品策略结合算法，调整品类结构，选出优质单品，牛转乾坤。   品类？单品？大卖场和便利店又有什么区别？又如何量化复杂的业务场景？别急，我们结合案例往下看。   单品 也可以理解为SKU，即可售卖/库存的最小标准单位，选品也以此为单位。它和商品不太一样，举个例子，农夫山泉纯净水是商品，它下面有不同规格属性，通过属性确认唯一单品，一瓶农夫山泉纯净水1.5L即是一个单品。   品类 零售管理的核心，它不是按照商品原材料归类，而是将满足用户相似需求的商品逐级分类，这样能更有效、灵活地做出调整，顺应市场需求。例如，婴儿用品传统上分散于食品、服装、纸品等品类，但随着这部分商品销售贡献越来越庞大，逐步形成了新品类-孕婴童。   大卖场 可以理解为大型综合超市，占地面积很大，有2、3层购物空间的线下实体店，靠近生活区，有可能坐落郊区，常见的有沃尔玛、家乐福，经营商品基本满足用户全部所需，可售上万不同的单品。   便利店 面积小，经营小规格酒水饮料零食等便民商品，靠近学校、CBD、小区等人流量大的地方，开店密度高，常见的有711、全家、便利蜂。   03 解析案例，明确策略产品的核心价值 案例中涉及到4个选品场景，大卖场线下、线上分别售卖什么？便利店的线上、线下分别售卖什么？需要根据不同场景选出建议售卖的商品清单。我作为一个不会复杂建模的“低配版”策略产品，与算法工程师的分工大致如下： 而策略产品最核心作用便是对业务的深度理解，如何将抽象的业务场景量化为可供算法工程师参考的选品逻辑框架。   04 初识零售选品 传统的零售选品，大多依靠人为经验判断，数据在其中至多起到辅助作用。例如日本的711便利店，定期会举办选品大会，品类部门选出主营商品供同台竞技，对于自有品牌的快餐鲜食，高级主管们会亲自参与品尝，如有异议，品类部门再拿出历史或市场数据作为佐证。这样选品存在的问题很明显： 耗时耗人，每次选品大会前1个月品类部门便开始准备商品清单，往往选品大会一开就是一天，遇到换季或市场变动大时甚至需要一周 按照人的经验判断存在主观性和信息滞后，可能会疏忽市场最新变化，错失商机   算法选品，则是数据先行，人工审核为辅。将限制条件、内&外部影响因素、商品标签等相关参数投喂给模型，让模型给出推荐方案。目前做算法选品极具代表性的是便利蜂，通过算法模型推荐上架商品，店长只需要听从系统指示，执行物理操作既可。（题外话，便利蜂不仅用算法选品，还用算法为便利店选址、商品动态调价，面试还有可能考挺难的数学题哦~） 算法选品的解决了传统选品存在的诟病，虽然初期模型计算结果不太稳定，但随着机器不断学习和数据训练，选品效果不会差于选品专家，长远来看它的优势不容小觑： 节省人力成本，缩减选品耗时，品类部门可以从重复的选品低效劳动中释放出来 不依赖于人的经验判断，减少出错率   05 构建选品策略 便于理解，我画了一个简单的选品逻辑示意图，实际算法会比这个更复杂，需要结合很多业务细节。 商品库 B端商家有渠道、可采购的商品总池，不一定正常在售，甚至不一定经营过的新品，作为基础数据供算法处理、选择。   限制条件 在选品前，需要明确一些业务限制或要求作为前置条件，不满足这些条件的单品或品类不会进入后续的选品。常见限制条件有： 单品数上限： 影响算法选品的单品总数。 线下选品数有门店物理空间、货架数限制，大卖场一般上万个单品，例如沃尔玛大卖场经营3~5W个单品； 便利店由于面积狭小，一般上架2000-3000个单品； 而线上选品虽然没有空间和货架限制，但是考虑用户在手机上选购时商品曝光率和配送成本问题，一般单品数控制在1500-5000 品类覆盖率： 大卖场线下基本要求品类全覆盖，应有尽有； 便利店线下的品类基本覆盖在休闲食品、酒水饮料，而大型电器、衣服鞋帽等无需经营覆盖 规格带覆盖： 大卖场售卖规格繁多，基本没有限制； 便利店受面积和用户需求影响，售卖规格小； 线上选品大规格的单品更受青睐 价格带覆盖： 受商家定位影响，例如山姆超市定位高端，进口商品多，价格带偏高； 物美超市主打中低端价格敏感用户，因而价格带偏低   影响选品因素 影响选品的因素有很多，且不同品类受到影响程度不同，例如冰淇淋受季节影响大，但卫生纸则不受季节影响。因此在用影响因素搭建选品模型时，需先将品类分为几类角色（或者可以理解为商品标签）再进行不同策略的选品： 季节品： 供需受季节强影响，最具代表性的： 生鲜果蔬 节日品： 用户需求受节日强影响，具代表性： 巧克力、红酒、计生用品（咳，情人节） 核心热卖品： 一年四季均可上架，为品类贡献80%的销售，具有市场竞争力，甚至代表商家形象，例如： 盒马的海鲜 新品： 之前没有售卖，但是市场数据或需求趋势表明可以带来一定价值 必备品： 商品销售表现不一定优异，甚至垫底，但不能不选，因为缺少了会给客户带来在架物品不全的印象，例如牙签 品牌感知度高品： 在购买时用户决策树受品牌影响，例如，饮用水用户倾向选择农夫山泉、怡宝等知名大品牌   根据这几大类再去做影响因子的权重配比（根据商家要求及关注度、业务实际场景考虑），常见几种会影响选品决策的因子： 从商品维度： 既往销售指标： 针对已经营过商品的销售量、销售额、毛利、销售增长、动效率... 投入产出比指标： 投入多少促销力度、陈列资源，获得多少销售反馈。 例如盒马将线上和线下表现合在一起创造坪效奇迹 市场调研、舆情数据： 这个主要针对于新品的挖掘，通过外部舆情分析获得市场最新变化趋势，结合竞争对手热卖，对新品选择策略的影响权重高。 例一些网红商品 商圈表现： 这个主要针对线下选品，根据门店所处位置强化某品类的单品配比，例如位于学校附近的门店售卖文具较多，CBD附近的门店售卖加工熟食、快餐较多   从用户行为表现维度： 关联购买： 通过用户经常一起购买商品选出组合销售或关联陈列的商品，尿布和啤酒的经典案例不用我说啦。 线上有很好的优势，例如我们逛某品A的时候，下面会有推荐文案： xx%的用户也会购买B。 提醒我们买全商品，并带来更多付费 复购数据： 从用户的复购行为、购买频率，得到高复购、高频购买商品，商家喜欢这样的商品，可以为他们重复制造价值 用户近期线上搜索行为数据： 即代表近期用户需求、市场热度趋势，又能强关联影响线上选品。 例如热搜（疫情期间口罩、消毒酒精）、搜索无果（代表当前选品未满足用户所需）、搜索增长（代表市场变化趋势，可提早警觉） 用户近期线上点击行为数据： 这部分数据可以用于调试模型，增加算法逻辑及参数。 这个理解稍微困难些，举个例子说明，如果用户在洗发品类下更多倾向于点击功效（防脱、柔顺、去屑等）进行选择，其次品牌、规格，那在选品时，洗发品类的影响因子权重会调整为： 功效>品牌>规格   建议售卖商品 如何通过选品决策和算法模型得到建议售卖的商品清单。通俗来说，通过一些前置条件进行选品限制，再结合不同业务场景、不同商品属性标签，在多种影响因子作用下，从商品库中选出建议上架商品，并获得更高收益。   06 效果复盘，数据反哺 完成选品决策后，很关键也很容易被忽略的一步便是对选品效果复盘，可参考销售增长表现，并将表现差强人意的品类拿出来，单独下钻具体单品数据，根据失败数据调整模型，并将反哺更多数据便于机器学习。

01 留存怎么算 “留存不就是用户在未来xx天的使用情况么，比如第一天拉新1000，第二天有100个人来了，留存率10%。” 这个算法本身没有问题，就比如前文中的一个例子：   有一个鼓励试用的活动持续2天，我们来看3日留存率的计算。 10月1日，1000人试用；第一天这1000人中300登陆CRM软件；第二天，有200人登陆CRM软件；第三天，有150人登陆CRM系统。 10月2日，1500人试用；第一天有400人登陆CRM软件；第二天有200人登陆CRM软件；第三天有150人登陆CRM系统。   那么针对10月1日和10月2日这两天的活动，三天的留存率分别是这样的（蓝色内容所示）:   但是要反映整体活动的3天留存率，应该怎么计算呢。我的方法是，把这几天活动中第X天的留存总人数，除以这几天拉新的总人数，即： 第一天整体的留存率为： 第一天的留存的总人数之和/这几天活动拉新的总人数 第二天整体的留存率为： 第二天的留存的总人数之和/这几天活动拉新的总人数 …… 以此类推，如下图中绿色内容所示: 这也是我在上文中提到的方法，然而一位小伙伴提出了他的看法（如果这位小伙伴看到此篇，可以联系我哦~）。   于是我把具体计算方法放在更大群体里讨论，不同的声音出现了，那种情形就像一帮南北方朋友在我家聚餐，我在西红柿炒鸡蛋里准备放糖，被一个北方人看到后大声质疑：“西红柿鸡蛋不要放糖啊”， 然后另外一帮南方人马上回答“啊，当然要放糖啊”。   “留存算同一周期下的平均值会好一点， 不是和的平均，而是百分比的均值”, 所以这里的另外一种方法是这样的，把两天的留存百分比加起来，除以总天数，即： 第一天整体的留存率为： （10月1日的day1留存率+ 10月2日的day1留存率）/2 第二天整体的留存率为： （10月1日的day2留存率+ 10月2日的day3留存率）/2 …… 以此类推（如下图橙色内容所示）:   貌似两种算法看起来结果都差不多，可是又有另外一个声音出现了： “一般情况下两种算法所得值差不了太多，但是如果两天的拉新数量差别很大，留存比率差别也大的情况下，就会出现不一致的情况， 比如下面这个例子，按照第一种方法算出来是2.75%， 第二种方法算出来是46%。”   哇，那要怎么算。“第二种用加权平均去算就好了，权重可以用拉新人数来算。”于是衍生了第三种算法，但仔细一看，按照拉新人数加权算其实和第一种算法是一样的（如下图第三行浅绿色所示）。   此时另外一个声音将话锋转移到一个新的问题：“先不去讨论对错，你们有想过这两种算法在业务应用上的差异点么？忽略场景而言，对绝大多数运营的人来说，肯定会先盯这个数字；因为第一条数据里98%的流失，需要反思的事情太多了，后面的更容易去做策略的落实，有方向和动力。”   所以为了体现这种异常，我们需要全局全细节的留存信息，就回到了最初的阶梯式留存表格，利用热力图将异常值高亮显示（比如下图），让业务人员一眼看到异常来展开分析，并且这些异常值后面往往蕴藏着机会或者风险，或者——bug。   但是，如果要更准确的体现整体活动的3天留存率，我们又需要将这些异常值剔除掉来计算留存率，剔除的方法多种多样（大家可以参考Python 库Pyod的各种算法，在这个Kaggler 分享的PDF中有各种详细算法：https://www.kaggle.com/getting-started/104950）。在剔除异常数据的情况下，无论采用第一种算法或者第二种算法，差别并不大，对于业务的价值是差不多的，如下图所示。嗯，这下问题可以稍作终结了。   然而，关于留存的探讨并没有到此为止, 搞清楚留存计算后，作为一名优秀的数据分析师，既要知道留存数据怎么算，也要知道留存数据怎么用的问题。   02 留存怎么用 搞清留存计算之后，我们问一下，为什么要看留存？千万不要觉得这是产品经理的事情，数据分析师们只有明白了为什么，才能更好的提供准确可靠的数据。留存的用处之一是通过留存率和其他要素的情况下，预估公司收益（这也是数据分析师在面试时经常遇到的问题），但留存数据的用处可远不止于此。   笔者曾经在一篇文章里看到这样一句话 “Without retention, your product is a leaky bucket”，翻译过来是“没有留存，犹如竹篮打水一场空” （或者翻译更形象一点，“没有留存，你的推广就是个无底洞”），好不容易拉新的客户，全部又流出去了。而在互联网下半场的浪潮里，另外一种增长黑客模型早已经浮出水面，即由AARRR 模型转变为RARRA，如下图所示，在RARRA模型中，留存--Retention 首当其冲，即先实现留存，再去做产品推广，让产品自己去运营，实现获客。   张小龙的相信不少人看过，演讲中所提的：“这是一种典型的微信style的产品方法，即通过产品而非运营的方法，找到事情的撬动点，通过产品能力让事情运转起来” 和RARRA的理念高度一致。我们今天就蹭一下热点，用留存的框架“套路”一下微信视频号的成长过程，纯属学习视角的讨论，欢迎大家拍砖留言。   个人认为RARRA增长模型下，产品成长过程中有以下几个阶段，而留存在是这几个阶段都需要关注的指标之一： 找到Market Fit，这个阶段留存分析能帮助产品发现“生存能力”。 培养初期留存用户的使用习惯，持续优化核心功能，这个阶段留存分析能帮助产品发现“基本能力”。 让更多的人看到核心功能，使产品被更广泛的人使用，这个阶段留存分析能帮助产品发现“价值能力”。 详细展开来说一下：   阶段1：找到Market Fit(即产品与市场的契合点)，这个阶段留存分析能帮助产品发现“生存能力”。 微信视频号找到Market Fit 的过程是这样的，“以下摘自张小龙《微信十年》原文”。   “可能在2017年吧...但后来就不了了之了... 第一个版本其实只是搭建了这样一个ID体系，但这样的效果并不好... 但头几个月的滚动特别困难，似乎陷入了死结… （2020年）5月份的时候，我们做了视频号最重大的一个改变...于是五月份发布了基于朋友点赞的新的灰度版本，终于看到了上扬的数据，用户的留存非常高。”   不知道大家看到这个过程是什么感受，我在想，作为业界“顶级产品的顶级产品经理”，都经历了如此多的曲折来尝试新事物，我们又有什么理由不去承担风险，快速试错呢？   那么龙哥所提到的“上扬的数据”是什么呢？什么样的留存曲线算是找到了Market Fit， 如下图所示，绿色代表没有找到Market fit 的留存曲线，蓝色代表找了market fit 的曲线，显示出“上扬”的趋势。当然这个过程并非像这条曲线这样简单，只是为了学习，我将这个曲线做了简化处理。   阶段2：培养初期留存用户的使用习惯，持续优化核心功能，这个阶段留存分析能帮助产品发现“基本能力”。 “以下仍然摘自张小龙《微信十年》原文”。   “所以6月视频号的用户到了一个量级。数字其实不重要，但对于一个内容形态的产品来说，一定量级的用户意味着解决了生死问题，即流量的循环起来了... 有这个用户基数说明生存下来了，这时候就可以开始做基础功能的完善了，比如直播能力等。没有过生死线的话，做再多功能也是白搭。”   注意到没有：“一个量级..数字其实不重要..做基础功能的完善”，意味着在阶段1解决生存问题之后，数字的增长并没有作为重点来看，而是开始做“基础功能的完善”。即在第二个阶段，就是要不断刺激这部分用户持续使用，黏住他们，从而得到长期的留存，所以你看到的简化后的留存曲线的变化可能是这样：   阶段3: 让更多的人看到核心功能，使产品被更广泛的人使用，这个阶段留存分析能帮助产品发现“价值能力”。   这里谈一点我对微信视频号的观察，目前在我周围的人群中，微信视频号的用户占比不算太高，大部分人仍然觉得视频号是像抖音一样是杀时间的机器（目前的确也是）。原谅我周围的人都比较勤奋，不是“围观群众”，不愿意将时间花在消遣类的社交上 。但同时我也看到越来越多的高管、精英人士、原来写公众号的，开始做微信视频号了，趋势是好的。所以，个人感觉微信视频号目前仍然这个阶段3。至于微信视频号能否走好阶段3，未来拭目以待。   那么，在产品的这个阶段，如何利用留存分析帮助产品发现“价值能力”呢？我们大体可以把用户分为新用户、已有用户、已流失用户来分析。   新用户的留存分析：找到能让新用户再次回来的事件（从阶段2中挖掘），利用这个事件改进产品的第一印象，从留存曲线上来说，新用户的留存曲线的变化更倾向于下图这种。当然为了夸大第一印象的作用，我们把这个留存曲线简化了很多。   已有用户的留存分析：可能有些人说，已有用户是不是意味着已经留存下来，就不需要做留存分析了。恰恰相反，这部分用户的留存分析最能体现出产品的核心价值，即利用已有用户的行为痕迹帮助我们理解“产品能给用户带来什么价值”。   拿视频内容产品来举例，使用者可能是希望用视频做品牌宣传，可能是为了找到自己的圈子学习专业领域知识，也可能是为了好玩，可能还有一些我们也看不到的价值。我们按照行为我们把视频内容产品的用户粗略分成两大类（其实还可以细分），创作者和观赏者。针对两类角色我们需要定义不同的留存标准： 1.创作者的留存定义可能是这样的： 留存初始行为是发布视频 留存后续行为是发布视频 时间频率是每周，或者是其他定制化天数 即距离上一次发视频不超过一周（或者是其他定制化天数）又发了一次视频的用户为创作者的留存。   2. 对于观赏者的留存定义可以是这样的： 留存初始行为是观看视频 留存后续行为是观看视频 时间频率是每天，或者是其他定制化天数   即距离上一次看视频不超过1天（或者是其他定制化天数）又看了一次视频的用户为观赏者的留存。 你看到的简化后的留存曲线可能是这样的：   通过对不同行为群体进行留存分析是对产品细分价值的判断，我们可以帮助产品构建出一个健康的增长引擎。   已流失用户的留存分析： 为什么流失的客户还需要留存？ 因为我们需要把老客户拉回来。 有研究表明重新激活老客户实际上比获新客成本更低。 这些用户可能是你在第一阶段获取的用户，因为彼时产品对他们来说价值不大，但到了第三阶段，或许到了一个赢回他们的好时机： 适宜地组织老客户拉回活动，告诉他们最近产品的变化（而不是骚扰式的push）， 是不是会更有效。 在做这样一些活动时，我们同样需要观察客户重新拉回的留存率，用于评判产品的变化是否具备拉回“已流失用户”的能力。 把时间拉长，这部分的留存曲线甚至可能是呈现“微笑型曲线”。   当然上述的留存分析在产品不同阶段的应用并不是一概而论的，只能说在不同的阶段，我们的留存分析有不同的侧重。不变的一点是“留存分析” 在产品的全生命周期都扮演着非常重要的角色，尤其是在当下互联网产品百花齐放的时代，留存显得尤为重要。   03 总结 留存是当下互联网产品重要的评价指标，也是当前形势下增长黑客模型的第一要素。本文从两个角度对留存分析进行讨论：   留存怎么算，我们需要提供一个准确的留存率分析报告，这更多是数据分析师的职责。 留存怎么用，如何运用留存分析来推进产品迭代，以实现产品增长，这更多是产品经理的职责，但是作为数据分析师，理解数据的运用也同样重要。

01 渠道是什么 说到渠道，大家的第一映像是销售渠道。如果通过哪些方式，基础到用户，并将产品售卖给用户。是的，这个是传统的渠道。在这个互联网+的时代，也出现了很多别的渠道。   渠道的定义是：将产品从生产者转移至消费者的过程。那么我们经常做的广告投放，活动营销，应用市场投放，是不是都是渠道呢？是的。传统渠道，转移的产品是实体产品，互联网+的渠道，转移的则是一个个APP，一个个活动。那对于这些，我们也可以叫渠道，比如我们常见的头条广告，就是feed流渠道，百度竞价搜索，也是一个渠道。   那这么多五花八门的渠道，穷举肯定不太可能了，毕竟产品在飞速的迭代。   02 渠道的分类 那我们根据推广方式的不同，将渠道进行分类把。主要有以下几类。   1、信息流推广 互联网行业的同学应该都非常清楚信息流。通俗来讲，就是一屏信息透出。比如我们常用的头条里面的刷不完的文章，就是信息流。那推广更好理解了，就是在这一堆文章中间夹杂着者一些广告，这些广告就是信息流推广。这些推广，一般来说都有固定的广告投放平台可以使用，比如广点通之类的。   2、搜索引擎推广 搜索引擎推广大家最常知道的就是百度的竞价排名。没错，搜索引擎推广是指通过搜索引擎优化、竞价排名的方式，不断的优化搜索关键词，触发相关的推广投放。从而吸引更多的用户点击访问我们的产品。大家熟知的SEM就是搜索引擎推广，SEO则是搜索引擎优化。通俗来讲，SEM是花钱买关键词触发，见效快，成本高；SEO则是搜索透出词的优化，不用付费，但是见效慢，是个长期的活儿。   3、应用市场推广 应用市场，俗称App Store。也就是手机应用商店。为什么这里我们还要推广呢？ 首先，各大手机厂商都有自己的应用市场，如果我们的APP，没有被某厂商的应用市场收录，那么，是不是就会损失一大批该手机厂商的用户？其次，即便被收录了，但是排名很靠后，那是不是被看到的概率也会下降，从而导致触达用户减少？   4、自媒体推广 这个相信大家都很熟悉了。公众号，知乎账号，简书账号，都是自媒体。那推广是怎么回事呢？主要由于这些自媒体产出了很多吸引人的内容，从而吸引了很多粉丝。那如果某个产品的目标用户，和某自媒体粉丝用户比较契合，产品就会通过软文，插入链接等方式，做相关的广告推广，达到引流的作用。   5、短视频推广 这个其实是最近才火起来的，不用多说，南抖音，北快手~但是目前该类推广也非常火热，主要来源于该类产品的巨大的流量。对于这种推广，主要有两种方式。一种是视频广告的推广，比如抖音就有很多广告小视频。另外一种，其实和自媒体差不多，就是找到视频平台上这些KOL合作植入情景广告。   6、其他推广 由于还有很多的推广方式，比如墙面广告，地铁站广告等，我们把这些都归入其他推广。   03 渠道如何调控 对应的，我们投放了渠道之后，我们肯定想要投放效果，拉动更多的用户（无论是NU还是拉活），我们都期望以尽量少的钱，拉到尽量多的用户。那么问题来了，我们如何提升渠道的投放效率，也就是渠道的ROI呢？   ROI大家肯定都不陌生，投资回报率嘛。那对应到渠道这块儿，我们的ROI该如何算呢？ 渠道的ROI = LTV / CAC。提高ROI，就是要在尽量少花钱的同时，拉来足够多的流量。   结合我们刚刚讲的渠道分类，我们肯定会有很多不同的渠道来引流。比如，我们会在应用市场，也会投放信息流。但是这个只是一级渠道，我们对应不同的平台，代理商，服务商等，肯定会有更细的渠道。那么对应的，我们就有最落地一级的渠道标识。通常这些渠道标识都是打在安装包中的，每个安装包只要下载激活，相应的渠道就会有数据记录。   对应的，我们知道了每个渠道号的流量，那这些流量产生了多少价值我们就知道了。这个就是分子LTV，用户的生命周期价值。   比如，流量型产品，用户不直接产生价值，比如搜索，头条等场景，用户没有直接的在线商业增值产品，这种情况下，用户创造的价值就是流量。那么我们直接计算用户在接下里30天内的活跃天数就可以了。相应的，有商业增值型APP，我们可以直接计算用户带来的收入，因为用户产出了直接商业价值。   当然，这里说到的30天，还可以是60天，甚至更长的半年一年。这些可以通过具体的业务情况来决定。通常情况下，90天足以，因为目前市场上的TOC的APP，活跃频次都较高。但是对于一些SAS产品，则需要计算较长时间，比较，企业级产品通常都按年付费。我们需要考虑的至少一年以上的价值。   那我们拿到了LVT，也知道了渠道花费，即CAC，是不是就可以进行渠道分析了。   这里有一个比较经典的四象限法。 我们来说明以下这个图。   我们以客单价为横轴，流量为纵轴，建立一个渠道矩阵。相应的，我们可以在这个矩阵中，找到每个渠道的定位，也就是这四个象限。   核心渠道就是流量高，客单价也高的渠道。这个是我们需要主力维护的渠道。   而优质渠道呢，则是客单价高，但是流量少，对于这种渠道，我们一般都是扩量，通过引入更多的流量，使其价值提高。   而针对潜力渠道这种客单价低，但是流量高的切，我们需要考虑如何提高客单价，比如设计新的商业产品，或者优化商业转化流程等。   最后这种客单价低，且流量也低的渠道，我们需要考虑是否投放该渠道，毕竟价值非常少，在这种渠道上增加渠道花费，不如找一些新渠道。   总而言之，就是其他三个象限的渠道，都要通过不同的方式方法，流程策略，往核心渠道上靠。这样有目的，且有方法的调控，才能不断的提高渠道ROI。当然，这个是个漫长的过程，渠道矩阵也需要不断的迭代和变更。不能始终使用一个标准去调控渠道。   以上，就是渠道的简介。什么是渠道，渠道的分类，以及如何调控渠道，相信大家有了一个了解。

01 前言 “同一个世界，同一个老板”，作为数据分析师，相信此情此景你也一定经历过：正在埋头工作，突然收到老板的一条微信，昨日的DAU为啥降了？然后你“一顿操作猛如虎”，但令人焦灼的是，面对一大堆数据“仔细一看还是原地杵”……   那么我们该如何建立科学的数据分析体系，并从业务的角度给到老板最满意的答案呢？接下来笔者将结合自身做DAU监控以及用户增长的经验，给到屏幕面前的你实用的干货知识！   02 梳理你所在公司的用户增长模式 在构建DAU流量监控体系前，建议通过业务人员调研、公司组织架构等途径，摸清楚真正驱动企业用户增长的“核心模式”是什么，以便为后续建立DAU监控体系提供基础；否则，无头苍蝇般地从各个维度拆解数据，会让整个分析工作变得非常低效。   尽管不同业务形态、以及不同发展阶段的公司，其用户增长模式各有差异，但都可以从拉新策略和促活策略进行分解。   常见的拉新策略有： 流量采购。 比如通过厂商预装、应用商店渠道、信息流广告、搜索广告、网盟广告等途径付费采购流量。 基于微信生态的社交裂变。比如归功于微信流量的支持，趣头条会通过“领取金币任务”吸引老用户参与“邀请新用户”的活动；微信读书依靠“组队抽取无限卡”的裂变活动，仅仅半年就暴涨百万用户。   常见的促活策略有： 外部渠道促活。 比如： 通过push唤起App； 头条系的APP矩阵可以互相促活； 在广点通第三方媒体投放基于“RTA+个性化商品素材”技术的实时动态出价广告，可以对不活跃的老用户进行促活； 朋友圈内打开一篇来自知乎的文章后，点击“App内打开”的底部浮层按钮可以唤起知乎App； 通过负一屏的weiget小组件可以唤起App等； 双十一短信促活。 社交裂变。 例如，拼多多的拼团砍价； 趣头条唤醒沉睡老用户可以赚钱金币。 红包补贴。 往往补贴力度越高，促活的效果越好。 电商的养成类游戏。 比如支付宝的蚂蚁森林、拼多多的多多果园、美团的小美果园等。 用户运营活动。比如签到任务、积分体系等，促活效果取决于虚拟币变现的能力。   值得注意的是，在梳理用户增长的核心驱动力时，需要重点识别影响DAU增长的核心要素。   举个例子，尽管虽然很多公司会有签到任务、积分体系、老拉新任务等用户激励体系，但由于兑换商品吸引力不足等原因导致用户参与度非常低，所以不足以成为促进用户回流的核心手段。   而对于很多App，Push拉活、RTA广告促活已经是提升老用户活跃度的标配手段，促活用户的DAU占比可达10%以上，那么在DAU监控体系中必须将push和rta广告等促活方式作为监控的重点。   03 搭建数据监控预警体系 1. 判定DAU是否异常 常用的方法是：看日环比绝对值、周同比绝对值、日环比、周同比、以及最近30天的变化趋势。   可以基于经验判断异常变化的Δ，比如日环比、周同比上升或下降超过5%可以判定为异常；或者日环比绝对值、周同比绝对值上升或下降超过 xx 万判定为异常。   这个异常Δ怎么设定呢？可以观察至少3个月的DAU波动数据，将波动较大的时间点所对应的数据变化幅值作为异常 Δ。   为实现自动化，建议将下图的监控报表进行数据产品化：即每日以邮件抄送各部门领导层；并在DAU处于异常时，给数据分析组发送报警邮件，以便于分析师第一时间排查诊断，做到在领导还没有张口发问怎么回事之前，就已经知晓背后的原因。   2. 构建DAU拆解的指标体系 在DAU被判定为异常增高或者异常下降时，就需要基于前面提到的“用户增长模式”，对DAU进行拆解以定位业务原因了。   这里值得一提的是，因为数据分析师的职责就在于通过科学的方法量化业务的表现，所以如果能给到业务方这样的论述，比如：这次DAU日环比下降 50% 的原因是由xxx贡献，30%是由于xxx贡献，20%是由于xxx贡献， 更能够凸显自己在数据分析方面的专业性。   为了对异动原因进行科学的量化和归因，可以按照完全穷尽、互相独立地去拆解日活：   拆解的第一层级为： DAU =  当日新增用户 + 首次外部唤起App的老用户 +  首次自然启动App的老用户    DAU中老用户的拆解，借用了渠道广告归因中“首次归因”的思想，即将全部功劳归因到用户行为路径上的首次行为属性。例如，某个用户当日先通过手机桌面图标 自然启动App，然后又通过push启动了App，但由于“自然启动App”是用户当日行为序列中的首次行为，该用户的这 1个DAU功劳将100%全部归给“自然启动”，push功劳为0。   说明下第一层拆解指标的具体计算方式： 新增用户可以利用当天激活的设备数来计算； 外部唤起老用户可以通过埋点统计字段（启动入口）进行区分，当启动入口为非桌面图标启动时记做外部唤起； 自然启动的老用户，可以通过DAU-当日新增用户-自然启动老用户计算。   拆解的第二层级为： 新增用户。 可按照渠道、机型等维度来进一步拆分，以细化异动是哪个拉新渠道的问题； 外部唤起App的老用户。 可按照首次唤起App的入口（比如Push、RTA广告、微信等）拆分。 即 首次外部唤起App的老用户数= 首次push唤起App的老用户数 + 首次RTA广告唤起App的老用户数 +  …. 自然启动App的老用户，可按照用户访问App的目的进行拆分。具体是，通过对用户站内核心行为的先后发生顺序进行分析，将DAU的贡献归因于首个核心行为模块。比如，某产品的渗透率较高的核心模块有：A、B、C，那么自然启动App的老用户 = 站内首次进入A模块的老用户 +站内首次B模块的老用户 + 站内首次C模块的老用户 + 其他行为模块的老用户。「其他行为模块的用户」，是指未发生以上前面任何核心行为的用户。   这里需要说明的是，如果App核心功能和使用场景比较单一，可以不对自然启动的老用户进行拆解。   3. 计算波动贡献度 指标Xi的波动贡献度=指标Xi的变化幅度/DAU的变化幅度。贡献度越大，说明该指标对波动的解释效果越好。通过波动贡献度，我们将异常原因定位到是新增用户、还是外部唤起老用户、还是自然回流老用户部分有问题。   比如下面虚构的例子，DAU日环比下降70W，尽管RTA广告、微信启动等也有下降，但下降贡献很小，而老用户回流的下降贡献可达93%，所以问题范围就缩小为老用户回流为何减少。   一般地，如果发现「新增用户」「外部唤起老用户」的异常波动贡献度较大，可以进一步按维度拆解指标并计算波动贡献度，例如按渠道拆分「新增用户」，发现 A 渠道的波动贡献度最高，那么A渠道就是造成DAU波动的主要原因。   如果发现「老用户回流」异常波动贡献度较高，需要排查是否是由于内外部环境变化导致（内部变化：新发版出现bug、运营活动、产品功能；外部变化：节假日、市场变化、竞品策略、热点舆论事件等）。   对于外部因素引起的老用户回流异常，可以结合竞品数据、百度搜索指数、去年同期数据进一步确认。   对于内部因素引起的老用户回流异常： 如果要排查是否是发版bug导致，可以拆分操作系统和版本进行排查 一般地，产品功能、运营活动的影响，可以按照首次归因的思想，计算打开App后首次进入活动页面（或者访问产品功能）的用户Δ增量，只有该 Δ 占 DAU波动Δ 的比例非常高，才能说明该活动对于DAU有显著的影响。   04 向上汇报异常原因 通过上述的波动贡献度计算和逐层下钻，我们可以找出DAU波动的主要因素，和业务方核实确认后，就可以邮件或微信同步上级领导。可参考以下格式进行汇报：   各位领导和同事， xx月xx日的DAU为xxxx，周同比下降xx。 主要原因是：xxxx。 建议是：1、xxxx；2、xxx；3、xxx。   05 结语 结合自己浅薄的工作经历来看，尽管日活的监控诊断工作可能非常繁琐枯燥，但它可以很好地锻炼我们的数据敏感性。比如，当你完成多轮的拆解归因后，就能知道大概率有哪些因素可能会引起DAU的剧烈涨跌，而哪些因素影响较小，以及哪些拆解指标是需要重点关注的，同时DAU波动的排查工作也会变得越来越娴熟。   以上就是DAU波动诊断的全部内容了，希望大家都能够有所启发。由于本文的案例均来源于实际工作，其中的部分结论可能并不适合所有业务场景；另外，限于自己的知识和视角，本文难免存在一些考虑不周的情况，一些分析方法和思路也许并非最优，若有不足之处，欢迎大家在评论区探讨。  

1 导语   相信对于很多刚入门的分析师小白来说，评估活动效果、洞察业务机会，是所有工作中最可以体现价值感的事情，但也可能是令我们最头疼的事情。本文作者基于自身的实际工作经历，结合一个真实的运营活动，对活动评估中可以复用的数据分析“套路”进行总结和整理，希望能够给初接触数据分析的同学带来帮助。 一般来说，互联网公司的运营活动按照目的可以分为3种：拉新、促活、品牌宣传，尽管每种活动关注的核心绩效指标完全不同，但是分析的思路还是可以套路化的。接下来，本文将以某次促活活动为案例，分享下如何对一场活动的效果进行量化评估。   2 活动背景   伴随着移动互联网用户的增速越来越趋于饱和，用户增长的破局方法不得不从拉新获客转换为如何促活存量用户。   通过第三方广告媒体app（比如微信、抖音等）投放针对老用户的素材对用户促活，已经成为很多公司用来提升存量老用户活跃度的有效方法（后续会统称为“渠道拉活”）   某公司的市场投放部门也开始投入预算试水「渠道拉活」这一项目，在项目启动一段时间后，已经回收累积了大量的用户数据，但是：   渠道拉活对于DAU的带动贡献究竟有多大？ 是否值得持续投入更多的资源？ 活动情况的ROI如何？是否符合预期？ 活动是否存在改进空间？         这些领导和业务方非常关注的问题，需要分析师基于数据给出公正和客观的答复。     3 分析框架和指标体系 3.1  分析框架 活动整体增量效果评估 (包括短期效果分析、长期效果分析) ROI 核算（计算单用户的拉新或者促活成本） 参活用户质量评估 活动存在问题分析         3.2 指标体系 3.21 流量规模   数据指标： DAU 参与活动的用户数（举例：渠道拉活成功召回的用户数） 通过活动首次调起app的uv（举例：通过渠道拉活首次调起app的uv） 通过活动首次调起app的uv占day的比例（举例：通过渠道拉活首次调起uv的dau占比）           可解决的问题： 通过对比事先制定好的活动KPI指标，评估目标完成率； 与其他活动对比，评估促活的核心指标（通常是DAU）是否达到预期； 评估渠道拉活能够召回的用户量级有多大； 评估对DAU的净增量贡献有多大；   3.22 用户质量、用户画像 数据指标： 留存率（次日回访率、7日回访率、30日回访率） 日均使用时长 核心功能渗透率 核心功能人均PV 人群画像（性别、城市、消费能力）           可解决的问题： 评估渠道召回用户的质量 监测是否存在刷量作弊渠道   3.23 用户行为 数据指标： 站外转化漏斗（举例：广告曝光-广告点击-成功调起app-deeplink抵达特定页面） 站内核心行为的转化漏斗（举例：活动页-列表页-详情页）           可解决的问题： 评估用户从站外渠道到抵达App的路径是否顺畅，发现产品bug或者可以改善的机会点 评估活动的站内承接策略是否合理     4 分析过程 4.1 活动效果评估以及活动ROI分析 在量化DAU (或者活跃天数) 贡献时，需要减去用户的自然活跃量，即计算“净增量”贡献。该贡献可以分为当日贡献和长期贡献。   当日贡献是指：当日的召回用户对于当日DAU的增量贡献 长期贡献是指：由于召回用户的后续回流，在后续特定时间范围还会持续贡献的用户天数增量。比如，活动后的50个参与用户，在后续30天内人均活跃天数比活动前提高10天，那么促活的增量贡献就是1500天。         不得不承认，AB实验最擅长处理归因和量化的问题。它的思想是，将流量随机分为数量均匀和特征均匀的两组（即对照组和实验组），实验组用户只有在产品策略上与对照组不同，因此我们可以认为两组用户在同一时间维度上的指标差异，可以完全归因于策略上的差异。   然而，该广告拉活项目无法设计对应的AB实验，但我们可以基于AB测试的思想，构造与实验组“相似”的用户群体作为对照组。具体过程如下： 将拉活渠道唤起app的用户作为实验组，未曾被拉活召回的存量用户作为对照组；   选取可能影响用户未来活跃度的特征（比如机型、新增渠道、历史活跃度、…），基于“特征相同”的原则，对两组用户划分为 N 对实验组和对照组。注意尽量将特征通过区间离散化，避免划分出的某一组落入的样本数过少，导致两组样本的指标差异不可信，比如特征「新增日期间隔」可以离散化为：7天内、8-14天、14天以上；   计算 N 对实验组和对照组的每一组的指标差异值，以及实验组的总指标差异（等于每一组指标差异*人群占比的相乘结果求和）     通过以上方法，可以计算出拉活对于当日DAU的贡献、以及拉活对于未来30天DAU的总增量贡献。   实际上，对于拉活对DAU的单次短期贡献，有更为简便的方法，即基于“首次归因”的思想，通过“拉活首次调起app的uv”进行量化评估，即如果用户多次启动过app，那么只有当通过促活广告首次调起app了，才会计入到促活广告的功劳。   值得一提的是，“首次归因”的方法也可以应用至“产品新上线功能评估”的效果量化中，通常我们可以将“启动app后首次访问该功能的用户量”作为该功能对dau的贡献量。   对于活动成本的核算，我们可以通过 “总成本消耗量 / 总DAU增量”，计算每个DAU增量的成本，以评估ROI是否符合预期。   4.2 用户行为分析、和用户质量评估 可以以「大盘未参活用户」、「同期同类活动」、「往期同类活动」分别作为对比基准，基于用户行为漏斗、留存率、核心行为pv、人均使用时长等指标，识别本次促活策略是否有薅羊毛或者作弊严重的渠道，并评估活动拉来的用户质量好坏。但这里不作为本次分享重点，因此不再展开赘述。   5 结语 作为数据分析师，实际工作中遇到的促活策略往往是五花八门，但是活动效果好坏的评估过程依然是有章可循的。最后，简单总结下本文对于后续活动评估的可复用之处：   如何构建活动评估的指标体系； 如何量化归因活动的短期贡献（即“首次归因”法）；    如何在无法开展AB测试的情况下，通过构造对照组的方式，快速地量化评估长期的增量贡献；

乔巴：我是一枚半路转行的数据产品经理，现在大数据火热，所在公司想搭建画像系统，但自己对用户画像没有概念，对画像系统是怎样的架构，有哪些常见的功能等事项全然不知，真是困煞我也！ 索隆，会心一笑，言道：产品经理就是为了解决问题而存在，解决问题要一步一步来，想掌握画像体系可以先了解标签体系、OneID体系等基础内容。 然后来细读各个大厂的画像系统是如何搭建的，如微博、百度地图、京东数科、腾讯、阿里等巨头公司的画像系统，正所谓“求其上者得其中，求其中者得其下”。取上再结合实际，才为正道。   当然，此项梳理并不轻松，需耗费大量精力。在此我花了2个月时间对其做了整理，并写了一份60页的PPT（关注一个数据人的自留地，回复“画像系统”即可获取），可谓是呕心沥血，相信你学起来必然可以事半功倍~ 乔巴：cool，我先关注学习一波~ 索隆：接下来会按如下结构展开： 1.V1.0：画像初级版，为画像系统雏形，选取了2015-2017年早期的画像版本，彼时部分公司的画像系统刚刚起步，各方面功能还未探索清楚，如百度地图画像系统、微博画像系统；   2.V2.0：画像标准版，其基础功能完善，有了一定的分析能力，如神策画像系统、京东数科画像系统；   3.V3.0：画像营销版，其进化为营销工具，助力业务增长，如腾讯广点通DMP、阿里达摩盘DMP；   01 V1.0：画像初级版 画像初级版，选取了2015年早期的画像版本，彼时部分公司的画像系统刚刚起步，各方面功能还未探索清楚。   例如，百度地图的渠道画像系统的整体设计是，在数据分析/报表系统的基础上加上一些基础的画像元素，如性别、年龄、行业、所在城市等标签数据。此阶段发力于对各业务进行数据分析，如建设了dashboard、自定义报表、订阅，类似BI平台，但缺乏标签体系建设、缺乏洞察等模块，各个画像的功能做的比较浅。   再到微博画像系统这，已经形成了画像基本形态，从数据采集、数据清洗，标签生成，到单用户画像、分群用户画像、API接口提供等。其功能模块相对来看较为完整，但洞察能力、标签体系建设能力还需继续增强。   01 百度地图画像系统   据相关资料报道，17年时，百度地图的市场占有率在45%-50%之间，未能覆盖全量用户，获取用户数据信息受到限制。因此，百度地图与华为、OPPO、vivo、小米、魅族等TOP手机厂商进行深度合作，允许其手机系统调用百度地图的LBS基础功能，从而换区数据共享的资源，用户画像系统在这个背景下产生。   而此用户画像系统在预算评估、投放效果分析、经费节约、用户实施监测等方面提供有力数据支持。   1.系统架构 系统的整体架构包含：   1.数据层：数据采集、数据清洗、数据库搭建、数据合成   2.管理层：管理模块和个人中心 a.管理模块：角色管理、用户权限管理、报表增删改查管理 b.个人中心模块：登录设置、浏览设置、dashboard自定义设置   3.展现层：导航模块和浏览模块 a.导航模块：用户自行选择需求报表 b.浏览模块：用户选择查看维度，自定义dashboard展示   4.拓展层： a.收藏模块：用户通过点击收藏，对关注频率较高的页面进行收藏，方便在众多报表中快速找到自己关注的报表。   b.邮件设置模块：用户选择关注的核心数据，每日定期将所选择的数据以报表形式发送至指定邮箱   c.异常预警模块：主要面向管理员，对报表和数值设定阈值，当数值超过阈值时通过邮件等形式通知管理员，以便及时发现数据异常情况   d.导出模块：Excel原始数据导出、图表导出   2.产品功能 如下图所示，渠道画像平台根据其面向的用户群的需求及特征可划分为，前装渠道、后装商店、厂商品牌、前后装对比等业务类模块。而每个渠道下，可进一步分析渠道质量、基础画像、用户行为。     基础画像包含个人属性类数据，如性别分布、年龄分布、教育层次分布、消费水平分布等。     通过城市用户分布热力图，可以直观了解各城市用户数量分布。     02 微博画像系统   微博画像系统基于微博的大数据，对微博全体用户进行刻画，可对每类用户进行数据分析。   微博的用画像系统主要包含数据爬取模块、单个画像模块、批量画像模块、查询接口模块。   1.数据爬取模块 数据爬取模块主要是做数据采集和数据清洗，采集用户在开发者平台上填写的资料信息，进行接口调用品类的限制，并保持最新的用户数据，对数据进行清洗，提供用户基础信息及用户关系链的接口，方便各个系统进行调用。     2.单个用户画像模块 单画像模块主要分为标签生成、用户行为分析、关系链分析。   a.标签生成 标签生成模块顾名思义，主要功能是通过对数据的分析给用户打标签，即用户画像。标签主要分为三类，一是安全标签，二是聚类标签，三是统计标签。     安全标签：描述账号是否异常，依据事先制定好的安全策略，分析异常概览。一是分析黑色产业链的整个流程，分析用户账号被盗之后的特点；二是分析用户的历史行为，来判断目前的用户行为异常的可能性。   聚类标签：对聚类算法的结果进行分析和解释后得出的结论，主要使用的是K-mean聚类算法。   统计标签：将各个指标进行统计分析之后，根据用户的分布，得出统计类标签。   索隆：可见这是早期的标签体系，但从标签分类来看，缺乏清晰的分类逻辑。   b.用户行为分析 通过在一段时间内，观察用户行为的变化，进行用户状态的判断和未来行为预测。如用户登录时长、关注数、粉丝数、微博数、收藏数等指标。   c.关系链分析 用户的关系链可以很好的描述一个人，因此关系链分析也是画像的重点。此处主要分析用户好友的年龄，城市以及好友的关注数等指标。   3.批量用户画像 批量用户画像主要分为文件上传、结果统计及展示模块。   a.文件上传 文件上传模块，支持用户将需要分析的用户ID写在一个txt文件中，通过前端页面传到后台进行分析。文件中的每个用户ID使用换行分隔符隔开，原则上每个文件的大小不超过10M。     b.数据统计及展示 批量用户画像和单个画像的主要区别是，单个画像只需要描述单个用户，而批量画像则需要对多个用户信息进行统计分析。数据统计及展示模块主要使用highcharts实现，使用柱状图、饼状图、散点图进行数据可视化。   独立分析指标：性别、关注数、粉丝数、微博数、收藏数… 联合分析指标：粉丝数、微博数、收藏数；关注数、微博数、收藏数；关注数、粉丝数、收藏数；关注数、粉丝数、微博数；   c.查询接口 接口模块同样是画像系统上十分重要，画像系统上创建的分群，可以以接口的形式供各业务系统调用。     03 小结   此处案例中的百度渠道画像系统还较为传统，在走BI的路子，相对来说微博画像系统已经更近一步有了单用户画像、分群画像、标签管理、接口等标准画像模块，不过标签体系和用户洞察做得不够深入。那接下来看看画像V2.0会有哪些进化。     02 V2.0：画像标准版 第二阶段的画像系统功能较为完备，初步实现为业务赋能，如神策画像系统、京东数科画像系统、腾讯广点通。   1.京东数科画像系统，标准画像系统，提供较为标准的画像功能，包含标签市场、人群画像、人群管理、接口服务、标签管理等，可以将用户分群服务于其他各个业务系统。 2.神策画像系统，分析类画像系统，则基于神策的数据分析基因进行用户分群、画像洞察相关的拓展，本质上是一个数据分析工具，其分析能力可进行借鉴。     01 京东数科画像系统   京东数科画像系统：提供基于用户标签、人群画像的统一数据开发与应用服务。辅助基于业务主体的营销、分析、识别、价值变现等目标场景的实现和服务拓展。 1.标签市场 标签列表中展示所有标签，对制定标签查看标签信息、标签值分布及标签的各项指标统计。   2.人群画像/洞察 支持对人群进行人群数量计算、基础画像分析、自定义画像分析，并分析两个人群之间的交叉情况、分析人群与其他标签关系。   3.人群管理 人群管理支持多种方式创建人群，并支持人群的信息设置，规则修改，保存后的人群可进行人群画像等操作。   4.接口服务 管理员可以在“权限管理”中管理用户的系统角色、标签使用权限；管理系统对接标签、任期内接口的权限。   5.标签管理 数据开发和管理员拥有标签管理的权限，进入页面后，可以查看对应标签的状态和信息，并且对标签进行“测试、下线、修改、删除”等操作。     02 神策画像系统 神策用户画像系统，是针对企业级客户推出的用户数据分析平台，提供探索用户特征及画像能力，完成对用户的识别、聚类和细分，并通过历史特征变化，查看用户全生命周期的演变过程，主要功能包含特征标签的加工生产，用户特征及画像分析，用户分群管理。   1.用户标签管理 a.创建标签用户 创建标签的过程中，按符合用户的行为习惯的方式来进行创建即可。填写标签名称，设置清楚标签条件, 同时，创建标签需要提供标签的基础信息，主要包含：标签的显示名、标签名称、标签的分组、更新方式和备注等。   b.管理用户标签 支持标签的启用、停止、删除、重算、历史回溯、标签计算规则查看，标签的数据可视化呈现。     2.用户分群管理 a. 创建用户分群   支持按规则创建分群，或者是通过文件上传的方式创建分群。 b. 管理用户分群 3.用户洞察分析 a.单用户画像 查看单个用户画像信息时，可以看到该用户全部属性，相当于一个人的个人简历，直扑眼前。     b.群体用户画像 通过选择对照组，可进行两个群组用户的画像特征对照分析。对照组默认为无，可选择用户分群或用户分群任一版本进行对照分析。     查看TGI，TGI（目标用户群体指数）=目标用户群中某一特征的总用户数在总用户的占比/全量用户中具有该特征的总用户数在全量用户总用户数的占比*标准数100   并且通过选择用户群画像模板，可直接将管理员预先设置的画像信息快速加载到画像分析结果中，同时可自行在其基础上进行画像信息的添加或删除。   c.相似人群扩散 通过智能算法，寻找与种子人群特征相似的【相似用户群】，针对相似用户群，可以进行针对性的运营策略。   其中种子人群，可分为正向种子人群，即预测人群的结果是与正向种子人群相似的；负向种子人群，预测的人群的结果是与负向种子人群相悖的。   4.系统设置 包含单用户画像、群体用户画像、相似人群画像模板管理、功能权限及数据权限配置等功能。     03 小结   第二阶段的画像系统功能已趋近完善，标签体系已开始单独建设与管理，分析洞察能力也在不断加强，具备画像标准版功能。但当前阶段与业务的关系结合的还不够紧密，要想发挥出标签的业务价值，还需进一步强化与业务方的关系。     03 V3.0：画像营销版 到画像3.0，画像系统更像是一个营销工具，除了拥有完备的画像基础能力外，还能更贴近业务的进行营销洞察，个人觉得更符合营销版的是阿里的达摩盘。 1.腾讯广点通DMP，广告类画像系统，是腾讯推出的数据管理平台，主要应用于智能广告投放，提供标签市场、用户分群、分群洞察等能力。   2.阿里达摩盘DMP，营销类画像系统，是阿里妈妈推出的数据管理平台，提供标签市场、用户分群、分群洞察、营销学院等能力。     01 腾讯DMP 腾讯DMP数据管理平台是广告主实现自身数据增值的重要工具，能帮助广告主管理自己在腾讯系中的人群，更灵活地将第一方数据用于广告投放，以及再营销、动态商品广告、转化统计等应用。   广告主也可以使用关键词、 LBS 等数据标签创建自己的目标受众。DMP 的Lookalike人群拓展功能，还能帮忙广告主在腾讯用户体系中寻找可能的新用户。   1.数据接入 用户会在网站、应用等场景发生一些行为，如浏览商品、收藏内容、完成关卡等。接入行为数据帮助了解用户在其网站或应用中采取的操作，继而利用这些数据进行广告营销活动。   人群提取：广告主可根据其上传的用户行为数据，提取出符合特定条件的用户人群，用于广告定向等。假如广告主上报了一条“某用户某时刻在某应用内购买了价格300元的女装”的行为数据，那么，广告主可以在DMP中创建一个“最近7天，在应用内发生购买行为，商品类型是女装，商品价格>200”的行为人群。   转化统计：广告主可把其上传的用户行为数据与广告进行关联，从而统计广告的转化效果。   2.人群管理 a.创建人群 根据用户的需要，将人群按照不同的方式提取或划分，创建成不同性质的人群。     人群分类又可分为自定义人群、拓展人群、组合人群三大类，下述划分几个小类。     例如，客户文件，指客户将想要用于广告投放的用户ID以文件的形式上传。 创建要求：当客户存在目标用户的QQ号、手机号、IDFA、cookie、MAC地址等信息时，方可创建人群。   应用场景：可以将想要用于管理的用户ID等信息，以TXT文件或压缩包的形式上传到DMP，创建成功后即在DMP对这些用户进行拓展、组合、洞察分析和广告投放等。   例如：某美妆品牌上传了注册会员的人群，对此人群定向投放品牌周年庆折扣活动的广告，大大提升了销售量和会员回购率；当用于智能拓展时，高质量的一手数据包，创建的种子人群能进行拓展，得到海量精准定位的潜在用户。   支持的数据类型：   b.人群管理 用户在人群管理页面进行筛徐、编辑、授权、删除等操作。     操作：点击下拉菜单，可对人群进行智能拓展、洞察分析、授权、删除等操作 人群编辑：点击人群名称，进入详情页，可对人群名称和描述进行编辑，并查看该人群的具体信息、创建时间、来源和操作记录等信息   搜索：按照人群名称或ID来搜索人群，随着输入人群会自动过滤   删除：删除不需要的人群，释放人群配额，定期删除人群也更便于人群管理。例如：对于一些测试的人群，可将其删除。   3.洞察分析 每个人群的创建都是在一定条件下进行，有频繁与某些广告互动的人群，也有特定地点位置变动的人群，或者是客户提供的第一份数据创建的群等，洞察分析可以帮助客户更加细致全面的了解人群的属性、兴趣分类、关注点及地域特点等特征分布情况，这些特征可以用于优化广告创意，指导营销策略，为进一步制定投放提供参考依据。客户对人群的洞察越清晰，就越能准确的传达出品牌的产品信息、提高投放效率。   例如：用户通过洞察分析得出，人群中男性占比较高，兴趣爱好属体育健康类居多，可根据这些信息修改出更符合用户特征的广告创意，投放时可筛选女性用品等可能导致低点击转化类别的广告，使得广告投放更具有针对性。并可导出生成报表。 进行数据下钻，查看更深层次的洞察数据： 4.标签广场 标签广场包含两个模块：标签专区和热点人群。其中标签专区包含标签地图、专属推荐和行业推荐。   标签地图：标签索引区，以树形结构展示所有定向标签。基础的人口学属性包含消费状态、生活方式和工作状态等几大类标签，点击标签可进入下一个页面查看具体的标签结构，进一步了解标签信息。   为进一步提高操作效率，还有收藏夹的功能，用于存放用户感兴趣的标签，方便快速找到目标标签。当不知道选什么标签时，可查看专属推荐&行业推荐模块。 临近双十一了，可以使用热点人群，热点人群是一个按营销场景推出的主题标签组合专区，会结合行业特征或节日主题，围绕一系列营销场景或时事话题进行组合。     5.对接投放 选择DMP中的人群，可对接至广告自助投放系统，进行广告投放。   02 阿里达摩盘DMP   达摩盘又称DMP，是阿里妈妈基于商业化场景打造的数据管理平台。商家通过达摩盘可以实现各类人群的洞察和分析，进行潜力客户的挖掘；通过标签市场快速圈定目标人群，建立个性化的用户细分和精准营销。   不得不说，达摩盘的水很深，研究达摩盘的标签体系、系统后台、玩法几乎花了草帽小子2个月时间，越挖掘越有料，下边由草帽小子带你先从整体上了解达摩盘的系统构成。后续会出达摩盘标签体系、洞察、分群等各个模块的专题文章，感兴趣的朋友可以先关注公众号：一个数据人的自留地，进群交流。 1.首页 达摩盘首页主要包含店铺消费资产，可查看全部消费者、潜客、新客、老客的趋势；标签使用推荐、老客价值细分、店铺消费者流转等。   2.洞察 洞察模块主要包含人群画像分析、单品智能洞察圈人、店铺超级用户洞察圈人。例如当进行人群画像洞察时，需要选择对比的人群，对比不同人群的特征，如性别、年龄、行业、消费水平等数据的对比。   3.标签 随着越来越多商家拥有个性化人群运营诉求，围绕精细化人群定向中台定位，达摩盘基于大数据深度挖掘和分析，通过精细化人群赋能不同层级商家精准营销，满足商家在不同营销场景下的人群诉求，提升商家消费者运营效率。 4.人群 人群模块主要包含我创建的人群、合作方人群、第三方数据上传，可管理人群，支持按标签和人群组合创建分群，支持交并差各类组合创建分群。     5.报表 系统提供整体达摩盘人群投放效果概览，可自定义历史事件，查看整体投放效果，同时查案同行同层级投放平均数据，了解同行对比情况。查看不同渠道下，人群投放效果，查看投放趋势，同时提供基于广告曝光、达摩盘曝光、全店消费者三个维度下，提供人群流转分析，帮助商家全面评估人群构成。       03 小结   经过如上的对比可发现画像系统的功能大同小异，其核心在于其标签体系、洞察及营销应用能力。在建设时也可根据公司实际需要，从下至上进行建设。  

00 BEGIN   提及 “体系” 二字，我的脑海里浮现出老板说的 “对于工作的规划要从全局出发，内容要全面、要成体系！” 那么对于一个数据分析师而言我们的体系是什么？是 “目标监控体系？”，是 “运营分析体系？” ，还是 “APP 指标体系？” 到底该如何构建数据分析体系赋能业务呢？今天就来跟大家聊聊体系构建的话题。   构建业务数据分析体系，对于分析师同学有两个方面的要求：第一，要了解业务模式，能够解释数据背后的业务含义，找到业务的问题点、提升点，驱动业务向前发展；第二，不能只做数据、图表的堆砌，需要根据业务的流程链路有目标、有逻辑、有顺序的分模块分专题展现数据。满足这两个方面的要求才是真正意义上的数据分析体系。   下面结合我的工作场景，给大家讲讲业务数据分析体系搭建的基本思路。   01 明确业务逻辑   分析师同学要明确自己服务的业务是什么？业务逻辑是什么？业务核心是什么？在业务的基础上构建分析体系，才能让分析结果更接地气，更好的应用到业务中。   以流量外采业务为例，梳理业务逻辑（如下图）：各业务线发起流量需求 → 多渠道进行流量采买 → 流量引入落地页 → 落地页产生流量转化 → 流量变现、效果转化，这一系列步骤决定采买目标是否达成。     02 拆解分析模块   明确了业务逻辑后，根据目标和事件顺序进行分析模块拆解，明确各个目标分析的专题及关注核心。流量外采业务拆解分析模块如下：     采买效率关注核心：有多少预算？现在以什么样的价格买了多少流量？当前出价能否实现目标最大化？预算、价格、采买流量无论调节哪一项，只有三者维持平衡，才能实现流量供给相对稳定。   广告填充直接影响流量变现。因此，在保证广告主预算合理消耗、效果满足预期的前提下，不断提升页面广告填充率，从而提升流量变现效率。   用户行为既能够决定收入转化又能够决定效果转化。细致研究收入、效果转化用户在单页面中有哪些行为、访问了几层页面、点—面—点—转化/跳出的访问路径是什么。根据转化用户特征优化产品策略从而帮助业务提升流量转化。   以上各个模块的优化目的是为了达成共同的业务目标，目标达成的数据监控基础且重要。收入、效果、投入产出的数据表现直观的描述了业务现状和目标达成情况，及时的监控目标达成有助于业务稳定健康发展。   03 确定分析指标   确定了分析模块后，开始选定各个模块的分析指标，指标基本分为：结果量、转化率两类。结果量描述规模和目标达成，转化率描述效果。根据业务路径选取关键节点的转化和重要结果达成作为分析指标。按照路径的先后顺序列出指标，形成了核心数据看板，完成了数据体系的搭建。   基于流量外采业务分析模块，可拆解出如下数据看板：     04 洞察走势与业务同步发展   有了清晰业务结构、模块拆解，数据看板就可以跟踪业务走势。在跟踪的时候，首先关注的是：目标达成情况。目标达成决定了后续一系列行动判断，根据业务走势的波动情况定位异常问题、发现业务提升点。产品、运营同学根据数据结论制定每个阶段的行动计划，同时分析师也要不断变换分析视角与业务联动实现同步发展。 如下示例：     根据业务阶段性动作，明确阶段核心，定制专题分析方向： 增收阶段关注 阶段核心：流量需求、广告填充、商业帖效果转化； 专题分析方向：客户数、预算消耗率、落地页 PVR、商业化率；   提效阶段关注 阶段核心：效果转化； 专题分析方向：CVR、效果量/UV、客户效果成本；   控成本阶段关注 阶段核心：采买效率、效果转化； 专题分析方向：投放 CTR、ACP、站内 C/站外 C、CVR、效果量/UV。   05 驱动业务增长   驱动业务增长是高阶数据分析要实现的目标之一。想要改善业务，就必须了解业务细节，发现问题，找出关键点，给出科学合理的优化方案，推动方案落地，才能实现业务增长。其中发现问题、找关键点、优化方案、推动落地都属于数据驱动的范畴。   如流量采买业务中需求与供给匹配的问题： 发现问题     优化方案     具体应该如何分配流量？这就找到了数据分析在项目中可以为项目实践提供价值的地方。   数据帮助项 根据规划求解的原理解决业务中流量分配的问题，具体方法参见《规划求解应用—预算分配》。     项目实践测试的过程中，分析师需要不断跟进评估实验效果、推全后复盘项目的目标达成和可迭代升级的内容。实现全流程的参与、评估、决策才能称之为数据分析驱动业务增长。   06 形成数据体系   构建数据分析体系的本质是：满足业务需求，解决业务问题，驱动业务增长。在满足需求、发现问题、解决问题、跟进项目、落地复盘的过程中分析师同学要不断的提炼总结，进而形成自己的数据分析体系。   它可以是个思维导图，可以是个表格，也可以是个文档。无论哪种形式只要实现了数据分析体系本质，发挥了它应有的作用，落在了具体业务中，就是一个优秀的业务数据分析体系。   回到流量采买业务的示例，总结提炼形成的数据体系如下：     现实中，很多分析师同学掌握了专业的统计分析方法、分析工具、算法模型，但在与业务配合的过程中，总是很关注自己的理论深度、难度、专业度，却忽略了与业务的贴合度，因此分析结构就没有办法形成体系化的分析结构，分析技能也只能停留在初级水平。   用专业的方法服务个性化需求，将分析结果推广至业务中，只要这样才能真正的实现分析师价值，同时你也从初级成长为高级。 希望对你有所启发！  

—————— BEGIN —————— 假设豆豆在小区附近开了一家小型超市，花花每周二下班后，都会来店里买半斤猪头肉，风雨无阻，从不间断。豆豆心想：“花花每次来的时间都很固定，并且已经坚持了好几个月，我如果提前把肉准备好，这样就可以节省彼此的时间了。”   此后每周二，只要花花一到店里，豆豆就跟他说，“猪头肉已经调好啦，还特意为你多加了花生碎，直接拎走就行”。花花笑了，心里想：“嘿，这服务员挺贴心的，不错嘛”。   在上面案例中，豆豆通过对花花 “每周二下班后买猪头肉” 行为的观察，提前 “调好多加花生碎的猪头肉”。豆豆的这种做法不仅刷新了顾客的好感度，还提升了用户的忠诚度。   豆豆观察花花的行为在互联网行业中叫做数据分析，要做好数据分析，并将数据分析应用于业务中，首先就需要构建好指标体系。接下来，笔者就会聊聊如何构建指标体系。   1 数据指标体系   1.1 什么是数据指标体系？ 通常我们讲述的指标是对当前业务有参考价值的统计数据，换句话说，不是所有的数据都叫指标。指标的核心意义是它使得业务目标可描述、可度量、可拆解。常用的指标有PV、UV等。   指标可分为原子指标和派生指标，按照笔者的理解，原子指标就是不加任何修饰词的指标，又叫度量，例如订单量、用户量、支付金额等；衍生/派生指标就是在原子指标上进行加减乘除或者修饰词的限定等等。   派生指标是对原子指标业务统计范围的圈定，例如：昨日境外输入病例、网站近一周的访问量等。   衍生指标是基于原子指标组合构建的，例如：客单价 = 支付金额 / 买家数。   指标体系是从不同维度梳理业务，并将零散单点的具有相互联系的指标，系统化地组织起来。其中，维度分为定性维度和定量维度，定性维度主要是文字描述类，例如姓名、地名等；定量维度主要是数值描述类，如工资、年龄等。   举个某电商限时秒杀的栗子（如下图）：   上方红框代表市场活跃度，中间红框代表当前价格波动幅度，下方红框代表价格趋势。三个红框中的指标，可以构成一个最简单的指标体系，用来描述伊利纯牛奶秒杀的现状，属于描述指标体系。   总的来说，指标体系是对业务指标体系化的汇总，主要用来明确指标的维度、口径、指标取数逻辑等信息，并能够迅速获得指标的相关信息。   1.2 为什么需要指标体系？ 对于数据产品经理来说，搭建指标体系可以更好地梳理业务，提高问题分析效率。 因此，笔者认为指标体系的主要目的为： 1）给业务发展提供指引； 2）建立共同愿景，凝聚团队，激励团队。   2 如何设计指标体系？   下面分五部分（如下图），讲一讲如何设计指标体系。   2.1 定目标 这是第一步，也是最重要的一步，同时也是很多产品上线运营后进行评估的标准，并以此形成闭环。好的目标具有以下三个特征： 1）特征一：与高层目标一致； 2）特征二：目标应当符合 SMART 原则； 3）特征三：具有挑战性。   下面笔者就先说说 SMART 原则： 1）S 代表具体（Specific） 目标必须是明确的、具体的，要对标特定的工作指标，不能笼统。下面举个栗子： 无效的目标：我要成为一名内容运营； 具体的目标：我要掌握文案技巧。   2）M 代表可衡量（Measurable） 目标必须是可衡量的，可衡量的指标是数量化或者行为化的，验证这些指标的数据或者信息是可以获取的。 上面的栗子进一步细化，让目标可衡量。 可衡量的目标：我要掌握文章设主题、切痛点、找创意、定标题等技巧。   3）A 代表可实现（Attainable） 目标必须是可实现的，具体指在付出努力的情况下可以实现，避免设立过高或过低的目标。   假如笔者刚接触内容运营，定下了 “我要在两个月内成为写文案的专家” 这个目标，那么这就是一个不切实际的目标。较接地气的目标是：我要在三个月内掌握文章设主题、切痛点、找创意、定标题等技巧。   4）R 代表相关性（Relevant） 目标是与工作中的其它目标相关联。 比如我的中期目标是：一年内能够独立完成文章的一系列创作与发布，我的短期目标就是：三个月内掌握文章基本创作技巧。只有中期目标与短期目标具有很强的相关性，那么中期目标才更容易实现。   5）T 代表有时限（Time-bound） 目标的时限性就是指目标是有时间限制的。比如我在运营公众号 “一个数据人自留地” 时给自己定的目标是 “截止到 2021 年 12 月 31 日创作并发布 12 篇文章”，这里的 2021 年 12 月 31 日就是确定的时间限制。   2.2 建模型 2.2.1 PLC 模型 产品生命周期（Product Life Cycle），简称 PLC，指产品的市场寿命，即一种产品从开始进入市场到被市场淘汰的整个过程。产品的生命周期有探索期、成长期、成熟期、衰退期（如下图）。   在产品不同的生命周期阶段，各业务方侧重点不同，关注的数据指标亦有所不同。   1）探索期 探索期的重点在于验证产品的核心价值，是否能够满足市场需求并从中获利。要做到：假设、验证、迭代、执行。这个阶段会着重关注目标用户画像、关键行为、留存率。下面以早期的土巴兔为例（如下图）。   根据上图对土巴兔业务流程的梳理，以及对土巴兔的定位（为探索期），因此当前主要关注点是打磨服务能力，了解用户群体的需求与产品服务的匹配度，重点关注的指标如下： （1）目标用户画像：性别、年龄、学历、地域、职业； （2）关键行为：图文发表量、浏览人数、传播量、使用量； （3）质量：文章转化率、完成率。   2）成长期 经过了打磨产品的探索期，产品有了较好的留存率，这时候产品开始进入用户增长期。处于成长期时，需要将注意力放在用户的整个生命周期的前半段上，即提高留存、用户激活、自传播。   3）成熟期 随着市场趋于饱和，用户的增速放缓，逐渐趋于稳定，关注的核心指标应该是用户活跃度，同时关注商业转化路径。实际上如果市场本身是增量市场，可以考虑通过获客，把一个成熟期的产品做出一个不一样的增长曲线。   4）衰退期 新产品或替代品出现，用户转向其他产品，导致原产品用户量迅速下降，从而使原来的销售额和利润迅速下降，于是产品就进入衰退期。处于衰退期，需要重点关注用户流失与维系。   2.2.2 OSM 模型 OSM 模型（Objective，Strategy，Measurement）是指标体系建设过程中辅助确定核心的重要方法，包含业务目标、业务策略、业务度量，是指标内容横向的思考。   1）业务目标 主要从用户视角和业务视角确定目标，原则是切实可行、易理解、可干预、正向有益。 （1）用户使用产品的目标是什么？ （2）产品满足了用户的什么需求？ （3）公司/业务/产品等存在的目的是什么？   2）业务策略 为了达成上述目标采取的策略。换句话说，用户在什么时候感受到诉求被满足？   3）业务度量 这些策略随之带来的数据指标变化有哪些？是否有效满足了用户的诉求，达成了业务目标。   以 PMCAFF 为例，按照 OSM 模型，它的指标是什么样？   1）业务目标 用户来使用 PMCAFF 这个产品，目标是什么？ 需要涉及两类用户：内容生产者和内容消费者，接下来简单介绍内容生产者的分析思路。 用户需求：发布文章或分享观点，建立行业影响力或者内容受到反馈。 那么，如何让用户感受到自己的需求被满足了呢？   2）业务策略 PMCAFF 的策略是：鼓掌、评论、分享、认可、专栏作者、好问题。   3）业务度量 接下来，我们需要针对这些策略去做指标，在这里我们的指标分别是结果指标和过程指标。   备注： （1）结果指标：用来反映某些业务产出或结果的指标项，通常是延后知道的，很难进行干预。结果指标通常更多的是监控数据是否异常，或者监控某个场景下用户的需求是否被满足。 （2）过程指标：用户在做某个操作的时候所产生的指标，可以通过某些策略来影响过程指标，从而影响结果指标。过程指标通常更加关注用户的需求为什么被满足或没有被满足。   接着以上面的 PMCAFF 为例： （1）结果指标：发布文章数、发布文章的人数、文章鼓掌/评论数、被打赏金额、专栏作家人数、新增专栏作家人数等。 （2）过程指标：使用内容导入人数、内容发布转化率、文章互动率等。   指标选取之后，就是选择分析维度了，而维度选择层面主要是通过数据分析视角结合实际业务场景来确定。例如：用户标签维度、时间维度、渠道维度等。   2.2.3 指标分级 指标分级主要是将指标化解为不同层级并逐级分析。根据企业战略、企业组织及业务进行自上而下的分级，对指标进行层层剖析，其中可结合 OSM 模型来确定指标。   1）一级指标：公司战略层 用于衡量公司整体目标完成情况，与公司当前业务紧密结合，并对所有员工均有核心的指导意义。一级指标通常指引着公司的战略。   一级指标通常根据市场、产品生命周期、产品品类和商业模式确定，一个时间点只有一个最关键的指标（OMTM，One Metric That Matters）。   例如：小红书的OMTM（又称：北极星指标）如何演变？   2）二级指标：业务策略层 为达成战略目标，公司会对其进一步拆解为业务线或事业群的核心指标。通常为了实现一级指标，企业会做出相应的策略，二级指标也会与这些策略有所关联。   例如：小红书当前的一级指标是销售额，那么二级指标可以设定为不同品类商品的销售额，分地区的销售额等。这样当一级指标出现问题的时候，我们可以快速定位问题所在。   3）三级指标：业务执行层 三级指标是将二级指标纵向展开，进行路径拆解、漏斗拆解、公式拆解。三级指标通常用于定位二级指标的问题，通常指导一线运营或分析人员开展工作。三级指标是业务中最多的指标。   路径拆解需要对业务流程进行分析，例如：打开应用、浏览首页、浏览商品详情页、加入购物车、提交订单、订单支付、支付成功。   运用公式拆解月活跃用户，如下图。   2.2.4 AARRR AARRR 模型就是海盗模型，也是用户分析的经典模型。它反映了增长贯穿于用户生命周期的各个阶段，即获取（Acquisition）、激活（Activation）、留存（Retention）、变现（Revenue）、自传播（Referral）。   1）获取 运营人员通过各种渠道进行推广，以各种手段获取目标用户，评估各种营销渠道效果，并不断调整运营策略，以不断降低获客成本。 关键指标：曝光量、点击、下载、安装、激活、安装率、激活率、注册转化率、留存率、付费率等。   2）激活 激活指目标用户开始使用产品。产品经理通过新手奖励、产品引导等方式，来引导用户使用产品核心功能。我们需要掌握用户的行为数据，监控产品健康程度。 关键指标：新老用户占比、DAU/WAU/MAU、日均登录次数、日均使用时长等。   3）留存 通常维护一个老用户的成本要远远低于获取一个新用户的成本，所以不仅要拉新用户，还需要关注用户粘性，以及关注用户在哪里流失、为什么流失。 关键指标：新用户留存率、老用户留存率、活跃用户留存率、日周月留存率、流失率等。   4）变现 主要用来衡量产品的商业价值，这也是商业的本质。 关键指标：ARPU、ARPPU、付费率（区分新老用户）、客单价、LTV 等。   5）自传播 主要是基于产品、营销、明星等事件的吸引力，从而使用户自发地传播。 关键指标：裂变系数等。   3 埋点   数据采集，就是采集相应的数据，是数据流的起点，采集的对不对、全不全，直接决定数据的质量，影响后续的所有环节。那么采集什么样的数据才算是质量高？这就需要提前规划埋点。   3.1 什么是埋点 埋点是（用户行为）数据采集领域的术语。它的学名叫做事件追踪（Event Tracking）。它主要是针对特定用户行为或事件进行捕获、处理和发生的相关技术及其实施过程，如用户点击某个按钮的次数、阅读某篇文章的时长等等。   埋点是一种常用的数据采集方法，它是为了满足丰富的数据应用而做的用户行为过程及结果记录。埋点是数据采集的一种重要方法，并且是数据的起源，采集的数据常常用于分析产品的使用情况、用户行为偏好等，于是延伸出用户画像、用户推荐系统等数据产品。   3.2 埋点流程 业务部门根据业务提出需求，产品经理将需求整理为数据需求，并输出数据需求文档（DRD，Data Requirements Document）。   接下来，产品经理就跟数据团队进行需求评审，评审通过与否，会后都要给相关人员发送需求评审纪要邮件。评审通过之后，产品经理需要跟开发工程师确定开发时间，并发送排期邮件。   开发完成后，测试工程师、数据分析师、产品经理需要验证埋点是否完整且准确，提交验收报告。功能上线后，产品经理或开发工程师需要发送上线邮件。如下图。   3.3 如何埋点 怎么埋呢？从业务角度出发，划分五个角度：   Who：对行为的发起者进行标识，一般使用账号或设备号进行标识。账号是常用的方式，通过身份证号、手机号、账号 ID 等信息区分用户；设备号多用于不需要登录的产品，通过设备的编码来区分用户。   When：记录行为是什么时候发生的，一般使用服务器时间，即 Unix 时间戳记录行为发生时间。它是全球统一时间，不受地区的干扰。   Where：记录行为发生的地点，一般通过 GPS 进行定位，或者通过设备 IP 判断用户位置。   What：指用户行为的具体内容是什么，比如用户阅读一本书，那么购买的书名是什么？价格是多少？哪个出版社出版等信息。   How：行为是怎么发生的，一般包含在行为名称中，如提交某订单，也有若干行为是可以通过多种方式完成，如解锁 iPhone，可以输入密码解锁，也可以刷脸解锁，无论使用哪种方式都是一种可以记录的信息。   3.4 案例：浏览APP首页行为埋点 针对浏览某电商 APP 首页行为，从五个角度分析，分为特有指标和公共指标两类，如下图。   3.5 案例：支付订单行为埋点 针对支付订单行为，从五个角度分析，分为特有指标和公共指标两类，如下图。   四 数据分析   4.1 什么是数据分析？ 数据分析是指用适当的统计、分析方法对收集来的大量数据进行分析，提取有用信息和形成结论，并对数据加以详细研究和概括总结的过程。简单地说，就是对数据进行分析。   数据分析的目的是把隐藏在一些看似杂乱无章的数据背后的信息挖掘出来，提炼出目标对象的内在规律。对于企业来说，数据分析的本质在于创造商业价值，驱动企业业务增长。   4.2 数据分析方法 我们以一个电商网站为例，用数据产品对该网站进行数据采集，然后使用常见的数据分析方法分析，如漏斗分析、留存分析、时间分析、用户画像、渠道分析、分布分析等方法。   4.2.1 漏斗分析 漏斗分析能够科学反映用户行为状态，以及从起点到终点各业务流程的用户转化率情况，是一种重要的流程式数据分析模型。漏斗分析模型已经广泛应用于用户行为分析中，例如渠道质量评估、产品销售等日常数据运营与数据分析工作中。   比如：对于电商产品来说，最终目的是让用户购买商品，但整个流程的转化率由每一步的转化率综合而定。这时，我们就可以通过漏斗分析模型进行监测。如下图所示，我们可以观察用户在每一个层级上的转化率，寻找转化路径的薄弱点，优化产品，提升用户体验，最终提升整体的转化率。   4.2.2 留存分析 留存分析是一种用来分析用户参与情况/活跃程度的分析模型，即由初期的新用户转化为活跃用户、忠诚用户的过程。随着统计数字的变化，相关人员可看到不同阶段的用户变化情况，从而判断产品对用户的粘性。   比如：对某电商平台来说，用户最近 30 日的 7 日留存率（如下图），从图中得知，用户留存率较低。接下来，按照地区、年龄、行为等，将用户分为不同的群体，观察留存的区别，找到产品可优化点。   4.2.3 事件分析 事件分析用来研究某事件的发生对企业的影响以及影响的程度。通常来说，事件分析包括事件定义与选择、下钻分析、结果等环节。   事件，是一个用户在某个时间点、某个地方、以某种方式完成了某个具体的事情。它的关键因素包括 Who、When、Where、What、How。   比如：运营人员发现过去 30 日支付成功次数波动较大（如下图）。这时企业可以先定义事件，通过筛选条件配送方式为 “自营”，再从其他多个维度细分下钻，如 “订单金额”、“是否使用优惠券”、“商品ID” 等。当进行细分筛选时，异常数据无处遁形。   4.2.4 渠道分析 渠道，是指产品与用户发生互动的各个接触点，比如 SEO、SEM、社交媒体等等。   渠道分析主要用于分析用户的访问来源及访问深度，通过访问用户数、访问次数、停留时长等指标来评估渠道质量，同时也通过转化率来衡量渠道转化的效果。   一个完整的渠道流程，常常包括：站外渠道 -> 展示广告 -> 着陆页 -> 访问着陆页的转化文案 -> 激活用户 -> 产品转化 六大关键环节，每个环节都有相应的指标来衡量。   1）用户在站外渠道，包括 SEO、SEM、社交媒体等，看到各种宣传广告。 关键指标：展示量、点击量、CTR（Click Through Rate，点击率）。   2）有兴趣的用户点击 URL 链接进入着陆页。 关键指标：着陆页 PV、着陆页 UV、加载时长、跳出率等。   3）对产品或服务感兴趣的用户下载、注册或者试用产品或服务，这个过程通常称之为激活。 关键指标：停留时长、访问深度等。   4）用户激活后，点击 CTA（Call To Action，召唤用户行为）选择商品加入购物车并提交、支付，这就是一个完整的购买流程。 关键指标：购买用户人数、产品内转化率等。   以上是四种常用的数据分析方法，在不同行业中，它们常常以不同的样式展示出来，当我们面对不同的问题时，需要清楚地知道哪个或哪几个方法最为有效，需要结合具体场景灵活运用，没有最好的分析方法只有最适合的。  

01 前言 随着互联网时代的到来，各行各业都开始融入“ 互联网+” 的思维。从最开始的TOC的服务&消费型产品，到如今TOB的数字化转型，数据越来越重要。打开京东淘宝，头条抖音，里面琳琅满目的商品推荐，视频推荐。   那么，问题来了，这些算法上千人千面的推荐，是怎么做到的？答案：用户行为数据。   那再深入一些，如何更精准的拿到 用户行为数据？ 答案：埋点。 这就是今天我们要讲述的内容：数据埋点。   02 埋点简介 定义：埋点是用户行为数据的来源。   目前来说，大部分企业对于用户行为数据的获取，都是在各个终端上设置埋点。 通过各种各样的埋点，拿到相应的用户行为数据。用于下游的统计分析和业务迭代。   主流的方式有两种： 第一种：公司自研，在产品的各个页面、（可交互）模块，按照一定的规范，“注入”统计代码。 第二种：第三方统计工具，如友盟，神策，GrowingIO等第三方监测平台的接入。   各个公司随着业务的不断扩大，一般都会选择自研发，并设定相应的埋点规则和统计规则。   我们这期重点就来聊聊“埋点规范”的设计。   03 埋点参数 一般来说，埋点主要由两个部分组成：公参和业务参数。   公参 什么是公参？通俗来说，就是无论这个业务怎么变，每个埋点中都必须有的值。   举个例子，用户的业务id（如 uid），就是公参；用户的手机imei，也是公参。我们可以根据我们的业务形态，及我们一定需要的数据，给出公参。   一般公参有4个要素：用户识别 、设备识别 、 页面识别 、关联识别。   用户识别：顾名思义，用户的唯一标识。即用户无论在哪台手机（终端）上登陆，我们都能映射到该app下的唯一用户的标识；且对应到这个用户上的一些固定信息，如手机号，实验分桶标识等常用信息。   设备识别：由于用户可能在不同的机型上，所以我们需要记录到设别信息，如imei，手机型号，手机系统等。   页面识别：特定的页面上的信息，如搜索，我们需要每个页面都透传用户的搜索词；如头条，可能需要每一次打开app的行为id，这些特定的，非业务参数信息，都可以记录到页面识别参数里。   关联识别：由于行为和行为之间，会有链路的串联关系，所以我们需要记录页面之间的关联关系参数。比如：页面和页面之间的关系，我们可以记录 来源页面；模块和页面之间的关系，我们可以记录 来源模块；如果所有页面流量都有算到某一页面上，那我们可以将 该页面识别（如页面id）透传至需要统计的页面。   业务参数 业务参数，就是对应到具体的产品模块，展现内容等具体业务上需要统计的内容的映射值。   对于业务参数的设计，我们在下文中会具体讲解如何定业务参数。   04 埋点设计方法 每个公司，每个业务都会有独特的埋点方案，但是无论哪种埋点，我们都会有个明确的层级及关系划分。这里主要介绍两种较通用的埋点方案，为大家埋点设计提供一定的参考。   模块式埋点 模块式埋点，就是用产品本身，肉眼可见的明确区分的模块，来构建业务参数。   每个app，都由多个页面组成，不同的页面及页面上的功能组合，构建了一个app。 所以，我们可以定义模块式埋点的第一个层级：页面。   具体到某一个具体页面，我们可以较明确的区分出区域，比如微信信息列表页，我们可以较明确的看到三个区域：头部区域（搜索框 & 右上角的加号），中间信息列表区域，底部4个按钮区域。这些明确可以划分的区域，我们可以定义成第二个层级：区域。   而在看这些区域中的具体 可以交互 的内容（或者功能），我们可以定义成第三个层级：按钮。比如头部区域中的搜索框点击，右上角加号的点击；中间信息列表区域的聊天窗口点击；底部按钮区的四个按钮的点击。   这样，我们把三个层级串联起来，就形成了这样一套业务埋点规则：页面_区域_按钮。   当然，我们可能还需要记录某些具体的业务附加信息。   如点击聊天列表，是点击了群聊，还是好友，我们可以记录一个聊天类型，而对应的如好友id，群聊id，我们也可以记录在附加信息中。   这些附加信息，我们也可以记录到具体的参数值里，但这个参数需要和模块层级埋点区分，不能埋在同一个值中，这点需要注意。   比如上文所述的微信的埋点，我们可以这样标记：     我们按照上述结构，将页面&区域&按钮链接在一起（比如以 @ 符号关联），就形成了该页面的埋点，如页面展现，我们可以打点为 wx_list_page@0@0,如公众号点击，我们可以打点为wx_list_page@talk_list@pub_acc_clk，以此类推。   如果我们想统计中间区域的点击，那么我们之需要把点击埋点截断至 区域，不用明确区分按钮，我们就能很方便的统计出想要的区域，页面，点位上的数据。   内容式埋点 和模块式埋点类似，模块式埋点是产品本身的层级区分，内容式埋点是内容本身的层级区分。   内容式埋点一般会应用在广告等内容的数据统计上。 首先，我们需要一个串联ID来串联前端数据和服务端数据。   往上层，我们需要知道这个串联id属于什么内容，这时需要内容id。再往上，内容id属于哪种大的类目，这时需要内容分类。   这个就是内容埋点，同模块埋点，内容埋点需要有明确的内容层级区分。 而这时基础层级，串联后就形成了内容埋点规范：内容分类_内容id_串联id。   当然，模块式埋点以及内容式埋点还可以继续往上层划分，比如 模块式埋点可以增加至 产品_业务_页面_区域_按钮；内容式埋点可以增加至 业务_系统_内容分类_内容id_串联id。   这些都可以根据特定的业务场景修改，只要有相应的层级划分，统计起来就会方便很多。   05 埋点TIPS 事件分类 一般情况下，主要有3类埋点：展现埋点 + 曝光埋点 + 点击/输入框 等交互埋点 + 自定义埋点。   展现埋点：通俗来说，某个页面里的内容被展现了。   怎么定义展现，这个其实就是一个服务端的触发。服务端如果触发了，用户侧会展现什么内容。   由打点时机可以明确出，展现埋点需要记录的是 页面展现的内容信息。   也就是说，服务端下发的内容都包含什么（这些东西一定是当前页面主要内容，不包含一些交互信息）。   曝光埋点：哪些下发的内容被用户实际看到了。   和展现埋点类似，由于屏幕有限，但内容可以无限。哪些内容被用户侧实际看到（曝光），我们也需要记录下来。   不同的是，曝光埋点，我们需要记录的是单个“内容”被看到，不能是一串内容。一串内容，可以触发多次曝光埋点，但是曝光埋点一定是单个“内容”。   交互埋点：哪些功能/内容被用户“点击”了。   从埋点时机来说，这个是展现 & 曝光的下游。 记录的是，对于我们提供的“服务”的“消费”情况。   比如，一个页面，用户可以点击，那么我们需要记录相应的交互埋点；比如，一个视频可以点赞，我们也可以记录交互埋点；比如，一个视频可以播放暂停，我们也可以记录消费埋点。   总体来说，就是，我们要记录 被看到的可交互功能/信息的“消费”数据。   自定义埋点：随着业务的发展，产品种类越来越多，总会有需要特殊埋点的地方，可以留一个自定义埋点备用，总要给业务一个机会嘛（玩笑话）。   埋点记录 关于埋点记录，或者叫埋点文档，我们只要明确记录两个信息：点位信息 & 点位映射。   点位信息：明确每个业务事件下的具体的参数信息，即上文所述的公参+业务参数。   点位映射：每个埋点对应的业务含义。   只要埋点文档中记录了这两个内容，那么这份埋点文档就是一个合格的埋点文档。   当然，上文所说的层级，参数，事件等，都是一份好的埋点设计的组成“成分”。 多思考，多参考，相信大家都能设计出合适自己业务的埋点规范。   编辑于 2021-10-19 08:52

前言 在上一篇文章数据人该知道的埋点体系（一）中主要介绍了埋点的数据从产生到使用的数据流转体系以及如何来设计埋点。接下来在本文我来介绍埋点的开发流程和埋点数据的使用。   03 埋点开发流程 1.埋点SDK 由于我们的埋点是采用代码埋点方式，每一个用户行为的触发都需要写代码来标记。如果采用纯手动的方式，将有庞大的代码量。也会有让程序员觉得一直写重复且无提升的体力活代码。因此我们引入了阿里云的开源埋点SDK，并进行二次开发以适配公司的业务。   通过阿里云的埋点SDK，开发者可以在自己的APP中便捷地进行数据埋点，监控日常的业务数据与网络性能数据，并通过阿里云控制台界面观察对应的数据报表展现。另外，用户后续可以通过设定自定义的数据解析规则（也就是阿里云的日志服务收集数据并投递至数仓）实现定制化的数据图表展现。   埋点SDK可以有通用的方案统计接口调用式的埋点，比如会员登录、会员注册等；也可以有页面埋点，比如页面进入、页面离开；还有页面事件，设置好页面名称、页面 refer、页面停留时间、页面事件扩展参数就可以组装日志成日志map。最后也是支持自定义事件以满足客制化的需求。   2.埋点开发流程 埋点的开发一般是由产品经理确认业务数据需求，然后和数据分析师一起讨论需求是否合理。如果合理就有数据分析确认现有埋点是否能满足需求，如果不能就需要数据分析基于需求设计埋点。设计完成之后邀请客户端、web、测试等参与埋点需求评审，评审完成后类似于普通需求的流程进行需求开发。开发测试完成后由QA介入测试，最后由数据分析师进行埋点的验收。   埋点开发流程图   3.埋点验收流程 由于埋点的开发需要跟随着客户端的发版进行，具有不可逆的特征。一旦发版后出现埋点问题就需要重新发版解决，而且还有版本覆盖率的问题。这样一来二去就就会耽搁不少时间，会因缺乏数据影响对产品功能的决策。在大部分互联网公司都是需要小步快跑的形式去迭代，因此埋点数据的准确性对公司来说是非常重要的。   如何来保障的埋点的准确性呢？首先采用集成SDK的方式规范和减少埋点的代码的开发量，其次有多个验收流程来保障准确性，先有开发进行自测，然后是QA组进行测试，最后由数据分析进行埋点的验收。版本开发完成不直接进行发布，先进行少量的灰度发版测试，来观察埋点数据的是否大致符合预期。最后一系列的流程都没问题后进行版本的全量发布。   埋点验收流程   最后来介绍2款埋点抓包工具，Android手机抓包埋点日志需要下载Android Studio，最好是2.3版本，这样方便打印日志。iOS手机抓包埋点日志需要mac电脑原生的控制台进行。   Android Studio   控制台   04 埋点日志使用 埋点采集的日志通过日志服务投递到数仓后，我们就可以进行一系列的加工来进行使用。   1.业务指标 通过对业务的理解，加工用户行为成为一个个数据指标来监控和迭代业务。比如DAU、功能的曝光点击、页面的停留时长、商品的销售额等等适合业务完整的数据指标体系。   2.性能指标 也可以通过埋点来监控App的性能情况。比如crash率也就是系统指定版本异常退出的次数在该版本中所有启动次数比例；还有次均TCP建连时间，代表网络请求中TCP建立连接的平均耗时，单位毫秒；再有次均首字节到达时间，代表网络请求中首字节到达的平均耗时，单位毫秒。再有次均请求资源大小，代表网络请求完成的平均消耗资源，单位B；最后还有：异常数量，代表发生异常的网络请求数量。   3.数据产品 使用埋点数据还是各种数据产品的数据源，比如BI平台，可视化的展示各项埋点指标数据；ABTest平台，利用埋点数据对比分析实验组和对照组的效果，以更好的帮助业务判断功能策略的好与坏；用户分群，利用埋点的用户行为数据圈选合适的用户群，触达到用户以提供用户的活跃度和粘性。   4.归因模型 在电商领域可以根据埋点日志进行销售归因。我们引入电商坑位归因的概念，把每一笔的成交都归给转化路径的不同的坑位。据坑位的曝光转化价值来评价坑位质量。把宝贵的流量尽可能都引导到转化率更高的坑位，以此达到精细化运营的效果。有了这个坑位价值评判的机制后，各个坑位的改版也能准确的评估，真正做到了数据驱动增长。   埋点体系的介绍到这里就全部结束啦，希望对大家能有所帮助！  

前言   埋点是将用户在App或者网页上各种行为记录下来并且上报的机制。埋点能有效的记录用户各式各样的行为，帮助我们更好的了解用户在我们平台的上行为习惯和使用体验，也能使我们朝着正确的方向迭代产品。本文将向大家介绍埋点的各个核心知识点。   一 埋点数据流向   埋点日志数据流向流程图   1.1 SDK 数据采集&上报   我们公司基于阿里云的开源SDK进行了二次开发，以适配与公司的业务情况。SDK的作用是将采集用户行为并且上报的代码进行打包成一个方法，各个埋点都通用采集的数据统一处理，个性化的采集数据进行抽象化。以便于开发能够快速高效的处理埋点任务。目前我们有iOS SDK、 Android SDK 、web SDK、小程序SDK这4个平台的埋点采集SDK。   SDK通用采集的数据主要有：   app_id 业务App标记Id app_name 业务App标记名称 app_version 业务App的版本号 os 用户使用设备的系统 os_version os的系统版本 device_model 用户使用设备的品牌 local_timestamp 用户设备本地时间戳 reach_time 日志到达服务器时间戳 client_ip ip地址 carrier 网络类型 access 网络运营商   SDK采集主要就是以上的通用信息以及自定义的埋点信息（比如：页面、行为、用户Id等等）   1.2 日志实时采集与消费（LogHub）   我们使用了阿里云的LogHub服务进行日志采集与消费。LogHub主要功能：   通过ECS、容器、移动端、开源软件、JS等接入实时日志数据（例如Metric、Event、BinLog、TextLog等）。 提供实时消费接口，与实时计算及服务对接。   LogHub简介   1.3 日志初步清洗（LogHub-etl ）   这一步的作用对日志进行一次简单的清洗。主要对加密的日志进行解密处理，变成可阅读的样式。对ip地址进行解析，处理成真正的位置信息。对最外层的json解析成各个字段。   1.4 投递数仓（LogShipper）   数据在日志系统后，我们需要将日志投递至存储系统中，这里我们也采有阿里云的数仓投递服务LogShipper。阿里云LogShipper服务算是一个稳定可靠的日志投递。将日志中枢数据投递至存储类服务进行存储。支持压缩、自定义Partition、以及行列等各种存储方式。     1.5 数仓ODS层   在数仓ODS层中进行针对性的清洗工作，主要清洗步骤如下图所示：   ODS层日志清洗流程图   1.6 数仓DW层   在数仓DW层各个业务的数据开发同学基于各个业务的情况处理出一些DW层级的日志表给数据分析的同学进行使用。   1.7 数仓ADS层   数仓的ADS层也就是数据应用层，是数仓中对外展示的部分。也就是运营产品日常工作使用的数据报表或者后台数据看板等等。在这一层也就是基于业务的需要，对用户行为日志进行各种统计汇总成数据指标进行分析。   二 埋点设计思路   如何利用埋点完整的记录和描述用户的一次行为，我们公司目前采用的事件模型来记录。   埋点事件模型   事件模型的埋点数据结构完整地描述了Who、When、Where、How 和 What 五个要素。 Who、When、How 由一般由埋点 SDK 自动生成，埋点设计人员在绝大多数情况下不必关心这三个要素，因此设计的核心是Where，What。   Page 表示app 中的各个页面的页面名称 args_json 表示需要设计的参数，其中较为核心的是以下三个，他们共同描述了‘对什么内容进行了什么操作‘： Bhv_Type： 具体的用户行为，我们称之为‘事件’； LogTrackInfo： 包含server上传的server下发内容的信息； LogExtInfo： 包含客户端上传的本地信息。   接下来重点来介绍这些核心参数的含义：   1). Page   Page定义:app 中的各个页面的页面名称   Page命名方式： 业务模块_核心命名_页面类型 （首字母大写）。 举例： 育儿页面=Parent； 商品详情页=Mall_Normal_Detail. Page的规则： 页面具有注册属性： 即一个页面名只能给一个页面使用； 页面使用前缀来区分业务模块。 页面使用后缀来区分页面类型： 主页，二级列表页，详情页，tab/楼层页。   2). Bhv_Type   Bhv_Type定义：具体的用户行为，我们称之为‘事件’，分为：   内容事件： 曝光=View； 点击=Click。 页面事件： 页面浏览时长=Page_Read App事件： App启动=App_Foreground   页面事件和App事件一般比较少，基本上可以枚举。我们重点在来介绍下内容事件。   通用交互： 特定动作;动作过程完成。 一般就是曝光点击等。 业务事件： 特定动作;业务特有;动作过程完成。 包括分享完成、加入购物车等等。 是一种带着特殊含义的点击行为，需要特殊标记。 按钮类： 页面按钮;server/客户端本地配置;同类型有多个； logTrackInfo信息。 有不要求过程完成。 不需要行为结果成功返回，用户触发即可。 一般用click+按钮名称信息来标记。   3). LogTrackInfo   LogTrackInfo定义:是server给出的埋点信息的载体，由参数和参数组组成。主要包括如下部分：   结构配置信息： 参数组在解释结构是什么，是哪一个； 补充说明结构的父类信息； 确认结构在页面位置。 一般是多对参数组成，例如itemType,ItemId这种样式。 有明确的参数规范。 结构内容信息： 结构内部跳转信息，也就是解释跳转后的内容是什么。 有明确的参数规范。 业务补充信息： 除默认参数外额外需要增加参数来说明用户行为的业务补充说明。 可以自由定义。   4). LogExtInfo   LogExtInfo定义：包含客户端上传的本地信息。客户端专用参数具有双向唯一性，即Duration只返回时长，返回时长只能用Duration。   以上4个埋点业务自定义内容参数就是埋点设计时核心的设计内容，基本能描述清楚90%以上的用户行为，另外复杂的用户行为还可以增加额外的参数来描述，这边就展开讲解。

上篇文章《数据应用系列（1）-ab测试》我们讲述了一些ab测试的基础概念以及对市场上一些第三方平台进行了简单的对比分析。   如有平台使用的需求，各家公司可以根据自身业务情况选择一些厂商进行ab服务的购买，但一般情况下，选择服务厂商都会存在以下问题： 1.公司数据有泄漏风险； 2.平台功能并不完全符合公司业务发展和变动，后期改造成本较大； 3.选用服务成本不低，但是收效却不尽人意等。   所以部分公司权衡后便决定组织人力着手搭建平台，那么一个ab平台究竟要如何搭建，搭建的ab平台如何在业务中应用，实验过程中出现的异常如何应对等一系列问题便会接踵而至。   下面我将从平台的前期准备，业务场景、平台建设以及异常处理四个方面来讲述一下整个搭建的过程。   01 前期准备   所谓前期准备就是立项前的一个评估，评估在什么“前提”下公司可以开始投入人力搭建ab平台。   01 有足够量级的用户基础 这里的用户量级不仅仅是指app本身、还包括具体功能使用的人数量级，再具体点来说就是进入实验的用户量级，ab测试之所以有科学性主要是引用了统计学的评估原理，根据z检验的公式：       可以很直观的看出：如果样本量很小，单个用户的行为表现就具有极大的影响力，极易造成两个版本的差异变大，无法客观的评估实验结论是具有统计学意义的。     02 功能模块可以进行精细化控制   ab实验的原理上一章我也有所描述，整体流程类似于控制变量法，那既然是控制变量，就要通过对已知变量的控制来减少误差对实验的影响，即实验过程中只对某一变量因素进行控制，因此需要在功能切分上做到相对精细化的控制，避免引入其他影响因素造成实验结果不具备参考价值。     03 能客观接受实验结果和实验结果的“代价”   ab测试前期需要投入较大的研发成本，而实验过程平均周期也需要2-3周，最终得到的结果却不一定符合预期，甚至不一定是正向表现，需要反复的进行实验探究。一次实验从开始到最终结论产出的这个煎熬过程和”损失“需要我们能理性的接受。     01 学会“三思后行”   ab测试并非是解决决策“分歧”的唯一依据，我们要以思辨的角度先去评估用户反馈的功能是否是产品的主功能或者影响了主流程的使用，毕竟在实验过程中要投入大量的人力和时间成本。   笔者在ab测试问题复盘的过程中，经常发现很多无故的放大用户需求的案例，最终的实验结果达不到最初的预期。所以在实验设计阶段或实验评审阶段大家尽量做到”三思而后行“。   上述列举的几点是笔者认为几个比较重要的因素，大家也可以结合自身业务特性进行其他角度的思考和补充。有了搭建ab平台的一些前置要素。下面我们进入第二篇内容，看一下公司中都有哪些业务场景需要进行ab测试：     02 业务场景   36Kr曾在一篇报道中写道，“头条发布一个新APP，其名字都必须打N个包放到各大应用市场进行多次A/B 测试才能决定。   张一鸣告诉同事：哪怕你有99.9%的把握那是最好的一个名字，测一下又有什么关系呢？那互联网行业中都有哪些场景需要ab测试呢？下面我简单整理了一下不同角色工作中适用ab测试的业务场景：         列表中的是否发版用以判断实验变量控制位置，需要发版一般版本id要在客户端进行版本判断，不需要发版一般可通过服务端进行判断，按需则根据具体功能实现方式来选择。   数据来源是作为实验效果评估的主要数据依据。例如客户端实验主要以sdk采集的用户行为数据为主，服务端实验若无法全面的获取用户数据，则以服务端日志为主要依据，例如push实验，用户不点击push打开，则无法统计到用户行为数据，只有服务端记录的push下发相关的数据。     03 平台建设   上面我们描述了一下平台搭建的前期准备和适用的业务场景。本章我们拆解一下平台如何进行建设，在开始这部分前，我选用上面一个流程优化的场景，通过一段”日常“对话来描述一下平台的需求都有哪些，方便大家进行理解：   业务产品经理：最近收到一批忠实用户的反馈，内容创作的入口应该从「我」中拿到主页面，我们想调整一下看不同入口位置哪种效果最好，目前已经设计了3个方案想搞个ab实验，选一个最优版本来代替当前版本上线。   平台产品经理：你们新版本大概什么时间开发好？实验需要运行多久？ 业务产品经理：大概2021年1月1号能开发完，实验周期的话预计2周时间   平台产品经理：你需要提前想一下实验的名字，不然这么多实验列表里不好找你的实验。哦对了，你们这次实验大概要用多少用户？ 业务产品经理：3个方案的话加上当前对照组，怎么也得用至少总体的20%的用户去验证效果   平台产品经理：那下次发版时间大概什么时候？ 业务产品经理：预计过完年后，2月底了，这个版本功能比较多，所以如果数据效果好，看能不能通过平台直接全量到线上，过年大家是大家分享的黄金时间，所以来不及等下次发版功能代码开发了   平台产品经理：好滴!我们平台马上也要上线了，到时候可以直接在平台操作，不会耽误你们进度的。   从对话中我们提取几个关键词（红字标记）：     通过简单的一个场景描述，我们可以看到，一个ab系统的核心模块至少包括以下四个：       01 实验信息管理   该模块主要是记录实验业务信息方便方便解读和查询，最少需要记录以下信息：       02 实验变量管理   该模块用以确定变量版本，方便逻辑控制。同样，需要的字段和每个字段的意义我以表格形式进行了整理：     该模块下需要提供版本个数的增删操作，方便用户进行临时版本的增加和删除操作     03 实验流量管理 实验流量管理模块应该是ab平台的核心功能之一，承载着确定变量流量，保证各版本分配的用户成分相似。但在互联网行业每天可能进行众多的实验，为了解决实验流量不够的问题，现通过引入流量层的方式来解决，所以实验流量就会出现正交&互斥的特性，那我在这里再简单描述一下相关知识点：   互斥 所谓互斥是指同层同时运行多个实验，彼此占用的用户不会被其他实验所占用，详见下图：     正交   正交是指，相同的用户在不同层都会被随机打散，以便以足够离散的支持不同的实验，详见下图：   那我们如何实现的流量的控制（离散和圈定），主要有三个方面：哈希算法、哈希因子以及流量确认。   哈希算法 业界比较常用的算法是murmurhash，共有三个版本（murmurhash、murmurhash2、murmurhash3），这种算法是一种非加密型哈希函数，适用于一般的哈希检索操作，其优点如下： 1）简单（就生成的汇编指令而言）。 2）良好的分布（通过几乎所有键集和存储桶大小的卡方检验） 3）良好的雪崩行为（最大偏差为0.5％）。 4）良好的抗碰撞能力（通过了鲍勃·詹金的frog.c酷刑测试。4字节密钥不可能发生冲突，差异不大（1至7位）。 5）在Intel / AMD硬件上具有出色的性能，在哈希质量和CPU消耗之间进行了很好的权衡。   当然还可以根据设备id的尾号进行分流，常用的分流算法有 crc_32、sha_256等，但是使用场景具有一定局限性：需要用户量足够大、设备id分布足够均匀、实验组数量不宜过多。   哈希因子 所谓的哈希因子，通俗的来讲就是被哈希的对象，一般情况下设备id（deviceid）、流量层id（layerid）就够了、还有一些统一测试平台还会涉及应用key或应用id（appid）、美团的业务场景下还会引入区域的id（areaid），所以一个哈希因子就变成了appid_areaid_layerid_deviceid。   流量确认 通过哈希算法和哈希因子可以最终确定一个1-n的位置，假设是1-100，则某一层的总流量就是1-100，业务方通过平台上操作的实验版本个数和版本流量，来确定这个实验1-100的位置如何分配，就完成了一次实验的流量确认的过程，下图就展示了正交&互斥的完整流量确认的流程。   实验效果评估 通过实验信息配置、版本和流量分配、实验周期的控制，最后一步就是通过实验数据来验证版本效果好坏，那我们要关注哪些数据呢？   1）北极星指标 所谓北极星指标就是业务核心发展的重点指标，换句话说今年kpi就全靠他了，所以实验版本的效果提升，都是采用对北极星指标正向的影响   2）业务相关指标 是指业务人员关注对策略改版本身有所影响的指标以及其他辅助指标的波动情况，从时效性上可分天级、小时级、分钟级   3）统计相关信息 每个指标的p值、置信区间、统计功效 除了以上指标，还可以观测ab测试版本中功能后续使用的留存情况，进一步去评估本次实验效果是真的好，还是偶然的好   上面根据业务场景和需求讲述了ab平台搭建需要的一些基本模块，下面我们就来将这些模块开始有机的组装和流转：   页面参考： 1）创建实验   2）指标查看   除了上述页面还应该提供一些管理页面，包括：用户管理、角色管理、应用管理（如果有多app的话）、元数据管理、流量层管理、指标管理等，这些页面这里就不作样例展示了，大家可根据自身业务特性来发挥想象。以上页面展示仅为参考，为方便大家便于理解上述所描述的内容。   业务处理流程：   上图中蓝色线代表了以客户端为逻辑判断的主要流程，红色线代表以服务端为逻辑判断的主要流程，不同的逻辑判断位置即代表了业务架构的差异性也影响数据获取的方式。   除了abtestsdk请求策略层获取版本id用以app端逻辑判断或传递给服务端进行逻辑判断外，还有通过业务服务端直接请求策略层进行逻辑判断的方式，如push实验，本身特性是无论是否有用户点击app，都需要根据push平台进行策略下发。第二节业务场景中所描述的是否发版和数据获取来源直接决定了ab的接入方式和效果评估的数据来源   功能框架参考：     04 异常处理   通过前期评估、业务场景、系统流转以及平台功能的框架，基本一套完整的ab平台就已经初具雏形，下面我们就可以按照以下的操作流程开始进行ab实验，对每次策略进行效果评估：     在本文的第一章节有提及，我们要理性的接受ab测试过程中得出的结论可能无效甚至与预期相悖的，不过这些也不一定是实验本身策略的问题，那么有哪些因素会导致实验“无效”并且怎么去解决呢？   01 实验周期 很多童鞋在做实验时特别着急的想去看结果，甚至迫不及待的实验开启几天就已经开始决定要上线，这样的做法显然是不可取的，实验周期的长短影响主要有以下几个方面：   a.影响样本量的大小；样本量决定了样本的代表性和实验的可参考性；   b.用户行为习惯影响数据指标，比如节日效应，或者例如有些工具类app工作日使用会较频繁，周末会下降；   c.影响进入实验的用户情况，因每天用户活跃情况不同，若观测时期较短，可能会因一天的数据问题导致整体数据指标很大或者很小   d.科学的实验周期应该在2-4周范围内。尽量涵盖到目标样本量以及所有时间维度上（工作日、节假日）      02 辛普森悖论 辛普森悖论是指当人们尝试探究两种变量（比如新生录取率与性别）是否具有相关性的时候，会分别对之进行分组研究。然而，在分组比较中都占优势的一方，在总评中有时反而是失势的一方，我们可以通过下面的例子简单理解一下：   目标：男生的录取率高于女生 方式：各学院提高男生的招聘率       上面可以直观的看到，单看商学院和法学院都是男生录取率比较高。但是总体情况确实女生录取率（42%）是男生录取率（21%）的两倍。映射到ab实验上，实验版本和对照版本其实分别就对应的是女生和男生的录取率，辛普森现象的本质是通过加权平均引起的，而且样本量越大越容易出现这种情况。   所以如果要规避这个问题主要采用： 1）策略上线前，要尽可能的进行多维度分析，找出可能会影响的因素； 2）实验分流前尽量选取合适的样本量，避免因样本量过大造成的反结果； 3）实验方案设计时，要在相同量级的维度下进行实验。例如为了节省成本，将一个策略同时在双端进行实验，但本身android的用户量会大于ios，实验结论从整体看效果是正向的，但实际ios可能完全与其相悖   03 幸存者偏差 “幸存者偏差”是指，当信息来源，仅来自于幸存者时（因为死人不会说话），这个信息可能会存在与实际情况不同的偏差。所以大家在实验结果分析过程中，不仅仅要看用户行为数据与有版本id用户（即进入实验的用户）产生的指标情况，还应看有版本id的用户中具体触发这些用户数据的表现情况，综合来评判版本实验效果。   04 缓存问题 为了保证实验能在客户端稳定运行，避免造成实验组和对照组来回波动的情况，一般会采用缓存策略。但在实际进行ab实验时，存在对已经结束的实验进行重新开启的情况，此时这个”新实验“会受到之前实验分桶流量的影响；同时还要考虑每次启动app时请求分桶流量的时机，尽量保证实验组和对照组在没有波动的情况下获取到最新的分流策略。   05 样本量选择 样本量的大小影响显著性水平、统计功效等。样本量太小，不具代表性，得出的结论不可信；样本量太大，容易导致辛普森悖论，需要的实验周期长，同时流量有限又不能无限扩大，那多少样本量合适，我们可以根据公式进行反推，也可以用样本量测算工具（https://www.evanmiller.org/ab-testing/sample-size.html）计算。     在实际测试操作中，很多童鞋也会有这样的问题就是，既然我们统计的都是转化率这种相对指标，是不是我们实验组和对照组的样本量可以不相等，比如对照组1000人，实验组5000人，针对于这种问题，我们可以进行个假设：若实验组的流量是最小样本量，那证明对照组样本不够，极容易导致实验不可科学；   若对照组是最小样本量，那”过载“的用户样本，会导致用户数据偏移、样本数据“浪费”以及辛普森等问题。所以大家在实验过程中要尽量保证不同版本的样本量一致。   06 分流评估 业务童鞋在使用我们搭建好的平台，无论实验做的如何：可能是实验结果不符合他们预期，也可能是因业务接入问题导致实验失败，即使ab平台没问题也会先被质疑一番。 而分流是否合理便是第一个被质疑的对象，所以作为平台方我们即使用了当前最牛的分流算法，在平台功能上也要提供：分流数据实时、小时的进入流量的情况以及不同画像特征维度下实验组和对照组的数据分布情况，如果十分有必要甚至可以让业务每次实验都应该进行aab实验，用aa实验结果的准确性来保障平台的可信度。   虽然aa实验是验证ab平台数据准确性的有效手段，原则上aa实验（实验组和对照组的策略一模一样）的数据表现应该是一致的，但是有时候却发现两组指标竟然出现了差别，即使反复验证也会出现这种情况，这种情况就是aa实验的波动性。   导致这个问题的主要原因就是抽样的随机性，举个简单的例子：即使同样性别的双胞胎，经过相同条件下培训，最终答题的分数也不一定是一模一样的。所以如果要解决这个问题，可以考虑适当提升aa实验样本量的大小，在一定程度上可以抵消这种波动性。     05 总结   A/B测试作为当前互联网领域用户增长、精细化决策的核心技能，越来越多的被各家公司作为基础能力所要求。   本文我们简单总结了一下ab平台系统搭建以及大家在平台使用过程中会遇到的一些问题，如果是此时你正需要搭建一个ab平台，希望读完后能起到一定的启发作用。   如果是平台的使用方，希望可以让大家加深对ab测试的理解。通过异常处理章节中的内容我们也可以看到，想做好一个科学的ab实验并非一件容易的事，需要大家积极拆解业务，理解ab测试原理和流程，以及统计学的相关知识。   希望大家可以在工作中灵活运用这一技能，为企业带来更大的增长效益。最后提前预祝大家新年快乐，事事如意，工作牛到飞起。

01 为什么需要ab测试 大家在日常工作中是否会遇到以下问题： 1）产品经理提出一个竞品没有的功能，即便感觉自己引领了行业，但老版：“这个功能竞品都没有为啥要做？”好不容易说通了老板，到了开发大佬评审时：“这功能对用户好像没用啊，要想说服开发，又要经历一轮苦口婆心，心累！ 2）新功能经历灰度发版后，上线之后数据增长下跌是否是因为这次功能或策略导致，要想拆分清楚，分析师小伙伴又要经历一次抽丝剥茧 3）我有两个想法，但不确定哪个对用户更有效，如何能进行验证…… 我们每天的工作都要处理各种各样的决策，而人们决策的方式会偏好自己习惯或者熟悉的方式，但往往结论与其相悖，要想以实际效果来驱动业务。   这就需要一个科学、并行、可操作的方法来验证每一种策略的可能性，这种方法就是我们今天要讲的A/B测试。近几年来随着用户增长，精细化分析概念的普及，作为核心方法的ab测试也仿佛成为了互联网圈小伙伴们必须掌握的基础技能之一。 Google、facebook、linkin、快手、字节等国内外大厂都把ab测试结果作为推动业务发展的基础。但ab测试方法具有一定的使用门槛，对于业务人员需要具备统计学、平台操作等相关知识；对于平台人员需要具备统计学、平台设计、数据采集、系统搭建以及异常问题处理等相关知识，乍一听起来，好像有点难度。别慌，听我慢慢给大家逐一阐述。     02 ab测试与控制变量 AB测试的定义是指为Web或App界面或流程制作两个（A/B）或多个（A/B/n）版本，在同一时间维度，分别让组成成分相同（相似）的访客群组（目标人群）随机的访问这些版本，收集各群组的用户体验数据和业务数据，最后分析、评估出最好版本，正式采用。   这条定义有几个关键词，同一时间、组成成分相同，随机访问，目的是尽可能的避免其他变量对实验产生的影响。看完这条定义，不知大家是否有些似曾相识。 我们初中上物理或生物课的时候，老师介绍过一种方法——控制变量法。控制变量法是指把多因素的问题变成多个单因素的问题,只改变其中的某一个因素,从而研究这个因素对事物影响,分别加以研究,最后再综合解决的方法。 该方法最早被设计出来是在进行科学实验时把多因素问题变成单因素问题来研究对事物的影响，目的是为了减少方差。   下面我们来举个例子说明一下控制变量法和ab测试有多么的相似： 例1：某兴趣小组做了个实验，研究问题是种子生长情况收到什么因素影响，提出研究假设：种子生长情况是否收到洗涤剂影响，实验设计如下图： 研究对象 组别 操作 现象 分别放入5粒有嫩芽相同品种的种子 实验组A 棉花中加入洗餐具用的中性洗涤剂 生长收到抑制 实验组B 棉花中加入洗衣服用的合成洗涤剂 生长受到抑制 对照组 加入自来水 正常生长 例2：例如某app打算优化一下签到功能，研究签到功能的点击率受什么因素影响，假设：签到点击率是否受到文案的影响，实验设计如下图： 组别 操作 点击率 涨幅 对照组 签到（线上） 45.00% - 实验组 签到有礼 53.00% +17.78% 实验组 签到得奖 54.34% +18.53% 我们从实验流程角度来看两组实验： 流程 ab测试 控制变量 目标 签到功能收到什么因素影响 种子生长收到什么因素影响 提出假设、猜想 签到点击率是否收到文案的影响 种子生长情况是否收到洗涤剂影响 实验设计 相同组成成分、相同时间下： 1.对照组：展示签到 2.实验组1：签到改为签到有礼 3.实验组2：亲到改为签到得奖 相同光照、相同温度、湿度下： 1.实验组：正常生长 2.实验组1：加入中性洗涤剂 
 3.实验组2: 加入复合洗衣液 
 选取研究对象 相同组成成分的人 相同大小、相同品种的种子 观测实验现象/数据 实验组1、2点击转化率均高于对照组 实验组1、2 生长受到抑制 对照组正常生长 得出结论 签到功能点击转化率受到文案影响 种子生长受到洗涤剂影响 是不是操作流程、设计理念有异曲同工之妙。虽然控制变量法已经被创造了百十年，但这个“古老”的方法也是后期设计实验、设计平台以及数据分析上的一个基本依据。 03 ab测试有哪些优点 那么ab测试在实际运用的过程中有哪些优点呢？ 1.说服力： 我觉得这个优点是首当其冲的，有些时候无论是产品、运营提的想法总会被开发diss，这需求有用么？嗨！有没有用上实验，用数据说话。这套操作下来简直是无形中给我们负责提需求的小伙伴们强有力的支持，长此以往，我相信开发大佬们也会对我们“言听计从”的。
   2.降低风险： ab测试强调先验性，实验确定对用户有效果才会上线，避免了传统操作需上线以后观测数据的方式，对用户影响小的多，降低了“伤害”用户的风险 
   3.符合科学原理： ab实验经过了科学的实验设计、科学的用户抽样、运用科学的统计方法及数据分析得出的结论并采用逐步全量进行上线的方式 
   4.口径统一： 实验组和对照组同时生效、同时展示、采用同样的指标口径进行计算，避免了后期实验结果上因口径不同导致的分歧 
 04 ab的基础知识及作用 ab测试是一种对比分析方法，通过样本对总体的估计，来识别出哪个版本对整体效果最好。下面我们一起看一下要学会ab测试方法需要哪些基础知识。 流量层 可以理解为平行时空，每层人总数是一样的，通过算法进行随机打散，让同一个人在不同层有不同的顺序和标号以便进入到不同实验，规避掉实验上多因素造成的数据偏差，之所以引入流量层的作用是为了解决实验多而流量不够的问题，每层都可以运转实验，结束后流量释放。 正交&互斥 正交&互斥是存在于流量层上，即实验用户同层互斥、不同层正交，通俗来讲就是实验已经占用的用户在同层不会被其他实验占用，但该实验中的用户在其他流量层会被占用，正交&互斥原则是实验设计时基本原则，为了避免实验与实验间互相影响。     均值：表示一组数据集中趋势的量数,在一组数据中所有数据之和再除以这组数据的个数，ab实验中涉及的均值为人均值和转化率，例如人均点击次数、ctr等，在ab测试里作为一个观测指标展示 方差：是指各数据与其均值的离差平方和的平均数，反应每个数据与均值的离散型或者波动性，在ab测试中是计算临界值的一个基本数据。 假设检验：又称统计假设检验，其作用是用来判断样本与样本，样本与总体差异是由抽样误差引起的还是本质差别引起的一种方法。   例如：汽车引擎新排放标准是平均值<20ppm，现某公司抽取10台汽车样本，其引擎排放水平为 15.6 16.2 22.5 20.5 16.4 19.4 16.6 17.9 12.7 13.9，判断该公司汽车是否符合新排放标准？ 若要看排放是否符合标准，首先要建立原假设：排放不符合标准；其次要构造统计量进行相关数据的对比；再次要确定这10台汽车与标准是否具有显著差异，若无差异，最后得出结论。 所以综上假设检验通常需要以下步骤： 1.提出猜想，设定原假设和备择假设 2.构造统计量，根据样本计算相关数值 3.确定显著性水平，进行数据检验 4.得出结论   常用的假设检验的方法有：z检验、t检验、f检验、卡方检验，我们可以根据下图来确定什么检验方式适合自己： 检验方法 试用场景 T检验 样本量较小（<< span="">30）、总体方差未知，服从正态分布，t检验样本量扩大就成了z检验，用以判断两个均值是否差异显著 Z检验 样本量较大(>30)，总体方差未知，服从正态分布，用以判断两个均值是否差异显著 F检验 用以判断两组数据方差是否有显著差异 卡方检验 用以检验实际观测值与理论推断值得偏离程度 其中t检验和z检验为ab测试所使用的检验方式。 正态分布：正态分布是描述连续型变量值分布的曲线，表现形式为中间高两边低，可根据一组数据的均值和方差求得，根据其均值、中位数和众数的大小关系有以下几种表现形式：   若均值（μ）为0（y轴），标准差（σ）为1，则该分布又称标准的正态分布，其在横轴区间（μ-σ,μ+σ）内的面积为68.268949%，横轴区间（μ-1.96σ,μ+1.96σ）内的面积为95.449974%，横轴区间（μ-2.58σ,μ+2.58σ）内的面积为99.730020%。也就是说在这三个置信区间内的概率分别是68.27%、95.45%、99.74%，该概率又成为置信水平。 置信区间：是指用样本均值估计总体均值时允许的误差范围。例如我们要统计全人类的体重，因为无法统计每一个人，但是我们根据规则随机取各个国家1万人的体重求其均值μ，假定做了100组实验，就会有95组实验包含μ，5组不包含。用数学公式标识则为P(μ−1.96nσ<< span="">M<< span="">μ+1.96nσ)=0.95 p值：即发生某件事情的概率，是用来判断假设检验结果的一个参数，若p值很小则证明原假设发生的概率很小。因样本是从总体中随机抽取，所以不能确定样本的表象差别是否通过抽样误差引起，故需要从统计学角度来判断此次抽样是否有统计学意义，其数据解释如下： P值 碰巧的概率 对无效假设 统计意义 P>0.05 碰巧出现的可能性大于5% 不能拒绝原假设 两组无显著差异 P<0.05< span=""> 碰巧出现的可能性小于5% 可以拒绝原假设 两组有显著差异 P<0.01< span=""> 碰巧出现的可能性小于1% 可以拒绝原假设 两者有非常显著差异 显著性差异是说明对比的数据不是来自于同一总体，而是来自于具有差异的两个不同总体，例如大学生和小学生的在学习能力上的对比，就是有极显著差异。 显著性水平α：是在原假设为真时拒绝原假设的概率，根据具体需求选择双侧检验还是单侧检验，详见下图： p值和显著性水平α的关系如下： 1）若P<< span="">=α，那么拒绝原假设 2）若p>α，那么不能拒绝原假设 通常情况下单侧检验取0.05或0.01为拒绝域的临界值，这表明作出接受原假设的决定时，其正确的可能性是95%或99% 统计功效：备择假设成立时，正确的拒绝原假设的概率，我们用下图来说明下什么是统计功效。   红色线是原假设下分布情况，红色区域在原假设分布下为拒绝原假设的概率，其中z值为临界值，统计功效就是该临界值在备择假设的分布下，统计量大于z的概率，即上图绿色区域，公式为1-β。   上面我们知道了以上ab测试所需要的基本概念，那如何运用到实际ab测试中呢。 我们举个例子来看下： 背景：某天a公司产品部门要优化push文案策略对用户点击率的影响   产品经理小a在其公司下的ab平台创建了一个实验，分2个实验组开启实验， 假设：实验版本比对照版本好   实验时间：周期21天，21天后观测效果如下：   版本 均值 变化 95% 置信区间 结果解读 对照版本 1.35 - - - Case1 1.46 +8.0% 统计显著，提升有效 Case2 1.36 +1.0% 非统计显著，效果不显著 根据上表数据，具体推演流程小伙伴们可以根据前面的知识点自己思考一下~ 上面梳理了ab测试的原理、优点以及一些相关的基础概念，如果要实际操作还是需要一个平台来承接，那么一个ab平台都需要具有哪些功能呢？我对比了一下市场上的产品给大家剖析一下。 05 市场工具的竞品分析 市场上提供ab测试相关功能的公司主要有： 国内： 1.云眼https://www.eyeofcloud.com/）abtester（http://www.abtester.cn/） 2.吆喝科技（http://www.appadhoc.com/） 3.智道助手 http://sjmyz.zhidzhushou.com/lp2.html?utm_source=5&utm_medium=sembaidu&utm_term=sem_baidu_data_lz&utm_campaign=bdpcdata9044 4.数极客 https://www.shujike.com/product/abtest.html 5.云测（https://www.testin.cn/）等 国外： 1.Vwo（https://vwo.com/）、 2.Optimizely（https://www.optimizely.com/） 3.Omniture https://www.adobe.com/marketing-cloud.html 我分别用吆喝科技、Optimizely 进行一个简单的“竞品分析”，分别从功能框架、使用流程上来对比一下国内外ab测试产品设计上的差异情况 1）功能框架： 吆喝科技应该是国内提供ab测试首屈一指的大厂，其具体功能如下：   optimizely公司是2010年创立，美国的一家资深提供ab测试服务的公司，功能丰富，自主化操作很强，对于不同场景的兼容也是别具一格，是非常值得大家学习和参考的一个产品，具体功能框架如下： 2）使用流程： 页面展示： 使用流程： 吆喝科技实验流程以引导式的交互方式进行，整个流程相对较“顺”，单从操作角度上而言门槛不是很高。 而Optimizely相对来说比较自由，但每一个操作配置都需要进行代码集成，操作流程较国内而言相对较多，具体如下： 页面展示：   上图为截取的部分配置页面 操作流程： 如果是一次新的操作，Optimizely需要提前配置好指标、受众人群、属性、功能等，每个操作流程都会展示很多配置需要集成在sdk里，对于使用者来说初始化过程有一定成本，不过对于开发者确实比较友好，只需要复制粘贴一段段代码即可，如果有人能提前把相关信息配置好，那用Optimizely进行ab测试还是比较香的。   经过对两个产品的对比，ab测试的功能也就一目了然： 模块 功能 实验 创建实验 复制实验 人群管理 实验管理（流量控制、实验控制） 实验调试 指标管理 指标管理 事件管理 数据 数据概况 数据明细（p值、置信度、统计功效、趋势等） 系统管理 角色管理 权限管理 总结： AB测试是数据驱动增长的核心方法，本文的目的在于能以“通俗易懂”的方式给大家普及一些基本概念，让ab测试的使用和理解不在有“门槛“，全文分别从原理、基本概念以及相关平台建设的角度进行叙述。   但因篇幅有限，相关知识点无法更全面的为大家展开，感兴趣的童鞋可以进行留言，后续相关的文章我也会逐一为大家解答，若文章内描述有错误的也欢迎大家指正。希望大家读完后可以多多思考多多探讨，让ab测试真正能为企业增长作出贡献。 备注： 1.以上功能框架是根据各产品的功能说明文档进行整理，仅供参考，若与实际有差异请于笔者联系，及时修正
   2.流程图并非标准流程图，只对比了主要流程进行的流程示意图


01 什么是OLAP？   说到数据分析，OLAP大概是最常见的选择。因此，作为一名数据人，要想搭建一个业务的数据分析平台，OLAP是你不得不掌握的必备技能。   OLAP(OnLine Analysis Processing ，联机分析处理 ) 是数据仓库系统的主要应用，支持复杂的分析操作，侧重决策支持，并且提供直观易懂的查询结果。在实际的商业分析中，OLAP联机分析更多的是指对数据分析的一种解决方案。   OLAP联机分析首先是把数据预处理成数据立方（Cube），并把有可能的汇总都预先算出来（即预聚合处理），然后在用户选择多维度汇总时，在预先的计算出来的数据基础上很快地计算出用户想要的结果，从而可以更好更快地支持极大数据量的及时分析。   OLAP联机分析最基本的工作就是对数据方（Cube）的操作，因此，首先让我们了解数据方（Cube）的维度层次划分和基本操作，并在此基础上，掌握应该从哪些方面考虑数据并构建出业务模型。为了方便大家的阅读理解，下面所有的举例分析都是基于图一数据方（Cube）的基础上进行的。 图一 数据方（Cube） 02 OLAP的数据源的层次划分   OLAP联机分析是从多维信息、多层次信息的角度，针对特定问题进行数据的汇总分析。因此，站在数据面的角度考虑，数据源需要满足如下层次划分： 维度(Dimension)：是用户观察数据的特定角度，是问题的一类属性，属性集合构成一个维度(时间维、地理维等)。举个例子：图一数据方（Cube）中的季度维度和城市维度。 维度的层次(Level)：用户观察数据的某个特定角度(即某个维度)还可能存在细节程度不同的各个描述方面(时间维包括日期、月份、季度、年)。举个例子：图一数据方（Cube）中的季度维度还可以进一步划分为月份的维度，月度还可以在日期的细节粒度进行描述。 维度的成员(Member)：即维度的一个取值，是数据项在某个维度中位置的描述，如“某年某月某日”是在时间维度上的位置描述。举个例子：2016年一季度是一个维度的成员。 度量(Measure)：多维数组的取值。举个例子：机票在2016年一季度上海市的出票量。   03 OLAP的数据操作   OLAP联机分析是在基于数据方（Cube）的基础上进行操作的。因此，站在分析的角度上，数据源需提供支持钻取(Drill-up和Drill-down)、切片(Slice)和切块(Dice)以及旋转(Pivot)等操作。 钻取：改变维的层次，变换分析的粒度。它包括向下钻取(Drill-down)、向上钻取(Drill-up)。 向上钻取是在某一维上将低层次的细节数据概括到高层次的汇总数据，或者减少维数。举个例子：将北京、上海、广州等三个省市的机票出票量进行汇总来查看北上广一线城市的出票情况。 而向下钻取则相反，从汇总数据深入到细节数据进行观察或增加新的维度。举个例子：将2016第一季度的出票量进行下钻，查看具体1月、2月、3月三个月的每月的出票量。 切片和切块：在一部分维上选定值后，关心度量数据在剩余维上的分布。如果剩余的维只有两个，则是切片，如果有三个或以上，则是切块。 切片是选定特定的值进行分析，在立方体（Cube）上的感觉就是选定一个维度后进行的平面切分，就像是一刀切。举个例子：只选择机票这个票种的销售数据，或者2016第一季度的数据。 切块是选择维度中特定区间的数据，或者某批特定值进行分析，在立方体（Cube）上的感觉就是挥几刀切出一块。举个例子：2016第一季度到2016第二季度的销售数据。 旋转：变换维的方向，即在表格中重新安排维的放置(如行列互换)。举个例子：图一数据方（Cube）中季度维度和城市维度的旋转互换。   04 如何构建多维数据模型   在实现数据方（Cube）的过程中，由于业务灵活多变，导致了构建的业务模型随之经常发生变化，而业务维度和量度一旦发生变化，研发人员需要把整个Cube（多维立方体）重新定义并生成，数据人员只能在此Cube上进行多维分析，这样就限制数据人员快速改变问题分析的角度，从而使数据分析平台成为死板的日常报表系统。   为了避免这一情况，数据人员在前期过程中，就需要理解数据并且构建出符合业务的多维数据模型，包括： 源数据如何拆分到不同字段中？ 例如如何把季度拆分到日期的格式，日期date拆分成yyyy-MM-dd这样的字段格式进行存储。 哪些字段用于维度？ 例如季度、城市、票种等都可以作为维度字段。 哪些字段用于统计指标？ 例如出票量、销售额这些都可以作为指标进行分析统计使用。 使用什么样的规则来对数据进行聚合？ 例如是进行简单的汇总，还是要进行一般的加减乘除，又或者更复杂的规则进行聚合。 用户经常使用的组合查询是？ 例如经常把季度和城市进行组合查询汇总，这些都需要提前考虑清楚。 排序规则？ 例如经常会按照出票量和时间等进行排序。   05 写在最后   掌握以上几点以后，你会发现一旦多维数据模型建成后，OLAP联机分析并没有想象的那么复杂。大数据分析架构在这个巨大Cube的支持下，直接把维度和度量的生成交给咱们数据人 ，由数据人自己定义好维度和度量之后，Hadoop会将业务的维度和度量直接翻译成MapReduce运行，并最终生成业务报表。  

作者介绍 @杭州阿坤 母婴电商行业数据分析师兼数据产品经理； 致力于研究电商行业的数据驱动增长， 以及数据产品从0到1的搭建； “数据人创作者联盟”成员，“最佳创作奖”获得者。   01 电商归因目的 对于电商平台来说，当流量进入时，我们需要引导其完成购买任务，以实现流量价值最大化，在互联网红利消耗殆尽之时，流量会越来越贵，我们需要精细化运营每一份流量。   我们在做各种banner活动、Feed流推荐优化、活动页等进行效果评估，无法知道该位置最终产生了多少收益，也就很难针对该位置进行有效的改进。   如果进行单因数AB测试进行改版的效果评估，那也会存在如下2个问题： 单因素变量控制并不容易做到完全可控，如果产品处在增长期，产品增长本身就是一个影响因子，很容易忽略此类因素的影响。 评估方式低效，如果 2 天内只控制 1 个坑位变动，那么评估 20 个坑位内容改变就需要 40 天时间，这样的效率任何企业都无法接受。   因此，我们希望用数据分析中归因的方式解决坑位运营中评估的问题。   我们引入电商坑位归因的概念，把每一笔的成交都归给转化路径中不同的坑位。根据坑位的曝光转化价值来评判坑位的好与坏。把宝贵的流量尽可能都引导到转化率更高的坑位，以此达到精细化运营的效果。当然有了这个坑位价值评判的机制后各个坑位的改版也能准确的评估，真正做到了数据驱动增长。   02 归因类型简介 首次触点模型：多个「待归因事件」对同一个「目标转化事件」作出贡献时，认为第一个「待归因事件」功劳为 100%。 末次触点归因： 多个「待归因事件」对同一个「目标转化事件」作出贡献时，认为最后一个「待归因事件」功劳为 100%。 线性归因： 多个「待归因事件」对同一个「目标转化事件」作出贡献时，认为每个「待归因事件」平均分配此次功劳。 位置归因： 多个「待归因事件」对同一个「目标转化事件」作出贡献时，认为第一个和最后一个「待归因事件」各占 40% 功劳，其余「待归因事件」平分剩余的 20% 功劳。 时间衰减归因：多个「待归因事件」对同一个「目标转化事件」作出贡献时，认为越靠近「目标转化事件」做出的贡献越大。   对于电商平台来说，末次触点归因是比较适合电商站内销售归因的。虽然用末次触点归因实现方案上比简单，但是直接将价值100%归因给购买或者转化之前最后一次接触的渠道，而完全不考虑整个过程中消费者到底接触过多少个触点。转化之前发生了太多的事情，该模型完全忽视了漏斗上层和中层部分的行为对转化的影响。   因此我们公司融合首次触点归因和末次触点归因，计算用户进入一级流量入口后再到完成的完整购物链接行为。一级流量流入的定义为：各个入口之间无法进行跳转，只能通过切换tab进行跳转或者返回初始位置后重新点击进入。这样我们就可以基于购物的完整链接的最外层进行销售归因，并且也能知道用户购物的完整路径，同时保证销售归因后各个入口坑位的销售额之和等于当日的销售额。   使用这种融合归因方式，也可能知道中间步骤的转化率。比如活动会场页和商品详情页的相关推荐，虽然对电商平台整体进行销售归因时，不会计算活动会场页各个模型的销售，也不会计算商品详情页的相关推荐。   但是由于我们记录了用户进入一级流量入口后的详细路径，因此我们单独研究活动会场页和商品详情页的效率时，也是可以计算得到各个模块的销售来进行对比分析。但是切记不能和一级流量入口的销售混合在一起看，这样会导致销售归因发生重复。 用户购物路径模拟图   03 电商归因实现方案 对于电商归因我们进行了三个方面的归因，包括：曝光归因、点击归因、销售归因。即归因出所有的商品曝光来自哪里，所有的商品点击来自哪里，所有的销售来自哪里。这样就可以追踪各个流量入口的曝光链路归因指标。比如各个流量入口的商品曝光点击率、商品点击支付率、商品曝光价值等等核心监控指标来评价各个流量入口的效率。   电商归因准确的前提是埋点日志的完整性，因为我们是通过需要归因的事件往前找到用户的购买路径，这样的好出是大大减少计算量，也基本解决的归因的问题。因此用户行为日志的完整记录才能真实还原用户的购买路径，否则就可能导致归因出错，最终造成错误的评价数据。   首先需要在埋点体系中引入PageId的概念，PageId的作用是每当用户产生一次跳转行为进入一个新页面时，为这个页面赋予一个新的PageId；而当用户点击返回时，不会产生新的PageId。PageId是越靠近的当前时间的页面浏览的行为越大，且不会重复，类似于自增ID的实现逻辑。PageId的实现当然是写入埋点SDK当中，这样保证所有的埋点事件都带上PageId，并且也无需开发同步每次单独写逻辑。   然后根据埋点日志去还原用户的行为路径，全程都可以仅仅使用SQL逻辑就能计算完成。 首先要确定所有要归因的end事件（末端事件），包括商品曝光、商品点击、商品加购成功（加购后可以通过server的订单表判断用户是否完成了付款，也达到了销售的归因目的）。 然后在确定所有归因head事件（首端事件），即之前就定义的好的各个一级流量入口。 我们平台比较特殊，是工具类App同时拥有电商业务，这样一级流量入口会比较多，但是可以枚举完成的，不仅仅包括常规电商App的流量入口，还可以在各个工具页面嵌入电商入口，这样复杂性要强于一般的电商App。 我们的埋点日志都会记录用户发生各个行为的本地时间，用end事件时间去找最接近的这个时间的head事件，直接用SQL的left jon关联日志表就能完成计算。 这样在首尾2段时间内的所有埋点日志行为就是我们需要日志。 然后筛选出这些日志中的所有点击事件，过滤掉其他无效事件。 再对所有剩下的日志进行排序，按照本地时间排序，这样就得到了一条完整的用户有效行为的路径记录。 对于这部分数据我们就可以进行存储使用了，这部分数据为归因后用户完整链路记录数据。 再基于PageId过滤掉同个页面相同PageId的事件，保留本地时间最晚的那一条事件记录。 这样就得到了用户进入一级流量入口后真正进行末端事件的有效路劲。 这部分数据也需要存储记录，并且这个部分真正归因完成的用户行为路径，此时的得到各个一级流量入口就行归因得到此末端事件的来源。 通过这样计算后就了解各个一级流量入口的商品曝光点击情况，也能知道销售情况。 利用这些数据就能衡量各个流量入口的效率情况，也同样也可以中间承载页面的效率如何。 就能帮助产品运营更好的改善各个功能以及迭代各式各样的活动。 用户进行一次加购的路径还原   通过上述方法的计算，我们最终得到的用户加过链路步骤为：【1，2，9，10，11】，并且入口事件【1】就此次加购事件的归因来源。   另外再来举个商品详情页相关推荐的例子，下图所示的用户行为最终得到的链路步骤为：【1，2，9，10，11，12】，由于我们是完整保留用户的路径，因此我也只能这次加购事件不仅来源于1，也有一部分功能功能来于11，也就是商品详情页的推荐，因此我们也能计算出商品详情页的推荐效率如何，后续算法团队迭代模型时也能根据这个数据来衡量优化的好与坏。   商品详情页之间的横跳类型用户路径   04 总结 通过以上方案得到电商归因模型数据，可以大大提高运营同学的运营效率，不再是盲人过河实的凭感觉去优化各个坑位和活动，已经可以通过数据清晰公平的判断运营每一次迭代的结果。   但是仅仅根据坑位归因决定坑位价值，容易出现短期偏见，即追求短期利益，比如在一款内容产品中镶嵌一些游戏元素，可以让用户停留更久、数据表现更好。但从长期来看，这种行为破坏了整个产品的价值定位，因为内容产品原本提供的是内容并不是游戏，产品也不并是为了追求用户停留时长而是为了实现价值。这是两者都存在的短期偏见。   因此不能仅仅根据坑位归因后的销售转化价值来评价坑位，还需要综合考虑产品价值定位、战略发展等因素，才能围绕长期目标进行健康发展。