在本文，作者描绘了一个理想的数据BI系统应该长成的样子。你是这样的么？enjoy~

在日常工作中，无论是to C还是to B的产品汪，都需要面临一个问题，那就是在业务发展到一定规模的时候，由于林林总总的原因，譬如出于安全性考虑，亦或是业务场景愈加复杂等等，市面上的第三方数据分析平台或者自家的平台已经无法满足业务发展的需求，这时候，就要着手搭建一个强力的BI工具，以适应高速发展的业务。

而一个好用的工具，将会解放生产力，极大的提高工作效率。加持了这个增益buff的运营和分析师们，将会如虎添翼，向你展示什么叫地表最强战斗力。

就算没有KPI的压力，那试想下，运营小姐姐因为你一手设计的出色BI系统而惊喜时，作为产(dan)品(shen)汪的你，是不是有机会……咳~

在进行产品设计前，先花点篇幅来讲讲数据在从产生到消亡（归档）的生命周期中需要经历哪些阶段吧。

图：图片来自网络，侵删

数据采集

数据来源分两块，一块是内部数据，一块是外部数据。对于to B的业务，内部数据多为业务数据，譬如零售业的供应链仓储以及GMV的细分数据等，金融业的交易流水和风控模型(风控模型也包含了用户行为数据)等，对于to C的业务或产品，除了基础的流量数据、业务数据外还会有用户行为数据等。这类内部数据的获取较为基础，常规的CS/BS的接口数据交互即可完成数据采集，对于C端产品，比较重要的是用户行为数据的采集，这里就需要做好数据埋点的工作，细化到每个事件的节点。

这里拿微信举例，从安装，启动，登录/注册的前期行为到聊天，公众号阅读，朋友圈查看等后期行为，不同流程的事件线会共用一些数据埋点。

一个用户从唤醒app开始，记录一系列的操作节点，带上序号和时间戳，就可以完善的记录用户行为日志，不过这类技术的问题就不深入探究，看研发团队怎么选择技术方案了。下面臆造一条行为组的日志信息。

先抛开数据加密的问题，这串日志的意思是下午13:40:03，ID为498161的用户，通过点击ID为164618的推送主动将app被唤醒，此时生成该条行为组信息的ID为341325，唤醒后按照推送给到的参数打开app进入微信tab页面，也就是首页，接下来停留了约4秒后，进行了拖拽操作，手指拖拽区间从x:334,y:130到x:560,y:363的位置，然后暂停了大概2s以后，点击了坐标x:634,y:30的位置，这个位置的目标是一栏ID为76316的对话信息，停留了约2秒后，点击页面中的输入框，过了约10秒钟，输入框失去焦点，此时输入框的内容为‘\u8001\u54e5\u53ef\u4ee5\u7684’（这里是Unicode，假装加密了：），与此同时按下了发送按钮。到了这里，这一系列的流程就已经完成了，收到好友信息的推送提醒了用户，用户做出了回应，并进行一系列的操作，完成了回复。

那么，这样一组信息数据有什么意义呢？

在微信5.3.1的版本新特性中，新增了一个这样的功能：可以撤回两分钟内发出的最后一次消息。

图：微信5.3.1新特性

对于这个特性，笔者进行了简单的思考：

1. 只考虑用户需求，不考虑商业需求。
2. 这个操作多为撤回者的需求。
3. 假设数据统计出一般用户从收到消息和看到消息的时间应该是在10s~30min，假设前两分钟有60%的用户已经阅读了消息。
4. 对想要撤回消息的用户进行研究，发现撤回者出于保密、失误、反悔或其它原因想要撤回消息，那这个准许反悔时间大概是90s，为了容错，将容错时间扩大一定的范围。
5. 出于对被撤回者体验的考虑，再压缩这个撤回的时间，避免用户阅读了消息，消息却被撤回，造成阅读者的不适。这个时间设定在120s。

上述的数值都为猜测，进行‘撤回’这一的功能设计前，需要通过数据来对用户行为进行研究分析，可以量化的数据为功能设计提供了衡量的标准，并在功能实现后进行数据反馈，从而修正功能设计。

为了简洁的表达，上文的日志信息只展示行为日志，缺少了客户端和服务端响应或监听这些行为的日志，从一开始app被唤醒，服务器就和app建立了数据传输，接收第一条请求时就录入了请求的终端信息，像设备型号，地理位置等等，一般来说app被唤醒的推送也会带有唤起方的渠道标记等信息。除了那些输入法开发商们，敲击键盘的行为选择不采集，因为对于绝大多数产品而言这类行为价值不是很大，还有一点就是，因为系统的权限限制，可能采集不到这类数据。

关于这类日志的采集，只要在需求的范围内，采集地越详细越好，这样可以精准的定位问题，是技术支持、运营策略，还是产品设计上的问题。在一些web类应用中也见到过每次拖动或点击就记录行为并回传给服务器的，这类高频的传输方式能够保障数据的完整性，但在高并发时会对服务器造成一定的压力，产品汪可在需求评审会上提出此类需求和顾虑，提前让研发团队了解到这种业务场景，并出具应对的方案，下文讲述数据处理时会顺带概述一些技术的方案。

内部数据都是自家的，只要权限允许，那就可以进行增删改查的操作，但外部的数据大多不公开，需要购买，有些甚至无处购买，且外部数据的结构不一，在进行数据归类的时候可能会造成一些困扰。对于那些能买的到的数据，往往需要进行数据清洗。

2015年号称互联网消费金融的元年，相关产业蓬勃发展。银行系、电商巨头以及一些传统企业陆续进军这个市场，这些巨头们手里掌握这充足的数据，足已支撑起一个较为全面合理的风控系统。但对于那些新入局的互联网团队，就没这么充足的数据源去搭建其风控系统，这时候，这些团队就需要从市场上‘专业’从事大数据服务的公司手头购买数据。然而，这些都是经过二道贩子，三道贩子甚至不知道几手了的数据了，每一层中间商为了盈利，往数据里面兑水，一些互金巨头为了干扰市场，也会对其中的数据进行加工并借壳售卖，到了这些使用数据的团队手里时，这些充斥着垃圾的数据能有效利用的可能不到一成。而清洗这些数据，需要花费的成本将无限大。一个用户风控模型的迭代修正，至少需要走完一个消费-还贷的周期，这中间需要的时间成本不是一般的团队所能接受的。

对于那些买不到，但又可见的前端数据，就可以通过爬虫的方式进行采集。爬虫的历史比较悠久，自第一个搜索引擎诞生已经过去了近三十年，而最早出现的爬虫却没有明确的说法，唯一可以知道的是自主机web时代开始的。而发展到现在，爬虫技术及其社区已经枝繁叶茂了，从近几年流行的python到最好的语言php，以及C语言系都可以拿来写爬虫。一般爬虫的原理都是构造请求，向目标服务器请求相关内容。数据本身就是一个相对敏感的点，有些数值类的数据往往是一个公司的命脉，为了遏制爬虫来采集数据，公司一般会设计不同的机制来反爬虫。譬如常规的服务器判断请求头部的UA和Referer，对cookie和验证码的验证，对IP访问次数的限制，通过对CDN标识的判别。还有一些前端的限制的方法，比如用JS动态加载数据以及一些能加大解析页面难度的做法。

比较成熟的就是一些前后端结合的方法，比如前文所讲的用户行为记录，再通过用户模型算法找出爬虫的特征，从而进行封杀。对于爬虫，大多数网站还是比较宽容的，或者说，没有一个万全之策来分辨真实用户和爬虫，因为误伤率一直是个绕不过去的坎。关于如何应对反爬虫机制，感兴趣的观众老爷可以绕道去携程技术中心的公众号看看，作为各类爬虫教程的目标网站，携程对Anti-Crawler这个课题还是有些心得的。

图：某公众号的前端反爬虫策略

数据处理

一般来说，涉及的数据的存储处理，不在产品岗的只能范围内。但是产品汪么需要明确数据调用的需求，以便DB开发设计合理的技术架构。按照数据所在的生命周期，或者数据被调用的频率，可以将其分为四个等级，活跃数据、休眠数据、沉默数据和归档数据。这里拿电商的订单周期作为范本解释。

• 活跃数据：这里的活跃数据一般指的是需求确定需要长期存储的数据。不包括那些存储在缓存里，在短时间会过期的数据。用户确认提交订单后，一直到确认收货，这个期间的订单的数据会以高频率被访问，用户、商家、平台、物流等多方角色需要查看这条数据，以确保这个订单完成。
• 休眠数据：休眠数据被访问的频率一般。订单走完正常的周期，已经超过退换货的期限时，可能因为保修，统计分析等情况任会被调用。
• 沉默数据：这类数据被访问的频率相对较低，在常规处理和存储后，已经将需要长期调用的内容存储到其它数据库表中作为活跃数据使用，此时源数据将进入沉默阶段，一般只在周期性的统计时会被调用。在分析季度商品销售情况时，需要翻出这笔订单来详细的分析。
• 归档数据：归档数据指的是已经被处理提取重要内容的源数据，为了数据完整性，对源数据进行归档处理，归档的意义不光是指备份数据，数据需要在生命周期的各个阶段做好备份工作。归档的另一个意义是压缩数据结构，保障核心数据能够被快速响应。

在日常工作中，数据的等级界限也许不会这么明确，具体还得看需求的情况。

数据应用

讲完了数据的产生到归档，相信观众老爷心中对这个BI数据系统的搭建已经有一个整体的规划了，下面笔者将描述在笔者心中，一个理想的数据BI系统，应该是长成什么样子的？

图：产品架构

后台的在进行有关数据的操作时，都可以选择进行GUI和SQL的操作。下文的所有功能只描述GUI状态下的使用，不描述SQL状态下的使用。保留SQL功能的原因有以下几点，就像Bash会比GUI界面发生意外的概率小很多一样，纯SQL操作比GUI操作来的稳定，而且数据开发更乐意去使用SQL。这种保险设计可以在产品迭代的过程中，实现一些因为不常用而缺失的功能。

下面按照操作流程，讲讲各模块的功能。

数据管理

在生产环境中，业务数据，流量数据或着其他数据的元数据已经产生，存储在数据库，这部分数据称之为「数据源」，这个功能的页面称之为「数据源管理」，整个后台对数据源的唯一的权限只有读取(select)，不然误操作造成损失，这口锅真不好分，直观的看，好像是操作者的失误，再深一步讲，是技术规范的缺失，但追究到底，还是产品设计的缺陷，所以，权限切记控制到只读。用户(运营，数据分析师，数据工程师皆称为用户)可以读取数据源库表中的元数据，并存储到数据库，这部分被提炼过的数据称之为「数据集」。许多数据需要每日定时或者按照其它周期进行处理，譬如那些避开服务器并发的时段的数据统计，这种数据的错峰处理大多放在凌晨或者其他服务空闲的时段，为了节省用户的精力和防止疏漏，这种周期性的点控式的任务就显得很有意义，但是单个任务没法满足对复杂数据的处理需求，借用MySQL的事件调度器(Scheduler)和触发器(Trigger)的设计理念，将这些任务连接在一起，让它们按照指定条件依次执行，从而实现按照序列处理数据结构和数据内容的任务环。数据集操作生成的库表的增删改查权限控制在初始化时，默认只开放给用户自己，若有需求，后期可以在权限管理中配置。

业务报表

在完成了对数据的处理后，数据还只是纯粹的单一结构的内容，干巴巴的数据难以直观地观察，所以数据可视化这一功能必不可少。市面上优秀的开源前端框架有很多，这里推荐两款——AntV和Echarts。这两块框架能够满足绝大多数业务场景，尤其推荐Echarts，给某度开源如此良心之作打call，Echarts中gallery社区的作品堪称惊艳，如果这个框架能将性能再继续优化下去，那就是做数据可视化的不二之选。关于AntV的话，友商都说Ant Design可能是开创了UI组件库的先河，组件的视觉、交互设计和前端的融合可谓是相当让人佩服。在实现上使用了较为先进的框架，主要还是React实现，好在今年八月，Angular版本的总算发布了。不过框架归框架，研发同学选择技术方案是他们的权利，产品汪在进行后台设计时可以参考AntV，这样可以让你少走很多弯路。业务报表设计功能可以达到高度自定义，可以对业务报表的菜单、页面布局进行设计。在进行图表设计时可以选择丰富图表类型，从常规的折线图、柱状图和饼图等到不同领域常用的图表，譬如K线图，漏斗图，关系图等。然后再给图表填充数据，按照规则给图表入参，与此同时对该表报的展示对象进行用户选择。这种高度自由的操作方式，看似会增加研发的周期和成本，但这种设计实际上将会解放研发同学。在后期产品迭代成型后，用户自主使用数据生成报表，而不是常规进行需求-开发的周期，从而让研发同学将更多精力放在核心技术上而不是业务上。所以综上所述，这种设计不光是功能上的设计，而且还是一种成本转移的设计。

实时监控

该模块分两个主要功能，一个是概览功能，一个是异常预警。概览页面就是业务报表的Dashboard，唯一的差别就是这里的数据多为实时数据，所以不赘述，如果希望这个门面能好看点，那就单独拿出来，作为一个独立的功能需求进行设计开发。关于异常预警模块，很多时候名不副实，预警意义在于预测当某个数值达到临界点时进行报警操作，但这种预警机制的算法可能会复杂，难以制定产品需求逻辑。所以在实际设计中，警报触发的条件可以配置多个，按照执行周期轮询，触发时进行短信或者邮件等推送操作，和数据源管理一样要注意的是库表名称的日期变量和事件环的设定。

权限管理

在讲整个产品设计中，一直在强调权限的管理，不是笔者话多，这个关系到数据安全的问题还是得注意下的。数据库的权限控制应当从服务器、数据库到特定表，关于控制到特定的列甚至存储过程，虽然MySQL有这个功能，但好像常规的权限真的没必要控制到这么精细。当然，对于数据结构和数据内容的增删改查权限还是有必要做权限控制的。最后，加上基本的操作日志的展示，用以查错问责皆可。

讲到这里笔者也就将整个产品设计的思路叙述完成了，观众老爷可能会觉得没有图解，过于抽象不好理解。但其实，笔者是故意没放图例的，因为担心放了原型后，会误导读者进行雷同的产品设计，故而只叙述核心功能，不做视觉和交互上的表现。如有哪里看不懂的或有歧义的可以向笔者公众号提问，笔者会抽时间回复的。

企业在业务早期用第三方的平台服务是高性价比的选择，但也要考虑到后期数据迁移的问题。第三方平台为了最大化平台的价值，不可避免的设计通用的产品结构和服务体系，以兼容更多业务场景，但这样一来就不能适配企业一些特殊的业务需求。最重要的是，自家的数据的一系列操作都在别人家的服务器上运行，这个数据安全的问题是块心病。今年年中时，作为菜鸟物流的创始成员之一的顺丰，受到菜鸟集团的一波突袭，这已然不是站队的问题了，从IaaS到SaaS，一大撂数据的处理和传输都是经过别人家的基础设施，在信息主权这个问题上，一旦发生了纠纷，那处理起来一个头两个大。前阵子开完的人大常会上，新修订了反不正当竞争法，也许有希望改善这个问题。毕竟对于企业而言，还是希望将更多的精力投入到业务经营上，而不是进行一些糟心的商战。不过好在市场上已经有越来越多的数据服务供应商已经可以提供私有化部署，加上个性化的功能设计在一定程度上可以解决企业的业务需求。

究竟是自建BI系统还是用第三方的平台，其实，在观众老爷心中已经有答案了。

图：数据服商

文中产品设计参考了Dataworks和QuickBI的功能，如果观众老爷有兴趣可以试用下，只是这个价格有点不太美丽(高级版的功能健全，基础版的功能阉割太多了)。

笔者才学疏浅，若观众老爷有什么高见，还请猛烈拍砖。

作者：水果篮子，公众号：老杨陪你来说事儿

本文由 @水果篮子 原创发布于人人都是产品经理。未经许可，禁止转载。

题图来自 unsplash