上一篇文章讲了《数据中台实战（六）：交易分析》，本文讲数据中台实战（七）：流量分析。
流量分析的核心就是你的平台每天有多少个用户过来，都去了哪里，在那个位置产生了消费。
针对这几个问题，我们做了几个功能：
- 网页分析，可以监测每个网页的流量PV、UV、浏览时长、跳出率；
- 坑位流量分析，可以看到产品的每个坑位每天产生多少流量，产生多少交易额；
- 路径分析，可以看到用户来了平台的路径是怎样的，从那里进来，走到哪里就走了。
这些功能都是通用的，几乎每个互联网产品都会用到。
只要前端产品做相应的埋点，就可以自动化输出数据，支撑N条产品线的流量分析。
一、网页分析
先讲一下网页分析，第一步要做的就是和产品线的产品经理沟通现在有那些网页，网页的地址是什么，网页名称是什么，网页有没有在数据库中管理起来。
比较不幸的是，我们的网页是没有管理起来的，我让产品线的产品经理输出了一份现有产品所有的网页名称和地址。
由于没有管理起来，我们只好将这份表格导入数据库，并给网页的英文名称定义中文名称，目的就是更方便运营能理解数据。电商产品的主要网页有这么几个：
- 推广落地页，投sem广告用到的页面，一般都是注册页；
- 首页，一般来说用户进入产品的第一个页面；
- 商品列表页，从首页坑位、搜索、分类等进入查看商品的页面，一般是多个商品；
- 商品详情页，单个商品的介绍页面；
- 进货车页，用户商品加购后的页面；
- 下单页，用户提交订单的页面；
- 支付页，用户选择支付方式的页面；
- 个人中心页，用户编辑资料，领优惠券等功能的集合。
其中有两个核心的页面需要讲一下，一个是推广页，一个是商品详情页。
推广页一般都是付费推广，推广页每天访问人数、点击次数、每一步的转化率直接影响到我们的投放ROI。
推广页的流量一般都很大，做投放的同事需要每天监测PV、UV这两个指标，如果发现暴增或者暴跌的情况，就要及时查明原因及时解决，所以我们给出趋势图。对
于访问时长来说一般是越少越好，我们希望用户能够尽快注册进入产品，而不是一直停留在推广页；如果一直停留在推广页说明吸引用户的是我们的推广页，而不是我们的产品，访问时长也是一个监控产品功能的比较好的指标。
我们第一次投广告时就发现一个问题，对比整个产品的平均访问时长来说，推广页的访问时长多了好几倍，经过查看明细数据，发现有一部分用户一直访问推广页，而且是同时发送多个访问请求。
我们当时就用一个未注册用户访问推广页，发现用户访问完推广页会填一些问
上一篇文章讲到《数据中台实战（五）：自助分析平台》，本篇文章讲一下交易分析模块。
交易分析设计原则
交易数据是一个公司最核心的数据，领导层会十分关注，一线的运营的kpi也是围绕交易额展开。领导层和一线的运营还是有些不同，公司领导层关注的是大盘，是不会看一些明细数据，而运营需要大量的明细数据来分析数据上升或者下降的原因。
所以给领导层看的功能都是计算好的看板，给运营看的数据的是可以各种维度拆解的数据，所以交易分析模块针对领导层和运营要分开设计。
给领导层看的交易分析数据
我们先看下领导层关注的指标有哪些。需要对公司的领导层做一个调研，ceo的视角和每条业务线老大的视角还是有些不同。
针对领导层的交易指标还是要围绕着公司的全年计划来定义，作为高层他们是公司全局的视野，需要一眼能看到公司全年的交易额、收入、每日的交易额、每日的收入。其次就是公司总用户数，每日新增用户数。还有就是每条产品线都有交易额、收入的kpi，可以针对总的交易额做一个拆解，每条线的交易额、收入、完成率。这些指标的口径要向公司高层确定好，然后邮件同步确认，因为交易的数据是每条业务线很敏感的数据，口径必须一致。
1. 交易指标的口径
我们也约了公司的几个领导层共同确定了一下，基本确定领导层关注的数据指标，主要分为三块：交易额、收入、用户数。
交易额没什么歧义，口径比较清晰，就是按下单金额（用户看到的包含优惠的原价）、下单时间来统计。为了防止刷单，我们又加了一个规则，所有未支付、已取消的单不算进交易额，这个也和领导层、各个产品线的负责人做的一个进一步的确认。
公司总用户数是以手机号为唯一ID，业务中台总体中心有多少手机号，公司就有多少用户数，这个十分明确。各个产品线的用户数就有一些小问题，因为我们的用户都在用户中心，用户只有一个平台标识，注册了产品线A的用户平台标识就是产品线A，不可能是产品线B。所以我们和产品线的运营同事定了一个规则，比如产品线A的用户的定义是，平台标识为产品线A或者注册了产品线A又登陆产品线B的用户。
关于收入这个指标，数据中台统一取订单中的佣金来计算，这就要求各个业务线都要接入中台的交易中心，提交订单时，已经把佣金算好记录到订单中。和业务中台的产品经理沟通后，除了某些产品线会有一些线下订单，这些是没有直接进入业务中台的，他们的运营会每隔一段时间补录进入系统，这样会会导致交易数据的显示没那么及时，其他产品线交易
上一次说到《数据中台实战（二）：基于阿里OneData的数据指标管理体系》，这次我们谈下产品经理更加关注的模块产品设计。接下来的文章将从六个方面讲数据中台的产品设计包括用户分析、商品分析、活动分析、流量分析、还有自助分析平台、标签平台、推荐系统的搭建。全部基于实战，读完这个系列，你就可以搭建属于你们公司的数据中台。
还是要先讲一下背景：笔者所在公司为XX环球商品贸易港，是集团旗下汇聚原创设计师品牌及时尚买手/采购商两大社群，通过B2B电商、RFSHOWROOM、富贸通等子品牌为时尚行业提供一站式产业＋渠道服务的平台。公司还在广州市、西安市有线下的综合实体商贸中心，涉及到的系统有CRM、ERP、Marketing等各种各样的系统，公司涉及的n条产品线。
如果每条产品线都有专门的运营、产品、研发团队，一方面需要耗费大量的人力资源，另外一方面公司的数据散落在每条产品线，再收集起来就会造成很大的挑战。数据中台的存在就是为了解决这些问题，公司内每个系统的数据都流入数据中台（数据中心），这样数据就会更加规范的存储与组织。
另外只需要一个团队就能支撑起整个公司的数据相关的需求，这是数据中台的优点。但是从这里你也能看出来，由于追求通用性，无论业务中台还是数据中台都是缺乏灵活性的，数据中台的模式是比较重的，这就要求前期公司数据的调研工作一定要做的足够细致，才能避免以后反复改造的问题。
在这里也给大家一个判断公司是否引入数据中台的依据：如果你的公司有多条业务线用到了多个系统，需要通过数据整合来驱动业务，那么你们就合适引入数据中台。如果公司公司只有一条业务线或者初创公司，这种你们还是重点关注你们的业务和价值探索，因为数据中台是需要大量的资源支撑的。接下来我们先讲最核心的用户分析。
一、用户分析
刚才提到中台产品的设计讲究通用性，那用户模块我们也需要选择一个比较通用的模型来设计功能，尽量使设计出来的功能能适用大部分的产品线。
用户模块的功能设计我们参考黑客增长AAARR这个模型，从用户的获取、激活、留存、转化（收入）、传播（推荐）五个方面来设计功能。这个模型是比较抽象通用，适用于每个互联网产品，因为每个用户的生命周期都会经过几个过程。
1. 第一层：用户的拉新
先讲一个坑，拉新的工作每条产品线都会有对应的人员去做，如果每条产品线都有一套自己的标准，需要针对每条产品线的拉新统计单独做一套功能，那么会对统计造成
商品的生命周期分为售前、售中、售后，接下来结合数据中台实战，分别从三个时期的细节方面分析下，如何保证我们提供的都是真正的好货。
上一讲讲了用户模块《数据中台实战（三）：用户分析（产品设计篇）》我们用的是海盗模型，从用户的获取、激活、留存、收入、推荐的角度来做分析。这些指标是没问题，但是作为电商产品，如果站在价值的角度来思考就有问题。
你可以分析下我们提到的用户相关的指标，比如：注册量、访问时长、留存率等这些指标都无法提高产品的价值，指标中最重要的是留存率，你发现站在价值的角度留存率也只能监控产品的价值，但是并不能提高产品的价值。
对于B2B电商产品来讲，产品的价值就是要给我们的采购商提供好货，所以商品才是最核心的地方。我们的用户直接接触的是我们的商品，商品能直接传递公司的价值。没有好的商品就不用提用户、产品、流量等其他方面的运营，这些都是手段，这些手段在我们提供好的商品基础上才会事半功倍。
我们先看下商品的整个生命周期，第一步是招商的工作人员负责吸引供应商入驻，如果有一套对供应商的严格筛选标准， 能直接决定商品的档次、品质和货源的稳定性等因素。
第二步是商品的选择，我们要从供应商的货中挑出最好的货给我们的用户，包括商品的款式、质量、性价比等指标。细节的地方我们会涉及到商品的图片及文案，每个细节对商品的转化率都有比较大的影响，因为用户是否下单是有很多因素的，我们把可控的因素做到最好，那就可以比较好的提高转化率。
接下来是商品的销售环节，我们怎么通过数据挑出好卖的货给到我们的用户的呢？
商品卖出去后我们的售后怎么样、我们的发货速度怎么样，也是直接影响用户的体验，可以说商品的每个环节都直接决定我们产品给用户的价值。
怎么保证我们的商品都是爆款、好货呢？
商品的生命周期分为售前、售中、售后，接下来结合数据中台实战，分别从三个时期的细节方面分析下，如何保证我们提供的都是真正的好货。
一、售前
1. 关于供应商的选择
我们有一套严格的准入机制。为保证效率，我们要求供应商适应“快反应”的柔性供应链模式，并建立了供应商分级动态管理系统，包括供应商准入机制、供应商绩效评估和激励机制、供应商分级认证机制、供应商升降级调整机制。从供应商的选择、分级、合作模式、绩效测评、订单激励和退出等方面进行严格的动态管理。
在供应商准入方面，由招商小组、相关业务部门、品控管理小组到生产供应商进行实地访厂和现场打分，重点评估厂家
本文将通过具体案例来介绍OneData的实施流程，继而介绍阿里OneData数据体系中数据指标的管理和数据模型的设计，最后再为大家讲数据看板的设计。
上一篇文章讲了《数据中台实战（一）：以B2B点电商为例谈谈产品经理下的数据埋点》，本文我们先以一个例子实战介绍OneData实施流程。接着再讲阿里OneData数据体系中数据指标的管理、数据模型的设计。最后讲一下数据产品中，数据看板的设计。全是实战干货，看完本文你就会知道数据中台最核心的内容。
阿里OneData实施过程实战
比如当时我们运营提了一个比较有指导意义的数据指标叫爆款率，我们以爆款率为例先说一下OneData每个步骤实施的流程和涉及的角色。
第一步：要确定指标的业务口径
业务口径应该由数据中台的产品经理主导，找到提出该指标的运营负责人沟通。首先要问清楚指标是怎么定义的，比如运营说爆款率的定义分子是是专场中商品销售件数超过20件的商品数，分母是专场内的总商品数（专场如上图所示，商品会放在运营人员组的一个一个专场里面）。
这里面有几个坑：
1. 这个20件可能是运营拍脑袋定义的数据，这时要协调我们的数据数据分析师看下历史专场销售件数的分布找出最合理的值，然后和运营基于数据再一起定义最终的阈值。如果历史数据专场销售件数大部分都远远超过20件那么这个指标就所有的专场都是爆款专场，就没什么意义了。
2. 商品的销售件数超过20件，其中有一个十分有争议的字眼那就是销售，怎么定义销售？是下单就算，还是支付才算？考虑不考虑退款？如果考虑退款是发起退款就算还是退款实际发生后再算？其实是有很多问题要考虑的。最终和运营确定为该专场支付后的商品件数除以专场商品的总件数。
3. 销售的商品件数是按商品销售的件数还是按照商品下SKU的销售件数，这个是要搞清楚的，可能运营不关心这个事，但是影响到模型的设计。
处理完这些坑后关于指标的定义还需要问这几个问题。我们统计的维度是什么？比如爆款率的计算维度是专场内商品的维度，一个是要专场内，一个是商品，原子指标就是销售款数。还有就是统计周期，一般统计周期分为按小时、按天（当天）、按业务周（运营自己定义的统计周期）、按自然周周、按自然月月、按年，还有就是截止到昨天也是比较常用。爆款率的统计周期是统计专场开始到结束时间内的销售件数。
接下来要问清楚这个指标有什么用，给谁用。
不是所有的指标都有开发的意义，因为后面你会发现我
本文以B2B电商产品“亿订”为实例，与大家一同谈谈数据中台的数据埋点。
笔者所在公司为富力环球商品贸易港，是富力集团旗下汇聚原创设计师品牌及时尚买手/采购商两大社群，通过亿订B2B电商、RFSHOWROOM、环贸快版、环贸映像、富运通、富贸通等子品牌为时尚行业提供一站式产业＋渠道服务的平台。
笔者所在部门为数据中台，职责就是为公司搭建数据中台，支撑各产品线数据化运营，通过数据中台打通各条产品线的数据，更精准的为产业的上下游客户服务。本文以B2B电商产品亿订为实战，谈数据中台的数据埋点。
图片来源：富力环球商品贸易港公众号
刚入公司时，公司的数据埋点这块是和百度合作，用的百度移动统计。
运营反馈百度的流量分析做的很强大，但是最大的问题是不能结合电商的业务数据，比如：只有坑位的流量数据却拿不到坑位的交易额、转化率（交易额/PV）这些数据，另外电商的主路径 访问>商品详情>商品列表>加购>下单>支付整个流程的转化率是取不到的。
此时，就拉上我们的开发，叫上了亿订产品经理和运营负责人，一起沟通目前的问题。
图片来源：百度移动统计， 百度的移动分析看不到任何业务数据。
沟通后确定主要确定解决以下问题：
问题一：要知道亿订B2B电商产品每天的主路径 访问用户数>商品列表页>商品详情页>加购>下单>支付主路径每天的人数及每个步骤之间的转化率。目的是长期监测每步的转化率如果有明显异常，运营同事会进一步分析转化率低的原因。
图片来源：亿订电商， 从左到右以此为：首页、商品列表、商品详情、加购、结算页
问题二：因为问题一只能解决总体转化率，要想定位到底是那里的转化率低导致整体转化率低的原因，还得看用户每个入口路径各环节的转化率。
问题三：要解决坑位的转化率问题，因为评价坑位好坏的因素不止有PV/UV百度统计的两个指标，运营同事定义了坑位的转化率为（pv/坑位交易额）来综合判定坑位的性价比，如果坑位的放在很明显的位置，那他的转化率还是很低，那就要分析原因，改变运营策略。比如图片的调整、商品的调整、位置的调整等。
问题四：要打通用户的行为数据和用户的交易数据，用户运营的同事需要更加了解他们的用户比如什么时候访问，访问了那些商品、什么时候加购，加购了那些商品，什么时候买了那些商品。这些百度是做不到的。通过用户的 访问行为，运营同事会进行针对性的运营型。
问题五：要看到用户的留存情况，留存的定义分为两种，第一种是访问留存
在我的上一篇文章中，我已经为大家用一个做菜的例子通俗的介绍了什么是中台？如果大家还不清楚中台是什么，可以先看我的这篇文章《最近处处惹人爱的中台到底是什么》。本篇开始我将以系列更新的形式分多个专题来为大家详细剖析中台要怎么做？
要进行中台的建设，我们首先要意识到中台的建设与传统的业务线维护是不同的，这两者之间最大的区别就是：中台建设是一个根据企业业务方向变化而动态发展的过程。
所以要想建设好中台，我们就要学会调研与预判业务，本文以一个事业线负责人的视角，带大家来看看很多看起来毫无章法的公司业务发展路径，背后是根据什么因素不断演化的。
一、业务正常迭代流程
我们先以电商事业线为例，看看如何单一事业线如何是如何演化的。
首先在整个电商系统上线初期，由于业务量不大整个电商后台我们通常是融合在一起开发的，也就是一个后台里面集合了订单中心、商品中心、会员中心等，这些中心只是后台系统的一个独立模块。
我们就以商品中心来看，在随着业务量的增长，电商公司为了更高效的去进行商品管理会将一个商品模块开始独立并扩充变为一个独立的商品中心，让商品运营团队不再在原后台里操作。
此时我们的第一步先将商品模块独立出来成为一个全公司的商品中心的子系统。在随着发展我们发现将所有的商品操作都由一个商品中心进行维护支撑是非常费劲的，例如商品管理中的商品信息管理与进出库管理，这是两个完全不同的业务。在商品数量种类急剧上升的时候，以往我们可能是一个业务团队来管理的商品信息与库存，在此时就无法放在同一个模块中维护。
所以我们就需要将库存模块从商品中心中独立出来，单独成为一个库存中心事业线。接着我们在发现价格模块在商品中心中由于商品数量的增加与电商的营销方式增多，价格管理机制也需要单独完善。我们发现此时的价格管理系统也需要单独维护，因此价格系统也需要拆分为价格管理与价格走势管理。因此整个产品迭代发展的路径如下图所示。
图：电商后台系统演化
我们可以看到由商品中心我们演化出了三个独立的中心，商品中心、价格系统与库存中心。
二、企业战略演进
除了事业线的演化，下一步我们要学会掌握公司业务多元化发展历程。相比大家应该经常会在很多产品场合听到——从0到1这一词，那么从0到1到底是个什么过程？负责人又是如何定义企业发展战略的。
让我们以一家虚拟公司：A影视票务公司的业务多元化发展历程，看一个企业如何在发展中去不断根据行业发展情况，去动态调整自己的业
在当下互联网圈子里要问什么最火莫过于中台这一概念了，各大公司都开始了一轮跑马圈地似的中台建设，那么到底中台是什么呢？本文我们就来谈谈这个话题。
一、什么是前台，后台
在以往的互联网企业生产流程中，我们可以将研发团队宏观的划分为前台与后台两部分。
所谓前台就是用户直接接触到的产品部分，如可在应用商店下载的APP，像微信、抖音、淘宝，或者可以使用的网站等。
用户对产品的认知与体验也由此而生。比如大家对于微信的理解就是这个前台APP展示的一切给大家描绘的：一个绿色图标的应用，里面有我的A、B、C好友。
而后台包含两个部分：
- 企业的内部管理服务的统称，如：内部的CRM，ERP等；
- 为前台提供服务能力的，如：数据压缩能力，并发等。
后台最重要的特点就是其提供的服务都是不被普通用户所感知的，就像用户不会因为应用的并发，传输速度而记住微信这个品牌。
在搞清楚了前台与后台的概念后，前后台模式的产品服务模式我们就可以用一张图来概括描述：
图1
总的来说就是在应用中后台提供能力与计算，前台将后台的能力进行封装以图形化的形式展示给用户，让用户能更容易的使用公司提供的服务来解决个人需求。
二、中台的白话解释
在开始谈论中台之前，我们先要明白：当下的主流前后台模式并不是在业务实现上出现了问题，不支持眼下出现的种种新业务场景；相反地，这种前后台反而是公司最省事省力的一种提供服务的解决方案。因为这种模式不需要提供额外的建设，前台完成信息展示与交互，后台做好对应需求的解决逻辑就组成了一个产品。
实际上，中台的出现更多是因为公司业务在发展到某一阶段时，在拥有多个业务线时继续发展遇到瓶颈与障碍后，为了解决如何继续朝下走的实际问题而提出的一个组织前台业与后台关系新解决方案的统称，而不是某个新的系统。
在互联网进入日益复杂的市场环境的今天，市场中由于存在众多的竞争者，也逼迫着企业需要不断去更新产品去抢夺市场。
而作为实际用户真正接触的前台业务，如：APP、小程序、网站等，必须要快速迭代新的功能才能让用户感知到。
而在这个大背景下带来的矛盾就是——以往为了支撑前台越来越多的业务，后台不断地建设庞大起来的系统，由于一直在追求稳定性而生，反而在这个时候显得越发笨重起来。这样的后台变得越来越没法去快速响应前端变化所带来的改变。原来的前后台模式的这种直接关联决定了两者的冲突不可避免。
例如：传统我们的一个电商网站，由于用户前端需要组织各种新的销售方式
在前面两个篇章我们已经普及了中台的基础概念与企业业务动态演化的历程，接下来本篇我们就来聊聊各类中台设计的根本性原则是什么？
一、企业设计中台时在想什么？
回顾2019年可以说是中台概念进入规模化建设的元年，这一年中各大中小企业都开始了自己的建设。
但是正如任何概念兴起后一样，市场上开始有了很多反对的声音，认为现在中小企业去建设中台完全是属于跟风建设，纯属因为看到阿里等巨头开始中台建设自己也想去追一下热点。
但是事实真的是这样吗？实际上各大中小企业之所以会去选择中台建设的一个本质原因是因为当下的互联网已经进入了一个竞争非常残酷的“市场渠道主导”阶段。
也就是说在这个阶段大家基本上没有什么核心竞争壁垒，A公司可以做一个抖音，B公司可以做一个飞音，单纯的技术实现已经不再是制约产品能否被市场接受的关键性问题了。而大家比拼的是谁能找到更好的流量渠道，可以说整个市场已经和传统线下的经销商分销体系一样了，就是在比拼企业的铺货渠道（APP传播渠道）。
进入这种典型的市场时代，各大企业想要生存下去的关键就是能否去提升公司内部运营效率与降低运营成本开支。
从管理学上来说一个公司的成本可以分为固定成本与变动成本两个部分，在互联网公司中固定成本很大一部分其实就是员工工资。
可以给大家算笔账，一个工资1万块的员工，企业最终的支付成本要在1万6左右（因为要加上企业交五险一金等），那么假设一个100名员工的企业，一个月他什么都不干就要付出160万的固定成本。
因此大家可以看到为什么临近年关会出现这么多裁员信息，因为企业必须要进行开支压缩，为自己的主营业务预留足够的现金流。
但是减少研发人员对于互联网企业来说必然会导致项目的研发进度下降，那么有没有什么办法能既减少开发人员的同时又能让项目保持原来的开发效率不变呢？
正是因为这样的需求出现，这个时候主打解决两类问题：企业内部复用率与统一整个公司的设计体验的中台方案，就一下成为了企业主大肆追捧的原因。
这里给大家拓展一下我们互联网产业发展的三个关键转折点。
图：互联网产业的三次关键转折点
这三次发展转变是互联网整个产业发展的关键转折点：
第一阶段：早期互联网的补贴型模式，企业给用户钱让用户来使用产品，目的就是快速拓展业务市场占有率；第二阶段：当第一批股权基金到了兑付期，发现大量互联网项目都是失败的，出资人都是亏钱，所以投行不再那么容易拿到钱，互联网创业公司也不再那么容易拿到融资，此
很多互联网人都了解DAU、MAU的重要性，但是具体的数据指标划分你知道吗？对数据基本功的扎实了解，是沟通的桥梁，本文作者对常见的数据指标进行了分析，希望通过此文能够加深你对基础数据指标的认识。
现如今，我们见证了太多的江湖奇迹，无论是拼多多的三年上市，抑或是瑞幸咖啡的异军突出，这些奇迹坚定了众多中小门派追梦之路，当然，人们也渴望获得奇迹增长的力量，《用户增长》这本武林“秘籍”似成了关键，仿佛一旦得到，便可“号令天下，谁敢不从”。
诚然，在以用户为中心的互联网行业里，有了更多的用户，便如同拥有了屠龙刀一样，无往不利。但是，神器虽锋，但也要修好基本的内功，不然可就成了：一方霸主尚未成，走火入魔断了魂。
说到基本内功，离不开对数据最基本的理解，说到数据指标，也许您可能呵呵一笑，不就是DAU，MAU，UV，PV吗？这有什么好讲的。可是如果我问您一下，日活跃用户中的日，活跃，用户分别是以什么划分的？可能您就有些含糊不清了，也许您觉得这没什么重要的，知道不知道都一样。
这里，宋老湿先卖个关子：
对数据基本功的扎实了解，是沟通的桥梁！等到文末，大家自然就明白我这句话意思了。接下来全程干货，请做好湿了的准备。
数据的一句话秘诀
数据作为互联网产品发展方向的核心驱动力之一，必须是基于业务，离开业务的数据毫无价值。无论哪种互联网细分行业的业务都是基于解决“用户在某种场景下，产生的某种需求”。
在解决的需求过程中产生的数据，才是我们互联网人需要关注的，因为是有价值的。那么作服务方的我们就需要记录用户用了我们的什么服务，最终结果是什么。
这里呢，为了方便大家记忆，给大家一口秘诀：
谁？做了什么？结果怎样？
根据口诀，宋老湿对应的将数据分为三大类：
用户数据（谁）行为数据（做了什么）业务数据（结果怎么样）
01 用户数据
用户数据主要有：DAU，MAU，新增用户，留存率。
DAU、MAU
DAU：daily active user（日活跃用户）MAU：monthly active user（月活跃用户）。这里面我们分三步拆解：
1. Daily
一般我们指一个自然日，即0:00–24:00。特例：如果用户群体涉及海外产品，可根据具 体业务设置为最近24小时。
2. Monthly
当月至少活跃一次的用户总数。（即多次打开只记录为一次月活）。此处需要注意：月活不等于当月各日日活相加，需要进行去重。
这里方便大家理解：给大家提一个小问题