App产品设计『数据篇』运营数据
这是《App产品设计指南》系列文章的第25篇内容，更多精彩可以点击下方链接查看。
《App产品设计指南》专栏目录
结束运营篇之后，接下来进入数据篇这个章节。我会和大家聊一聊常见的数据指标，主要是关于运营数据和业务数据这两块内容。本文会重点介绍一下运营类数据指标。
PC数据指标
这几个指标是对网站流量的统计，在移动端使用的是新增用户，活跃用户等指标，下面的内容会提到。
PV
PV是页面浏览量，用户在网页的一次访问请求可以看作一个PV。用户浏览多次，PV会一直增加。
UV
UV是独立访客数，在同一天不论用户访问多个页面，都只看做一个PV。技术上一般是通过cookie来判断用户唯一性，使用不同浏览器或者进入隐身模式访问页面都会被认为是新的UV。
IP
IP是独立IP数字，是指1天内使用不同IP地址的用户访问网站的数量。同一IP不管访问了几个页面，独立IP数均为1。在公司中一般是使用企业宽带，多个人上网办公，但对外统计的IP一直都是1。而在家庭中如果把光猫重启，IP就会变化，这样对外统计的IP就会自动增加。
VV
VV是访问次数，是指1天内使用不同IP地址的用户访问网站的数量。用户浏览网页最后关闭网页就视作一次访问。
假设我在家里使用家庭宽带，上午浏览了百度的2个页面，下午浏览了百度的3个页面。则当日的PV是5，UV是1，IP是1，VV是2。
用户获取
渠道曝光
渠道通过各种手段让应用展示给用户，比如应用商店，朋友圈广告，其他App开屏广告等等。这个和SEM的展现量比较类似，只有获得曝光和展示，才有可能获得下载，注册。
渠道转化率
1.CPM（Cost Per Mille），每千人成本。展现给一千人就收费一次，平台流量越大理论上优势就越大。
2.CPC（Cost Per Click），每用户点击成本。用户点击才会收费，不考虑曝光量。
3.CPA（Cost Per Action），每行动成本。是指用户按照完成一个指定的标准或者行为动作来进行收费的广告模式，比如注册，下载，交易都可以作为指标。
4.CPS（Cost Per Sale），每次成功交易收费，也就是按效果付费，一般平台不会考虑这种合作，因为效果很难保证。CPS可以看做是CPA的一种特例。
有两点需要说明，一个是无论选择哪种方式都很难百分百保证效果，只能是凭借经验，历史数据做出参考。另外一个是部分第三方渠道会针对数据造假，并没有带来真实的用户，对广告主是不利的。
获客成本
获取新用户是必然要支付成本的，无论是线上还是线下获客。目前线上获客的成本已经非常高，动辄上百。通过裂变活动，分销等手段在扣除一些成本后，往往比常规的获客方式的成本要低。所以现在的企业更加青睐通过这些营销手段来获客。
用户活跃
新增用户
首次安装App的用户数，以设备为判断标准。如果用户卸载App再次重装则不会再次统计。
活跃用户
在特定周期启动过App的用户，启动多次也只统计为一个活跃用户，包括新用户和老用户。
流失用户
有一段时间没有再打开产品，那么我们就视为流失用户，根据产品的属性，可以按30天，60天，90天等划分。
不活跃用户
有一段时间没有打开产品，为了和流失区分开来，需要选择无交集的时间范围。比如流失用户是60天以上没打开产品，那么不活跃则是0～60天没打开。
回流用户
有一段时间没用产品，之后突然回来再次使用，则称为回流用户。回流用户是活跃用户，且是由流失用户或不活跃用户唤回而来。
忠诚用户
也可以叫超级活跃用户，长期持续使用产品，比如连续四周，或者一个月内15天等。
启动次数
用户启动App的次数。打开应用视为启动，完全退出或退至后台一段时间即视为启动结束。
桑基图
平台的新增用户、活跃用户、回流用户是可以互相转化的。下面的桑基图能很好地反映这种趋势数据。
来自网络用户留存
留存率
用户留存可以被细分为新用户留存和活跃用户留存。某段时间内的新增用户（活跃用户），经过一段时间后，又继续使用应用的被认作是留存用户；这部分用户占当时新增用户（活跃用户）的比例即是留存率。
比如2020年2月14日的新用户数为200，在1天后，7天后，14天后，30天后这些用户启动过应用的数字分别是100，20，10，5，则2月14日新用户留存率分别是50%，10%，5%，2.5%。
流失率
流失率=1-留存率。流失率是相比于留存率的，通过留存率可以进一步分析用户的粘性、活跃度，预测产品的发展，还能计算用户生命周期。
用户生命周期
用户生命周期=1/流失率=1/（1-用户留存率），注意这是一种比较简单的计算方法，有些时候不一定准确。
例如，某产品新增?户的?留存率是60%，则?户?命周期=1个?/（1-60%）=2.5个月。
上面这些数据指标是运营过程中相对重要的指标，也是产品经理应该关注的。此外还有很多很多指标，在工作过程中根据场景灵活选择即可，不能迷信数据。希望本文能对大家有所帮助。
在写作过程中，如果有意见或者想法，欢迎有兴趣的读者添加我的微信一起交流探索，共同进步。
编辑导语：数据资产管理与治理是数据产品经理的四大方向之一。本篇文章作者为我们分享了数据资产模块到底在做哪些事情，以帮助有需要的小伙伴判断是不是可以去尝试的数据产品方向。
在数据产品经理从业指南相关文章中讲到，数据资产管理与治理是数据产品经理的四大方向之一。Q2开始了，近期在整理数据资产方向的产品工作规划，顺便分享一下，数据资产模块到底在做哪些事情，也方便大家在未来找工作的时候（今年铜三铁四的行情让很多人只能静待惊蛰了）判断是不是可以去尝试的数据产品方向。
一、用户是谁要解决什么问题?
B端产品经理工作方法论中，首要的一点就是搞清楚你的用户是谁，他的诉求是什么，有哪些影响他工作效率的点，可以通过产品化的方式去解决。
数据资产产品的用户分为两类，一是数据资产的生产者，二是资产的消费者。
1. 资产生产者工作内容及诉求
这里的生产者指的是数据开发者，虽然“我们不生产数据，我们只是数据的搬运工”，但是他们基于原始的rawdata经过加工处理之后，生成资产化的数据。
上图是很多数据开发者的“愉快”的一天，也有人调侃说他们干着“出力不讨好的脏活累活”，不出问题叫数据赋能，荣耀和光环都聚焦在应用产品端，出了问题就是“数据质量有问题”。“工欲善其事，必先利其器”，所以，作为数据资产产品经理，给他们提供趁手的工具，可以高效快速的干活，帮助他们把自己的资产管理和治理好，才是对他们的一丝丝安慰。
开发数据的时候，ODS层、DWD层、APP层，临时表，一堆的命名规范限制，记下来消耗CPU，记不住建模不规范事后被批还要整改。所以，能不能简单点，开发的方式简单点。睡得正稥的时候报警电话什么的最恶心了，所以，任务调度运维的报警策略，失败重试机制可以更AI一些么。即使非得人工处理，任务的一键通知、重跑能不能闭着眼睛就可以操作完接着睡觉了?负责很多的数据模型，业务经常来问数据在哪里，字段啥意思，可以不要来骚扰我吗。所以，我想让模型更多的被复用，但是最好自助去使用，我只想安静去coding。每次被老板指着鼻子说模型健康度差，哪个模型命名不规范，元数据缺失，任务耗时高，长时间没人访问。所以，可不可以提供个工作台，就像农民去田间看庄稼长啥样要不要除草，让我每天早上上班第一件事，把代办清单的治理事项提前完成，下次老板直接周会表扬，我们要向XX同学学习，开发习惯非常优雅。数据开发者除了自己不能删库跑路外，还需要对数据安全问题负责，所以需要流程化、自动化的权限授权和审批管理流程。2. 资产消费者的场景及诉求
指使用数据的业务产品、运营、分析以及二次加工的数据开发人员。作为数据消费者，就像你去实体店或者电商平台买东西，你希望能够：找得到，看得见，放心用（买）。也就是说，在资产仓库中，SKU覆盖全面，并且规格参数、用法用量（元数据）完备可见，帮助你决策是否是所需要的，除此之外，最好有一些客户好评推荐或者官方认证的童叟无欺的证明，这样才可以放心使用，不至于掉坑里。
资产消费者的主要诉求包括：
当我需要用数据，但是不知道数据在哪的时候，可以有工具引导我，从产品线，到数据分类可以逐步缩小范围，最终众里寻他千百度，啊原来你在这里。所以，需要有地图指引的能力。新入职工作交接，前辈告诉我需要的数据都在这个表里，但是求知欲比较强的我，希望搞清楚数据的来龙去脉，以便举一反三，而不是仅仅改个日期参数就查数据去了，所以需要便捷的数据检索能力。数据找到了，有没有相关的认证，证明今天数据没问题呢。虽然内心是拒绝骚扰数据开发者的，但是遇到逻辑不清楚，数据不确定的时候，还是想能够找到负责人，或者其他使用过这张表墙裂推荐的人，去交流交流。除了利用表进行SQL查询或者拖拽分析外，现在不都提中台吗，所以，还希望有可以直接可以输出的数据服务，比如指标API、标签服务，可以通过界面化的配置就生成了接口，DAAS嘛（数据接口即服务）。二、数据资产模块的产品体系规划设计
明确了用户及其诉求，接下来就是需要通过相应的数据产品来为其赋能助力了。两类用户可能会有重合的场景，比如数据开发者也会作为数据消费者去使用别人开发的数据，同样，业务人员也可以自己去申请建表。所以，在资产产品架构设计上，主要围绕数据的汇聚、加工处理、资产管理、数据治理、价值输出等环节进行覆盖。
1. 数据汇聚
主要解决异构数据源之间的数据传输问题，数据从业务数据库、产品端埋点采集或者其他第三方的API接口、FTP文件互传，需要提供简单通用的数据集成能力，方便把数据统一汇聚到中央数仓。
在产品功能设计时，不同的源、和目标之间所需要的参数配置是差异化的，逐个对接解决即可。另外，数据需要每天或者实时的进行同步消费，所以需要和调度系统结合，提供智能化自动化的资源调度和任务运维能力。
所以，很多数据产品是把数据集成作为一种数据开发任务类型，整合在数据开发套件产品之中。
2. 数据加工处理
在这个环节主要是基于业务对数据使用场景进行数据清洗和逻辑处理，包括离线数据开发和实时数据开发，相当于是数据的加工厂，基于同步过来的数据源进行加工，形成高可用的数据模型。开发套件比较大，可以独立成单独的产品模块。
同时，可以将模型建设规范融入到任务开发的校验流程中。多些事前校验，而不是仅仅依靠事后治理。例如提供dataphin之类的流程化建模或数据加工工具
3. 数据资产化管理
资产化管理：数据工厂加工好的数据，还需要进行分门别类的规整，贴上各种规格标签，才能给到下游消费者使用。资产化管理主要通过数据地图进行数据表查询检索，元数据信息维护查询，为使用者提供方便的数据指引能力。
数据血缘：是贯通数据从入湖到业务终端全流程的数据链路关系，一是可以方便排查数据生产过程的来龙去脉，为翻代码查逻辑提供指引。此外，基于血缘可以做到数据异常时的下游通知，以及下游应用无人使用时，数据一键治理，存储计算资源释放。
数据质量监控：针对任务执行的结果准确性进行监控，提前发现因为源端数据库变更、开发Bug等问题引发的数据不准等问题。
数据治理：从任务资源消耗、时间消耗、业务使用（冷热数据）、开发规范、模型覆盖度复用度等不同维度建立资产健康度评估指标体系，以及数据治理工作台，每天上班就可以知道有哪些坑要填，提前把自己埋了。
4. 数据价值输出
搞大数据最终是为了数据能够产生价值，一是基于数据的决策，二是数据驱动的产品智能化、运营精细化。
SQL即席查询是基于数据模型的SQL取数，自助分析则是通过傻瓜式拖拽方式服务于无SQL能力的业务人员。在这个环节和资产关系密切的就是指标管理、标签资产管理，通过数据API方式，最终将数据输出给到前端的可视化分析产品或者产品、运营主流程的接入应用。
5. 数据安全管理
数据库、数据表、指标及标签的元数据可以公开查阅，但真正要取数使用，必须先获取对应的授权，因此需要提供一键权限申请、审批消息通知、授权后应用自动赋权等全流程的自动化产品设计。
三、总结
数据资产是大数据的根基，前期业务发展追求短平快，留下的资产不规范不健全的坑未来还是要逐一去填平。数字化转型首先要解决的也是数据汇聚和数据资产等问题。
数据资产模块相关的产品经理，不仅要具备良好的产品通用能力，同时需要对大数据生态、数据流转流程、数仓建设等理论有良好的认知，这样做起产品才能更加游刃有余。但万变不离其宗，数据的采存管用流程涉及的数据产品模块，各家公司也都大同小异。
#专栏作家#
数据干饭人，微信号公众号：数据干饭人，人人都是产品经理专栏作家。专注数据中台产品领域，覆盖开发套件，数据资产与数据治理，BI与数据可视化，精准营销平台等数据产品。擅长大数据解决方案规划与产品方案设计。
本文原创发布于人人都是产品经理，未经作者许可，禁止转载。
题图来自 Unsplash，基于CC0协议。
下一篇：356的故事简短-
发表评论