产品经理萝卜

上一篇文章中，阐述了实现一个智能化数据清洗工具的思路，其中最关键的是自动构建数据质量检查规则。自动生成数据质量检查规则的基本思路如下：构建质量检查规则模板库。根据项目过往经验，分行业、分主题构建数据质量检查规则模板库，比如，创建日期模板库就可以包括日期格式检查、非空约束两个规则；构建元数据的同义词库。利用词典法、机器学习法或人工方法，构建元数据的同义词库，比如，创建、成立、设立等是同义词，后...

CEO门户诞生记（一）昨天把思考了几天的CEO门原型发送给了老大。这个门户可以认为是高层门户的切入点，通过过该门户的研发，打磨出一套具备一定交互分析能力的分析框架，同时也借助各项目国CEO，督促规范BOSS操作，提高数据的准确性，尤其是营业收入，这部分数据一直得不到财务部门的认可。老大在回复邮件的时候，字里行间认为规划不够大，他希望能实现人、财、物的分析，对于这个目标我不反对，但现阶段经分的数...

月度分析以自然月为单位汇总经营数据，让CEO可以从不同维度分析和盘点经营结果，找出差距。一级分析维度包括：月度、地域，其中，地域以目前的管理单元大区和城市进行细分，这也是BOSS系统可以准确提供的程度。运营分析版块，目前管理上习惯分为DTT、DTH和DTV三张业务线，虽然这三者的指标和细分维度非常类似，指标包括新增用户数、续费用户数、ARPU值等，细分维度有终端、节目包等，具备以一个分...

立项会议今天召集了一个会议，包括 老马、朱磊、璐璐、艳华几个人，介绍了CEO门户的用途、功能及未来的意义。不出所料，老马对这个产品的交互功能很感兴趣，他理解通过这个功能，可以简化现有报表的复杂度，可以把他从提数中解放出来。在开始，他还强烈建议把曹博士请过来，他担心没有人做。遗憾地是，曹博士不在公司。最后决定：分期实现，先安排一个人开发一个版块；性能问题需要后期专门解决，需要引入月度宽表...

整体分析框架今天在思考怎么统一门户的维度使用方式，总结如下：维度分为一级维度和二级维度，一级维度的操作以”过滤“为主，二级维度的操作以”下钻“操作为主；门户一级维度，以管理单元为主线选择一级维度，目前包括日期、国家、大区和城市；版块一级维度，指每个分析版块的一级维度，目前以终端分类为主，即清流和付费，以及电视机的型号。暂时没有把节目包列为版块的一级维度，这是考虑到节目包更适合做下钻操...

开发工具的选择经过几天的评估，永洪工具不能实现原型中关键的交互效果，也就是选择各项参数数（包括指标、对比方式、分节目包）后，数据图动态变化。现有的BI工具可以将这种交互方式转变成多个tab页的形式，但这种交互虽然可行，但缺点也很明显，也就是要提前做很多的图，根据组合原理，DTT运营月分析部分的数据图可能会有50多种，提前开发这么多的图，费时费力不说，一大片tab也很难排列。对于CEO门户，交互...

今天收到一封售前的邮件，关于H省网运营商要做手机APP数据分析的需求。客户对要分析的数据内容没有很清楚的想法，只给了百度移动统计的页面。这个需求本身不复杂，只是涉及的厂商较多：APP由我方提供，但其中有部分业务功能是通过H5的形式集成自大唐，数据分析平台由亚信提供。从技术角度出发，这个需求有两个解决方案：以SDK的形式集成业界成熟的数据分析云平台，包括百度移动分析、友盟、growio等，数据...

技术选型和人员选择今天老大特意把我找过去，询问CEO门户的进展。告知目前正在评估arcplan是否适合开发门户，永洪已经被排除。他认为不应该绑定到arcplan工具，存在风险，应该采用前端技术开发。从实现效果来看，前端技术是合理的，肯定可以实现预期的效果，但也存在着几个困难：前台分析框架，需要前端技术相对较强的人员来搭建初期的技术框架，支持灵活扩展分析版块、增加分析指标、扩展图形显示方式...

收到老大关于大屏项目重构的邮件，起因是老板要把大屏内容放在一楼监控室去展示，做为日常参加的一部分。因此他希望用前端技术全部重构整个项目，以便更加稳定。我非常担心这个”面子工程“的项目会浪费更多的资源，而丧失了其它项目的机会。 另外他邮件中也提到了对目前万村通部分展示的不满意，希望加入视频和图片的展示。虽然对于这个想法，我从内心当中是反对的，一个PPT形式的展示，非要搞成动态网页，而且也不是长期使...

产品立项会议今天补开了CEO门户的产品立项会议，召集了海外事业部、收视率调查中心的外部用户以及研发、测试的相关同事。在会议上，介绍了CEO门户的立项背景以及要达成的目标，对原型系统进行了详细讲解。会上讨论的焦点有以下几个：访问速度的挑战，使用者多数都希望操作能在5~10秒内有响应，但由于汇总的数据较多，能不能达到这个速度，心存担忧，需要进一步讨论技术架构。大家基本能达成一致的是，月度数据...

技术原型今天基于arcplan开发的功能有了初步结果，交互效果基本满足预期，但存在两个问题：首次打开太慢，应该是查询的时候执行了所有的SQL语句，对于首页没有使用到的数据也做了查询，没有实现“懒加载”机制。arcplan目前是20并发，将来上线后同时使用的用户应该会超出这个限制，需要进一步扩容，而arcplan能否进一步扩充都是一个未知数。接下来需要组织一个会议，针对技术原型和上...

敏捷BI的思考这几年在BI市场上，出现了一些区别于传统BI的敏捷BI工具，国内的如永洪、帆软、smartbi等，强调快速交付、简单易用等。网上百度了一下敏捷BI这个概念，没有找到统一权威的定义，下面这个简单明了一些： 敏捷BI（Agile Business Intelligence），顾名思义，就是反应迅速且敏捷的商业智能系统。敏捷可以从以下几个方面体现： 快速提供可选...

近期公司的某个项目遇到了一个问题，通过手机APP激活的用户没有正确输入用户地址，而地址对于后续的统计非常关键，运营线的同事提出了一个想法，即对于这类用户要在激活的时候加限制条件，地址输入不正确的情况下不允许提交。这个方法可以解决没有把地址选择到相应层级的问题，但解决不了错选的难题。对于为什么没有选择正确的地址，项目国的同事给出了自己的看法：图省事，现在APP只要求必须选择地址，管理上的要求一...

现在的校验规则模板，把校验规则的种类、含义以及要填写的内容整理成了excel通用模板，但在实际执行过程中，每个人对校验规则的用途和校验方法存在不同的理解，而对于如何写出相应的校验SQL，有不同程度的困难。现有的校验规则说明如下图：要填写的校验规则模板如下图：从上面的图中可以感受到，如果表的字段较多，除了逐个判断每个字段适用的校验规则，还要写出相应的SQL语句，再将结果粘贴回来，大量的工作...

上周参与了大数据筑基工程对现有数据平台的对标分析工作，各厂家要分析出自己平台的现状、差距以及要未来要改进的点，从而为筑基工程制定出接下来的行动计划。通过分析，发现公司产品在数据清洗、数据质量以及数据分析方面的覆盖度还是挺好，但在其它诸如统一安全、统一管理、数据共享等领域，则显得有点单薄，当然这也与总体方案对这方面的规划本身很超前也有关系。抛开其它方面不谈，产品在数据质量、数据清洗这两方面的满足程...

数据清洗是数据分析过程中最基础的工作，也是最累、最繁琐的部分，不像数据挖掘、数据分析看起来那么光鲜，做起来枯燥乏味。当然，这也与数据清洗工具的自动化程度不高，需要人肉去完成大量的ETL开发工作有极大的关系。为了改善这种局面，可以让ETL工程师减少重复性的编码工作，将更多的精力投入到数据分析当中，更加有效地发挥人的聪明才智，提升数据价值。下面是加入了“智能化”元素的数据清洗流程图。构建数据质量...

对pdf（或其它非结构化文件）的分析场景可以归纳为以下几种：全文检索。基于solr或ES搜索引擎组件，对文件内容建立索引，通过关键字对文件进行检索；结构化分析。把pdf文件内容转换为文本，提取内容中的关键属性，比如，标题、来源等，建立表结构模型支持后续的统计分析。下面是项目中所做的一个案例：语义分析。在上面结构化分析的基础上更进一步，对其内容进行分词、词性标注、命名实体识别等处...