急忙推行产品商业模式，同时投入资源和成本在构建产品前端、客户端、后台。最后团队一定会花时间在数据平台上搭建。
我的产品到底商业模式行不行？产品有没有前景？这都是数据才能反映的客观条件和论证。
从0到1搭建一款APP、小程序、PC的数据平台到底需要多少种维度的数据统计？数据管理权限又应该在早期如何考虑?涉及到的模型有那些？
今天以自己带团队搭建的数据大盘案例，讲解从0到1互联网产品的数据版块设计。
相比数据中台，大数据系统更像是多个数据报表的集合。由于数据的搜索、查询页面较多，为此我截图部分页面汇总为如下内容。若看不清，可以进群找我拿取。
该板块涉及到产品数据的全体概览。也是内部管理者、产品经理、运营使用最频繁的面板。
依照活跃定义下，用户活跃数量。注意的是不同产品活跃定义不一样，比如资讯类产品，即打开APP。但电商类产品，用户产生订单才算活跃指标。不考虑独立用户和用户重复访问情况下，访问的累计和。增加日、周、月环比，同时允许用户查看自定义时间周期的用户访问周期。通过柱形图反应数据的走势规律。以日期为横坐标、增长数据为纵坐标。通过趋势报表主要是查看产品数据的规律。不要聚焦在数据的具体数额，反而关注在周期下产品功能数据、行为数据的变化规律。用户打开APP客户端、H5、PC端的次数，计算算重复。依照次日留存规律计算，计算累计7天的用户7天注册占比。每次停留APP、PC、H5时间长度，通过版本迭代来统计用户停留时长判断产品好坏。
用户生命周期是比较难以度量的。尤其是产品在探索期、增长期、稳定期、衰退期的用户周期不同。所以这个版块需要数据产品经理或产品经理花时间在数据模型上罗列设计，满足不同周期阶段用户的生命周期展示和统计。比如可以用柱形图的方式来表示用户周期时间长度。从发现产品到离开用户的整体时间有没有环比增长来验证新版本效果好坏。比如图中将新用户、连续活跃用户、回流用户、沉默用户、流失用户以时间段长度组成了柱形图的长度部分。用户访问产品后，没有产生付费、连续活跃，在流失期内。流失期不同产品定义不同，比如日打卡的用户超过90天不使用则算流失。金融理财类产品，超过720天没有投入产品则算流失。（金融理财产品一个周期在365天）用户在符合活跃定义下，连续使用产品，至少满足2次活跃指标以上。由于APP、h5等产品都有版本的记录。标记互联网产品的优化是否有成绩，版本数据统计十分重要。
以柱形图的方式，统计版本下安卓端、IOS端用户增长环比、用户总数。横向对比「整体概览」数据下的浮动趋势。统计出时间坐标轴下，版本的用户增长情况。观察用户的日启动次数、活跃关键指标，统计出环比。用户行为涉及下载量、点击量、用户登录次数。指标体系可以随着资源情况做更细化的指标。
为了降低开发成本，还可以允许用户查询时间，找出时间范围阶段的指标浮动规律。还可以去掉图形图展示，通过Excel导出自己建立分析模型，减少开发成本。
统计出产品不同端的登录次数，以列表的方式展现。点击量、登录次数同理。登录次数的记录方式可以用服务端（后台）记录，记录用户的反馈。
以上是本次大数据平台的产品从0到1搭建。你可以看到产品由于数属于后台类型的产品，因此数据产品经理、后台产品经理都会涉及到这类工作。唯一不同的是数据产品经理、数据运营会专注于数据的定义。数据的查看权限、后台产品的数据分类页面管理、后台的模块如何区分？在建立大数据盘的同时，数据指标首先是满足业务人员查询的。造成了大数据中心的产品经理、运营、数据分析师总有被业务牵着走“打杂的感觉”。只有当业务需求指标累计后，再重构大数据中心系统去完整的设计产品框架，才会有主动权。
产品框架化会更加容易标准化产品，同时利于未来迭代。也就是后面提到的数据中台的概念就是由此衍生出来的。我们就可以将大数据中心的报表以接口化的方式提供给内部或第三方外部。当某一个或某场景下的接口需求较多，就会建立开放平台做管理。以此来做数据中台的前期。
本次分享的大数据中心，是每个0到1互联网产品都会做的。唯一不同的是数据字段、统计逻辑规则有区别。
