创新互联建站主营大姚网站建设的网络公司,主营网站建设方案,成都app开发,大姚h5重庆小程序开发搭建,大姚网站营销推广欢迎大姚等地区企业咨询
夏凯
卡内基梅隆大学计算机系毕业，曾供职于Evernote数据团队和微软Bing.com搜索引擎广告部门。回国后作为早期成员加入小红书，先后从事大数据，用户增长，项目和团队管理等工作。
我最初是在美国做搜索型广告。回国之后，加入小红书，做基础的数据服务、数据平台。作为创业团队，最开始想做数据挖掘、数据统计、增长，但是没数据，所以先得把数据的采集、管理、计算、储存的技术架构搭起来，有了技术架构之后，再做进一步的数据分析，基于分析与决策，然后再做增长，进而推动产品的迭代和公司各个层面的决策。因此，我将从技术架构、到分析、增长、产品的路径进行分享。
一、享物说是什么
先介绍一下现在做的一个事情，享物说是一个小程序，也有APP，主要是做用户与用户之间物品互换社区，有一点像闲置交易。由于免费，用户与用户之间，通过我们定义的小红花积分互相换东西，用户黏性与兴趣非常高，增长率也非常快，同时借着小程序传播非常快的特点，在过去10个月内，我们从0做到3000万的节奏。B端商业/企业端可以在平台上送东西做推广、回馈粉丝活动。除此之外，我们也会做一些公益，如捐赠图书馆等。
随着数据增长的速度，会对数据团队提出很大的挑战。对我们来说，最初的挑战是业务在10个月内以非常快的速度增长，我们内部从零到一搭建一个完善的数据平台，支撑高速发展的业务是比较困难的。因此，基于业务，我们首要考虑的是需要支持什么样的业务数据分析需求；第二是如何在短期内迭代一个MVP的产品支撑这些需求，基于以上思考，我们利用云计算工具和第三方服务，加上我们团队工程师的努力，再根据产品反馈、业务部门使用数据的反馈，我们对数据平台进行了迭代。
第一点：提高产品和改善用户体验。在对产品功能设计、流通布局、页面设计等方面进行决策的时候，我们更多是希望依赖数据，而不是经验。然而通过数据分析支持决策，就需要采集、计算、存储与分析工具。有这样一个场景，我们曾经很强烈的争论过，在产品设计与业务设计之间，到底应该用单列瀑布流的形式，还是用双列的形式？
单列图文并茂，可以沉浸式的浏览，但是一次只能看见一个；双列的布局是一屏可以看到多个，点进去再退回来，但是可能会打断用户浏览。今天看来类似抖音与快手的布局，在当时还没有快手让我们做参考。当时，我们把这两个布局分别分配10%的流量，过一段时间后，通过看使用时长、用户黏性详情，我们依靠数据决策采用了双列布局。由于抖音的出现，我们重新设计了单列布局，让用户体验变的更直接、更沉浸、交互性更强。
第二点：IF U CAN'T MEASURE IT, CAN'T MANAGE IT。在公司管理或者决策分析时，在没有数据支持情况下，大家很容易陷入主观讨论和争议。因此，我们在进行产品流程/功能的迭代，通过借助数据分析工具，根据数据分析结果制定完善的迭代方案，避免陷入无意义的争论中。
最后一点，上升到文化层面：主动意识+智商+理智环境+信息透明 = RELIABLE DECISION MAKING。我个人认为帮助整个公司/组织做可信赖的决策支持，有四个因素：主动意识、足够自驱以及智商，后面两个因素和数据息息相关，分别是理智环境和信息透明。在相对理智的环境，让每个人都可以发声，让每个人的意见都可以被尊重，通过数据进行决策。另外一个因素就是信息透明，每个做决策/参与决策的人，基于足够多的数据信息，进行有效的判断。
对于一家企业而言，对数据需求强烈的部门如市场部、运营部、销售部等，市场部每年推广费用巨大，通过数据分析进行ROI计算，因此市场部对于数据质量、渠道流量质量有极高的要求；运营部门对数据灵活性有很高的要求，比如说今天运营部做一个活动，如何衡量活动对拉新的效果以及对老用户促销效果，通过分层对不同用户的召回效果进行评判活动的质量。而这在数据灵活性、指标灵活性上面需要进行多维分析。
研发团队更多是支持线上业务，因此对数据平台的高可用有很强的依赖，如果他的推荐用到你的数据结果，不管是计算用户中短期的用户画像，或者直接通过数据结果做推测或者对搜索排名做决策的时候，需要数据保持高可用，并且提供可编程可直接对接的接口。产品这块提出的需求，一是基于自己的KPI指标体系，二是不同的产品经理会看不同的指标。大的产品经理，会看GMV，小的产品经理会看注册、转化、点击、测试结果等，这些要支持各种不同力度下钻，以及指标分析。
最初，我们是通过在业务数据库里面跑数据，工程师需要写脚本，以及通过跑数据填到Excel里面，再给到业务部门。这种方式非常不灵活，以及会影响线上的业务访问，即使将数据同步到其他数据库里面，依旧会出现只有最终业务数据结果，没有过程问题。例如订单数据，要想知道这个订单从签收、流转、发货的状态流转上是比较困难的，因为只有当前的用户状态、交易状态、支付状态等最终结果。
在迭代过程中，我们需要的是用户行为日志，通过状态变更日志这样的方式，把一些结果的数据落到日志里面，最后再做分析。这样就提出来对日志的采集、同步计算与结构化的需求。
当时一部分业务在腾讯云，后来我们采用了混合云方式。我们的数据平台架构随着业务量的升级，经过几次迭代，下面和大家分享一下我们在迭代过程中是如何思考的，以及为什么做这样的决策。
最初的业务分析需求比较简单，当时对数据分析需求较急的是业务部门，如对某些接口的访问数、某些功能的浏览量、点击量分析这些需求，工程师一天就可以完成。然而随着业务量上升，接下来各种各样的灵活性数据分析需求扑面而来，无法应对。
前端、客户端、小程序、移动平台、PC等来的流量，这些数据会最终会落到两个地方，用户行为数据会落在用户的访问日志上，这些日志被进一步收集采集；业务数据会通过定时同步的方式，把业务数据定时同步到文件储存上，最终这些数据会落到AWS，基于数据仓库，我们直接落到数据仓库，这个数据仓库可以结构化，实现速度较快，需要维护与搭建的成本相对较低。
当时遇到两个问题：一个是这套系统的灵活性比较有限，当有实时、大量的数据需求，以及需要快速拿到分析结果时，会产生计算跟不上展示问题。另外，当时的AWS只有线下库的专区，数据会有延时。随着开放，我们迅速迁入过去。因为有实时的数据需求，我们用了AWS版本的链接数据做同步。然而仍然会由于大量的数据，导致计算存储量问题。
基于以上情况，我们搭建了自己的EMR数据集群，之后进行分析数据、离线运算结果，可以迅速被业务部门使用与访问，进而可以支持到物流计算、KPI计算。但是当不同数据源的数据量都在快速增长的时候，这样的方式也变的不是很稳定。
在我刚开始做这件事的，我们工程师是自己写任务，管理大量脚本，跑各种有前后依赖的任务，非常花费工程师的精力，特别是在工程师只有两三个。在这种情况下，我们接触到了DataPipeline，他们拿出了相对成熟的数据管理平台DataPipeline，并且通过私有化部署在我们服务器上以及完善的解决方案，这在很大程度上帮助我们解决了工程师遇到的诸多问题。可以相对比较稳定的支撑我们推荐、搜索、一线分析、业务分析等不同的场景。
我们在只有几个工程师的情况下支撑了整个数据架构，供业务部门进行数据分析。我们目前用Airflow做一些任务调度，以及通过Tableau进行可视化分析。
下面和大家分想一些关于Growth内容。随着业务量的增长，有了数据、以及分析工具后，我们需要进行分析，持续化完成增长目标，包括拉新、激活、召回到留存这些模式。我今天和大家分享的内容将更偏数据分析的框架，这个框架简单总结是以下五步。
需要有一个可以监测的数据平台或者数据工具。通过数据平台/数据工具，进而可以分析当前发生了什么，以便如何进行优化和迭代。监测最理想状态是每天当我进到办公室的前5分钟，浏览一下数据简报，对整个平台、整个产品的状况有一个大致评估。
当发现产品有好/坏状况变动后，再进一步拆解这些指标，进行分析，做进一步挖掘。
下图是一个Growth案例，例如我关心的是整个产品使用总时长，每天都会关注指标变动，因为天和天之间有周末，因此会有较多的波动，而通过七天平均时长来看，就相对平缓一些，这是通过时间层面看出趋势变化。
一旦看出趋势变得不好/更好，通过把目标、指标拆解进行分析。一个简单的拆解思路就是对于使用时长来说，通过内容产生和内容消费两个端来看，到底多少人贡献了可以增长时长的内容，以及多少人来消费这些内容，增加时长。例如，享物说是一个内容消费平台，我们的内容都是用户发布的，发布内容包括话题、笔记或者是物品，我可能会分为以下几个维度，谁、什么时候、如何发布、新用户/老用户、哪些地区的用户、在工作日还是节假日、晚上还是白天，发布的内容会分不同品类、母婴类、穿搭类、美妆类还是其他，如何发布？是通过小程序、APP、安卓、IOS、PC端，从活动页面进入还是从专题页面进入。
之所以进行维度拆分，当我们看到一个大指标发生变化的时候，无法立刻知道是全局还是只在某个时间节点上发生了变化，因此在进行这样的拆分后，如果这一指标在每个维度都发生了变化，可以判断可能是全盘的变化；如果这个指标只在某几个维度发生了变化，例如只在上海地区新用户男性中发生了变化，我们可能会有一些基本的假设，进一步就可以用这些假设验证是不是上海最近做了线下活动，或者是不是在IOS版本上发生了BUG。
在对指标进行维度拆分后，基于挖掘/猜想，再通过数据进行验证。进而对产品的一些功能进行改进或者流程上的迭代。
完成“测”的部分后，进一步将你想要做的改动放到产品里面验证，跑一段时间数据，通过A/B测试以及数据效果可以发现精细的测量结果。
迭代部分就是通过重复这个过程，在产品的样式、按纽文案、布局上做各种各样的改进和测试。因为想要快速产生产品或者指标效果，质的飞跃是比较困难的，通过不断优化能够逐步把产品往好的方向推进。
以上是基于数据做增长类分析的简单框架，最后和大家分享的内容是如何用数据讲故事的套路。
当我们需要展现数据或者展现论点的时候，如果只是呈现数据，别人无法直接看出来你想要表达的观点。如果是将数据可视化，就会更容易的让人清晰知道你想要表达什么。例如下面这张典型的电商数据可视化图，横轴代表物品浏览量，纵轴是物品实际销售量，不同颜色的圈代表了不同的品类物品，不同大小代表了不同的利润率。所以它代表一个物品被看了多少次以后，成功交易出去。比如右下角，代表的意义是很多用户看，但是没有人买的东西，左上角代表用户看见立刻就买的物品，这是我们在看到这张图对转化率直观的感受。
为什么数据可视化或者用数据讲故事特别重要？在一个数据分析师或者数据科学家的整个工作流程中，可视化只占非常小的一部分。更多精力是放在确保数据正确性，确保数据采集、数据清洗、整理、计算、建模整个完整流程。但是通过可视化或者用数据讲故事，往往是最能被人感知的环节，而且在这个环节也最缺少现成的经验或者可直接学习的教材或者技能。所以在这个方面和大家相互交流的一些经验。
一般数据分析分为两类，一类叫做解释性分析，一类叫做探索性分析。探索性分析是当我们通过数据报表或者是一些日常的数据分析，发现问题后，我们会进一步带着这个问题找一些假设，然后再用数据验证它。如果一旦觉得这个假设可行，我们就会需要一些解释性的分析把它给相关的人看，告诉他为什么有这样的假设，以及觉得为什么应该做ABC不同的方案。这时候我们需要用数据解释前面提出的方案/论点，这两个过程往往是必不可少的。
当我们向别人呈现数据报表/PPT，第一，听众会是不同的人；第二，会是不同的场景。例如工程师，他可能会更关注你的数据分析如何推导生成的，为什么产生这样的结果？他会对结果推理的可信度以及产生过程有一个非常强的质疑，你需要给他非常强的证据。如果是销售、市场人员，对这个过程就不是特别关注，他关注你的分析结果对他会产生哪些结果，以及如何利用这一结果，因此就需要对不同的人说不同的话。
另外一种情况，有的人天生带着一些先入为主的偏见或者意识。例如，当你拿着数据分析结果和产品经理讨论的时候，他会拿用户反馈的直接结果，来驳斥你的数据分析推理。为什么会有这样的情况呢？因为用户反馈是一个更直接、让你直观感受更强的意见，但是数据确是一个比较冷冰冰放在那儿的东西。除此之外，还有一个原因叫做幸存者偏见，愿意给你反馈，特别是负面反馈的人是非常多的。因为用的好的人可能就不说话了，用的不爽的人才会过来骂一骂，如果你对有些功能提出不同意见的人，可能他的意见表达更强烈，你会更关注到他。这是在平衡用户反馈结果还是数据调研结果做决策的时候需要注意的点。
这当中常用的例子就是电梯间测试，不管是创业还是在公司里给上级领导汇报一项工作，或者想要争取一个新的方案通过，都会有这样一个过程：如何在短时间内让对方GET到你想要表达的点。当他愿意进一步和你做沟通的时候，你再给出更多证据或者数据来证明，最终当他和你结束这场对话的时候，它进入的只是你一个或者一两个结论，这就是电梯间测试的全部过程。
呈现数据也是这样，当你呈现数据给他的时候，你只希望他记住一个或者一两个点，能够GET到你这段数据需要表达的意思。
下面我用两个例子来解释，第一个例子是原来做过一个客服工单完成度记录。把每个月客服工单完成情况记一记，区分收到的工单和处理的工单，从这个报表的呈现上其实没有什么问题，但是我们也看不出需要关注什么。它的优化是什么？背后其实想说的是随着后面几个月，我们收到的工单越来越多，收到的工单处理不完，所以把收到的工单和处理的工单直接罗列在这里，对后面几个月做直接数字直观的呈现，把结论贴在这儿，告诉上级因为后面处理不完工单了，需要急增人手。这是第一眼看上去知道你这个图要表达什么、说明什么。
对于饼图也是一样。饼图在我看来是一个非常不好的数据工具，尽量不要用饼图。当我们在做共性优化之后，有更多人满意，但是因为其中混杂的人数比较多，需要反应一下才能看出不同的颜色代表不同的含义，再对应观察一下才会发现原来是满意的人多了。另外，如果我想要表达完全不同的意见，通过做3D饼图操纵数据结果。
下图是完全一样的饼图，当我用不同的方式做3D饼图的时候，你会在左边看出来是支持人更多，右边反对的人更多。
以上分享的内容基本涵盖了我工作过的不同领域，最初是如何通过数据架构或者数据工程迭代去支撑业务，进一步如何通过数据做增长，最后是当我有各种各样分析场景后，我如何让分析和沟通变得更加高效。
谢谢大家，给大家分享的就是这么多。
点击这里，免费申请DataPipeline产品试用
重庆分公司
重庆分公司
