微信

数据分析产品经理(社招),广州

部门:微信基础产品产品中心数据分析组

岗位职责:

  • 与产品经理对接各类数据需求,推动产品的发展与改进;
  • 对重点数据进行监控,能从数据异动中主动发现问题,分析和探索解决方法;
  • 对业务数据深入分析,为产品运营、业务决策和产品优化提供数据支持;
  • 对产品相关的热点问题做专题研究,收集相关数据,输出有价值的分析报告,用数据支持决策。

岗位需求:

  • 有独立解决问题的能力,能自主攻克课题;
  • 对数据可视化以及海量数据分析有丰富经验和工作热情;
  • 数据库(MySQL or Postgres)以及Hive/Hadoop实操经验;
  • 具有数据可视化软件(比如Tableau, Excel, Google Analytics)的使用经验;
  • 有较强的分析总结能力,熟练使用各种数据分析方法,可以对数据进行归纳,汇总,并进行专业细致的分析;
  • 有规划能力及意识,并且有较强的执行力;
  • 较强的服务意识,良好的团队协做能力,工作认真细致,具备高度的责任心;
  • 本科及以上学历,计算机,数学,统计,信息科学相关专业者优先;
  • 2年以上大规模数据分析经验。

书籍

  • 《数据分析之美》
  • 《谁说菜鸟不会数据分析》
  • 《用数字说话》
  • 《谁说图表不会说谎》

要点

  • 看待问题的角度是否ok
  • 分析的角度是否全面
  • 有没有关注到细节
  • 道理是否符合逻辑
  • 回答的表述是否清晰有条理。
  • 切忌空泛。这是关键
  • 产品感觉,个人经历,真诚。

行动者+思考者+创造者。这类产品经理在产品层面之上还要有创新思想,这个能力是优秀产品经理必备的.思维绝对不能被框架化。实践中就要考虑用户真实需求和市场趋势变化,并结合数据给出产品的创新东西。先给个场景模拟来形象化三类水平pd,顶头上司突然叫你拿个盒子进来他的办公室。1.此类的产品经理会直接给领导找个盒子,比如邮局给的,装零食剩下的之类2.此类产品经理会思考领导需要的盒子到底是什么样子,一问领导才知道是装垃圾的。产品就找了个上档次的垃圾箱给领导3.此类产品经理一问领导是要垃圾桶后,就在给了大气的垃圾桶后,再叫了某人几点后定时去领导办公室处理垃圾换新垃圾袋。经常在面试人中了解过往的经验来匹配下他是哪种程度。抛砖引玉。

同理心( Empathy)我个人觉得,如果说逻辑性是智商的主体,那么同理心就是情商的主体。同理心的重要性不言而喻。简单的问题包括,你觉得你的简历在设计上可以怎么优化?为什么?你觉得作为考官,我为什么要问上面的问题?你和你的父母曾经最大的争执是什么?你怎么解决的?(观察是否考虑到对方的感受)其他的点,例如创造与、抗压性、沟通技巧、性格态度、技术背景、时间管理能力、商业嗅觉等,我一般面试提问较少,并不是不重要,只是没有前面几点那么必要罢了

真正数据挖掘相关的数据分析,或者说垂直领域的侠义的数据分析,就是指数据挖掘,从问题识别,建模,算法设计与计算求解,到后期验证,对比分析,结论报告等,是将数理方法应用于实践问题的复杂过程。

产品经理应该了解利用各种资源和资料,包括数据、设计、心理等各种层面的知识,帮助自己做好最重要的工作,即产品设计与运营。

仅对技术的要求来看

  1. 查数 = 数据分析(知道pv,uv,点击流,能写sql和脚本扫log)
  2. 在1T的log级别上查数 = 大规模数据分析,用户行为分析(要用hadoop了)
  3. 用svm,朴素贝叶斯,knn一类的,不能叫数据分析了,叫数据挖掘了(R,matlab,python科学计算等)技术其实不重要,关键是对业务的理解

每个产品经理在产品设计前就需要明白一个最简单的公式:产品价值 = 产品带来的收益 - 设计研发运营成本 >0

对于大多数网站,如果你想用数据为导向,必须建立系统级的A/B测试机制。对于界面层面的重构,一个产品经理+一个工程师,一天用这个系统一天至少能做3-4个。系统级别的A/B测试要能够保证快速上线,第一时间看到数据,一旦超过临界值直接结束测试、保留数据并生成报告(直接邮件发送,而不是让产品经理想起来跑到后台再查)

对于做社交网站,或者有复杂用户数据模型的公司,要在界面呈现和用户数据之间建立匹配系统。这样产品经理可以设计几种呈现模式,丢到匹配系统中,过不了多久,就能发现用户对不同呈现的数据反映的不同,然后系统性地固化这种机制。

通过cookie或者用户登录信息,建立针对不同用户的内部tag系统,看这些tag在系统2里有没有明显差异。如果有就可以固化下来,用来提高关键指标。所以,我现在对于数据分析的感觉是:

  1. 要提高一个数据指标,盯着它是没有用的。必须找到影响这个数据的另几个可操作性更强的数据指标,调整它们。
  2. 分析数据的可能性要充分,充分分析的基础是测试充分多的可能性。如果你想测试图标的颜色从绿色变成红色会不会更好。那为什么不测试一下蓝色,紫色和黄色呢?
  3. 如果小规模数据已经可以说明问题,就没有必要延长测试时间,也没有必要扩大测试范围。
  4. 要充分利用计算机来帮你做数据采集和分析,缩短数据分析的周期,降低数据分析的成本。
  5. 有必要的时候,可以让计算机帮你找pattern,因为计算机没有偏见。

发声的数据是最好获取的, 但如果没把这些沉默的数据考虑进来, 那么这种数据分析是不靠谱的. 所以除了数据的结果, 还得尝试解读这些数据. 而解读数据就完全依赖人了. 把沉默用户当做支持和反对的中间态

我一直认为数据本身是带有主观性的, 完全客观的数据是没有的. 数据的获取方法, 数据的解读方法, 数据的统计方法, 都是人的决策. 一份数据拿出两个相反的结论来也不是没有可能. 即使主观上没有偏向性, 也受限于方法和视野. 决策上最终起作用的还是人不是数据. 虽然人有那么多的不确定性, 还可能出现争论, 扯皮, 不敢承担责任.

  1. 对数据有客观的分析过程,最终产出的不应该只是一个结论,还应该包括你的分析方法和分析过程,这些也要讲给RD,只有这样数据才真正起到了应有的作用!从这个角度讲为什么使用4星,而不是3星或者5星,也应该是给出理由的,而且必要时也需要数据证明。
  2. 不要对数据想当然,很多pm拿到数据根本没做深层次的分析就直接告诉RD你看这个数据说明什么的,甚至其他网站的运营数据,很多PM会直接拿来讲给RD,这个情况我相信即使资格深一点的PM也有的。我要说的是不要把其他人的数据想当然成我们自己,一个产品能够成功是有个过程的,这就是我经常说的成长期,我们虽然没办法参与每个过程,但是在使用别人数据的时候还是需要分析这个过程的,数据不能脱离年代、环境、用户、等等很多客观因素单独存在!
  3. 不要过于依赖数据,数据只是我们产品发展中辅助的东西,PM应该更多的了解很多数据之外的事情,如社会环境、用户水平、竞品状态,这些东西新人更应该注意,不要总拿个数据跟RD转牛脚尖!

一位是亚马逊的首席科学家韦思康,曾经,我告诉韦思康,KPI报告显示敦煌网需要4秒钟,他立马让我叫来做技术的同事(他要听到一线同学的反应),问这个4秒钟怎么测算出来,是美国人打开用4秒钟,还是英国人打开用4秒钟,用的是甚么Browser等等。这个4秒钟和商业价值(例如交易量)有关系吗?我当时很触动,连这么一个很基础的数据,他都是以求证的心态来分析的。更令我印象深刻的是,只请他当敦煌网顾问半天,按照他的工作经历来说,随便忽悠我半天是很容易的事情,但是韦思康非常严谨,先是以一个普通人的身份花了半个小时在敦煌网买东西(坚决要真实付钱),切身体会敦煌网的用户体验,然后也不先看数据,而是先问很多能更了解敦煌网的生意形态的问题。讲真他的问题比很多投资分析师来得专业。而现在许多数据分析师,包括当时我自己,只看数据就开口说问题,不深入去体会公司的商业形态。韦思康告诉我数据是一种态度,让我明白做数据的人就是要全身心投入,好像一种信仰一样,中间有许多路要走;而且,数据与商业密切相关,不能局限在数据的死角里。

另一位是清华大学的教授谢劲红,有一个夏天碰巧去旁听他的课,拿一堆的数据给他看,他一边看一边给我演绎他的思维,他可以很快在一堆数据找到他们之间的关系。后来我带着团队常常去清华找他聊,他教我如何看网络数据,用联动的思维来看网络数据。可以说是他启蒙了我用 “关系”的思维看数据。一听完就回到敦煌跑到敦煌看很多数据,发现了新世界。

本人常年从事市场产品工作,对数据统计自学过一阵为硕士论文用。就我自己体会讲几点:

  1. 有意义的数据极其有必要,这里的有意义指
    • 精度有意义,精度太高很不必要代价太大精度低了那和没有数据也是一样。
    • 指向有意义,这个就需要丰富的经验来把握,哪里去获得数据?和谁去比较?能说明什么?这一系列问题能把握住才能称为数据指向有意义。
  2. 不赞成先有结论再去用数据求证。提出这中说法的人基本上都是用来凑数据的。稍微了解统计思想的就知道,统计的证明是建立在拒绝基础上的,而不是承认假设。
  3. PM的黄埔军校是快消行业
  4. 在中国的传统里理数被认为是奇技淫巧之类因此是欠缺的,所以中国人的严谨性群体缺失我敢说坚持数据无用论中90%以上是懒得去搞数据,或者看见的垃圾数据太多已经失去对数据的信赖,但我相信一旦一份逻辑严密数据严谨的数据放在你面前你一定无法忽视。
  5. 人的辨别能力是有限的,很多数据工作是为了研展你的辩识能力,比如数据挖掘。一堆杂乱的数据对你是毫无用处的,但通过处理就可能告诉你很多你忽略的信息。因此数据挖掘我认为是PM必须具备的职业技能。

《从数据中挖掘因果关系》

这个题目是很有趣的:数据本身并不说谎,难就难在我们如何从中挖掘出正确的信息。当我们讨论数据时,我们讲的最多的是数据的相关性,而我们希望得到的则是事件之间的因果联系;但事实往往是复杂的,统计数据有相关性并不意味着两个事件具有因果联系,而具有因果联系的两件事从统计数据上看有时也并不相关。

有虚假的相关性数据,就有虚假的独立性数据。“健康工人效应”是一个特别有意思的理论。调查发现,在铀矿工作的工人居然与其它人的寿命一样长(有时甚至更长)。这表明在铀矿工作对身体无害么?当然不是!其实,是因为去铀矿工作的工人都是经过精心挑选的身强体壮的人,他们的寿命本来就该长一些,正是因为去了铀矿工作才把他们的寿命拉低到了平均水平。这一有趣的细节导致了数据的伪独立性。类似地,有数据表明打太极拳的人和不打太极拳的人平均寿命相同。事实上呢,太极拳确实可以强身健体、延长寿命,但打太极拳的人往往是体弱多病的人,这一事实也给统计数据带来了虚假的独立性。现实中的统计数据往往会表现出一些更加诡异复杂的反常现象。

  1. 数据监测:通过测度产品所表现的关键相应指标来评估产品目前的运行状况,并保障产品正常运行,如果有意外,第一时间发现,并分析原因;赘述一句,想象到的就不是意外,预案在此时通常很苍白,因此数据问责很有可能出现,PM也好,RD也好这时要冷静而不是抱怨。
  2. 数据探索:每一个PM都是贪心的,恨不得将所有可能测度到的数据全部让RD实现,这在效率和效果上都是个坏主意。因此,PM需要在让RD把所有数据都跑出来之前,做足探索,哪些数据有效,哪些没什么用,往往PM在处理项目时,评定优先级,而在数据上往往过于急躁。 2需要不断迭代,来完善1数据监测。
  3. 数据假设与数据挖掘:通过数据来推翻而不是论证项目的假设。基于数据获取更多的知识,甚至能够通过数据自学习,形成良性的自我成长。 这3个部分能杀掉PM大量的时间,故形成BI体系,作为团队内部的知识分享平台,至关重要。

Hadoop生态圈(或者泛生态圈)基本上都是为了处理超过单机尺度的数据处理而诞生的。你可以把它比作一个厨房所以需要的各种工具。HDFS(Hadoop Distributed FileSystem)的设计本质上是为了大量的数据能横跨成百上千台机器,但是你看到的是一个文件系统而不是很多文件系统。比如你说我要获取/hdfs/tmp/file1的数据,你引用的是一个文件路径,但是实际的数据存放在很多不同的机器上。你作为用户,不需要知道这些,就好比在单机上你不关心文件分散在什么磁道什么扇区一样。HDFS为你管理这些数据。存的下数据之后,你就开始考虑怎么处理数据。虽然HDFS可以为你整体管理不同机器上的数据,但是这些数据太大了。一台机器读取成T上P的数据(很大的数据哦,比如整个东京热有史以来所有高清电影的大小甚至更大),一台机器慢慢跑也许需要好几天甚至好几周。对于很多公司来说,单机处理是不可忍受的,比如微博要更新24小时热博,它必须在24小时之内跑完这些处理。那么我如果要用很多台机器处理,我就面临了如何分配工作,如果一台机器挂了如何重新启动相应的任务,机器之间如何互相通信交换数据以完成复杂的计算等等。

这就是MapReduce / Tez / Spark的功能。MapReduce是第一代计算引擎,Tez和Spark是第二代。MapReduce的设计,采用了很简化的计算模型,只有Map和Reduce两个计算过程(中间用Shuffle串联),用这个模型,已经可以处理大数据领域很大一部分问题了。那什么是Map什么是Reduce?考虑如果你要统计一个巨大的文本文件存储在类似HDFS上,你想要知道这个文本里各个词的出现频率。你启动了一个MapReduce程序。Map阶段,几百台机器同时读取这个文件的各个部分,分别把各自读到的部分分别统计出词频,产生类似(hello, 12100次),(world,15214次)等等这样的Pair(我这里把Map和Combine放在一起说以便简化);这几百台机器各自都产生了如上的集合,然后又有几百台机器启动Reduce处理。Reducer机器A将从Mapper机器收到所有以A开头的统计结果,机器B将收到B开头的词汇统计结果(当然实际上不会真的以字母开头做依据,而是用函数产生Hash值以避免数据串化。因为类似X开头的词肯定比其他要少得多,而你不希望数据处理各个机器的工作量相差悬殊)。然后这些Reducer将再次汇总,(hello,12100)+(hello,12311)+(hello,345881)= (hello,370292)。每个Reducer都如上处理,你就得到了整个文件的词频结果。这看似是个很简单的模型,但很多算法都可以用这个模型描述了。Map+Reduce的简单模型很黄很暴力,虽然好用,但是很笨重。

第二代的Tez和Spark除了内存Cache之类的新feature,本质上来说,是让Map/Reduce模型更通用,让Map和Reduce之间的界限更模糊,数据交换更灵活,更少的磁盘读写,以便更方便地描述复杂算法,取得更高的吞吐量。有了MapReduce,Tez和Spark之后,程序员发现,MapReduce的程序写起来真麻烦。他们希望简化这个过程。这就好比你有了汇编语言,虽然你几乎什么都能干了,但是你还是觉得繁琐。你希望有个更高层更抽象的语言层来描述算法和数据处理流程。于是就有了Pig和Hive。

Pig是接近脚本方式去描述MapReduce,Hive则用的是SQL。它们把脚本和SQL语言翻译成MapReduce程序,丢给计算引擎去计算,而你就从繁琐的MapReduce程序中解脱出来,用更简单更直观的语言去写程序了。有了Hive之后,人们发现SQL对比Java有巨大的优势。一个是它太容易写了。刚才词频的东西,用SQL描述就只有一两行,MapReduce写起来大约要几十上百行。而更重要的是,非计算机背景的用户终于感受到了爱:我也会写SQL!于是数据分析人员终于从乞求工程师帮忙的窘境解脱出来,工程师也从写奇怪的一次性的处理程序中解脱出来。大家都开心了。Hive逐渐成长成了大数据仓库的核心组件。甚至很多公司的流水线作业集完全是用SQL描述,因为易写易改,一看就懂,容易维护。自从数据分析人员开始用Hive分析数据之后,它们发现,Hive在MapReduce上跑,真鸡巴慢!流水线作业集也许没啥关系,比如24小时更新的推荐,反正24小时内跑完就算了。但是数据分析,人们总是希望能跑更快一些。比如我希望看过去一个小时内多少人在充气娃娃页面驻足,分别停留了多久,对于一个巨型网站海量数据下,这个处理过程也许要花几十分钟甚至很多小时。而这个分析也许只是你万里长征的第一步,你还要看多少人浏览了跳蛋多少人看了拉赫曼尼诺夫的CD,以便跟老板汇报,我们的用户是猥琐男闷骚女更多还是文艺青年/少女更多。你无法忍受等待的折磨,只能跟帅帅的工程师蝈蝈说,快,快,再快一点!

于是Impala,Presto,Drill诞生了(当然还有无数非著名的交互SQL引擎,就不一一列举了)。三个系统的核心理念是,MapReduce引擎太慢,因为它太通用,太强壮,太保守,我们SQL需要更轻量,更激进地获取资源,更专门地对SQL做优化,而且不需要那么多容错性保证(因为系统出错了大不了重新启动任务,如果整个处理时间更短的话,比如几分钟之内)。这些系统让用户更快速地处理SQL任务,牺牲了通用性稳定性等特性。如果说MapReduce是大砍刀,砍啥都不怕,那上面三个就是剔骨刀,灵巧锋利,但是不能搞太大太硬的东西。这些系统,说实话,一直没有达到人们期望的流行度。因为这时候又两个异类被造出来了。他们是Hive on Tez / Spark和SparkSQL。它们的设计理念是,MapReduce慢,但是如果我用新一代通用计算引擎Tez或者Spark来跑SQL,那我就能跑的更快。而且用户不需要维护两套系统。这就好比如果你厨房小,人又懒,对吃的精细程度要求有限,那你可以买个电饭煲,能蒸能煲能烧,省了好多厨具。

上面的介绍,基本就是一个数据仓库的构架了。底层HDFS,上面跑MapReduce/Tez/Spark,在上面跑Hive,Pig。或者HDFS上直接跑Impala,Drill,Presto。这解决了中低速数据处理的要求。那如果我要更高速的处理呢?如果我是一个类似微博的公司,我希望显示不是24小时热博,我想看一个不断变化的热播榜,更新延迟在一分钟之内,上面的手段都将无法胜任。于是又一种计算模型被开发出来,这就是Streaming(流)计算。

Storm是最流行的流计算平台。流计算的思路是,如果要达到更实时的更新,我何不在数据流进来的时候就处理了?比如还是词频统计的例子,我的数据流是一个一个的词,我就让他们一边流过我就一边开始统计了。流计算很牛逼,基本无延迟,但是它的短处是,不灵活,你想要统计的东西必须预先知道,毕竟数据流过就没了,你没算的东西就无法补算了。因此它是个很好的东西,但是无法替代上面数据仓库和批处理系统。还有一个有些独立的模块是KV Store,比如Cassandra,HBase,MongoDB以及很多很多很多很多其他的(多到无法想象)。

所以KV Store就是说,我有一堆键值,我能很快速滴获取与这个Key绑定的数据。比如我用身份证号,能取到你的身份数据。这个动作用MapReduce也能完成,但是很可能要扫描整个数据集。而KV Store专用来处理这个操作,所有存和取都专门为此优化了。从几个P的数据中查找一个身份证号,也许只要零点几秒。这让大数据公司的一些专门操作被大大优化了。比如我网页上有个根据订单号查找订单内容的页面,而整个网站的订单数量无法单机数据库存储,我就会考虑用KV Store来存。KV Store的理念是,基本无法处理复杂的计算,大多没法JOIN,也许没法聚合,没有强一致性保证(不同数据分布在不同机器上,你每次读取也许会读到不同的结果,也无法处理类似银行转账那样的强一致性要求的操作)。

但是丫就是快。极快。每个不同的KV Store设计都有不同取舍,有些更快,有些容量更高,有些可以支持更复杂的操作。必有一款适合你。除此之外,还有一些更特制的系统/组件,比如Mahout是分布式机器学习库,Protobuf是数据交换的编码和库,ZooKeeper是高一致性的分布存取协同系统,等等。有了这么多乱七八糟的工具,都在同一个集群上运转,大家需要互相尊重有序工作。所以另外一个重要组件是,调度系统。现在最流行的是Yarn。你可以把他看作中央管理,好比你妈在厨房监工,哎,你妹妹切菜切完了,你可以把刀拿去杀鸡了。只要大家都服从你妈分配,那大家都能愉快滴烧菜。你可以认为,大数据生态圈就是一个厨房工具生态圈。为了做不同的菜,中国菜,日本菜,法国菜,你需要各种不同的工具。而且客人的需求正在复杂化,你的厨具不断被发明,也没有一个万用的厨具可以处理所有情况,因此它会变的越来越复杂。


Spark 是一种与 Hadoop 相似的开源集群计算环境,但是两者之间还存在一些不同之处,这些有用的不同之处使 Spark 在某些工作负载方面表现得更加优越,换句话说,Spark 启用了内存分布数据集,除了能够提供交互式查询外,它还可以优化迭代工作负载。 Spark 是在 Scala 语言中实现的,它将 Scala 用作其应用程序框架。与 Hadoop 不同,Spark 和 Scala 能够紧密集成,其中的 Scala 可以像操作本地集合对象一样轻松地操作分布式数据集。 尽管创建 Spark 是为了支持分布式数据集上的迭代作业,但是实际上它是对 Hadoop 的补充,可以在 Hadoop 文件系统中并行运行。通过名为Mesos的第三方集群框架可以支持此行为。Spark 由加州大学伯克利分校 AMP 实验室 (Algorithms,Machines,and People Lab) 开发,可用来构建大型的、低延迟的数据分析应用程序。 虽然 Spark 与 Hadoop 有相似之处,但它提供了具有有用差异的一个新的集群计算框架。首先,Spark 是为集群计算中的特定类型的工作负载而设计,即那些在并行操作之间重用工作数据集(比如机器学习算法)的工作负载。为了优化这些类型的工作负载,Spark 引进了内存集群计算的概念,可在内存集群计算中将数据集缓存在内存中,以缩短访问延迟. 在大数据处理方面相信大家对hadoop已经耳熟能详,基于GoogleMap/Reduce来实现的Hadoop为开发者提供了map、reduce原语,使并行批处理程序变得非常地简单和优美。Spark提供的数据集操作类型有很多种,不像Hadoop只提供了Map和Reduce两种操作。比如map,filter, flatMap,sample, groupByKey, reduceByKey, union,join, cogroup,mapValues, sort,partionBy等多种操作类型,他们把这些操作称为Transformations。同时还提供Count,collect, reduce, lookup, save等多种actions。这些多种多样的数据集操作类型,给上层应用者提供了方便。各个处理节点之间的通信模型不再像Hadoop那样就是唯一的Data Shuffle一种模式。用户可以命名,物化,控制中间结果的分区。————————————————python 及其它Python和hadoop没啥关系,做数据分析时可以和R语言类比,实现streaming时可以和php ruby perl shell awk类比。Bigtable来自谷歌,对应hadoop里的HBaseGFS来自谷歌,对应hadoop里的HDFS……所以你看,搞懂hadoop是多么重要


而对于自身产品和竞对产品维度的求证,不二法宝就是细分,下面介绍一些常见的细分维度及其案例。

  • 分步:假设某产品的转化率数据出现降低的情况,而这个转化率是多步漏斗转化的最终转化,我们可以细分每一步的转化情况,查清是否因为某一步出了问题。比如微信支付服务器的故障会造成下单到支付的转化降低从而造成转化率降低,列表加载速度增加造成列表到详情转化率降低影响整体转化等等。
  • 分平台/版本:假设某产品列表页到详情页的转化提升,我们猜测是iOS新版本中优化列表布局方式,我们需要分iOS和Android以及分iOS新版老版对比这个转化数据来证明我们的猜测。
  • 分区域/城市:假设某年8月31日某OTA的交易额呈现大幅增长,我们猜测是因为大学生开学造成酒店需求增加,这时我们可以选取部分高校较多的城市如北京、武汉、西安等城市的数据来对比其他城市来侧面验证我们的猜测。
  • 分时间:假设某日某产品转化率数据下降,我们猜测是10:00-11:00支付服务器故障造成的,那我们只需要分时间段和上一个波动周期同期的数据对比,如果当日这个时间段转化率确实下降很大,就可以证明我们的猜想。
  • 分用户群体:假设某App新版上线之后新版转化率低于旧版,经过用户分析发现新版新用户比例较大,我们猜测新用户转化率会比老用户转化率低,这个时候我们只需要看一下新老客户的转化率区别就能知道我们是否蒙对了。
  • 分场景(本/异地):假设某App在某假期内转化率降低,已知异地用户转化率低于本地用户转化率,猜测假期转化率降低是因为异地用户较活跃造成的,这个时候,我们只要需要去看看本异地用户占比的变化就可以验证猜测了。
  • 分Item:假设某OTA转化率在某段时间内明显提升,而这个时间段恰好是竞对较少补贴促销活动的时间,我们猜测是竞对促销活动终止对产品转化率造成了正面影响,如果我们查看数据证实那些被竞对取消促销的Item转化率提升明显,那说明我们的猜测是对的。

传统互联网对产品的数据分析,核心围绕着“用户”,例如从用户质量分为:狂热用户、核心用户、一般用户及边缘用户;从运营角度分为:活跃用户、留存用户、流失用户、回归用户等,移动互联网也不例外。

然而,移动互联网由于“碎片化”等原因,虽然你已经明确是哪一个用户,如果没有场景支撑,用户也不会来的。例如:我如果最近不看电影,我不会去美团;我在公交车站等30分钟,公交车还没有来,我可能会打开“公交大师”查询公交情况。

所以根据我个人的看法,“用户”的指标体系发展多年应该是相当完备了,但“场景”的指标体系还不太完善,至少我还在学习及摸索中,我的初步解决思路就是尽量在产品中体现“场景元素”,这样便于统计。例如:我会让用户做选择商品内容的时候,能接近场景选择核心内容。


  1. 起床之后,回回信息、刷刷朋友圈,这时候用户大都可能不喜欢深度、烧脑的文章,反而一些新闻、轻松娱乐的文章资讯能够带来清晨好心情。
  2. 上班途中,也不适合深度阅读,大多看看娱乐轻松的,或者小说,或者玩个休闲游戏。在这里,“不紧迫、碎片化"非常关键。由于接下来到达公司后要吃早餐并微信支付,所以类似美团外卖、饿了么早餐或者其他的O2O应用,可以抢注这个时间段,投放一些美味信息和打折促销。
  3. 9点之后用户进入工作状态,切莫此时去骚扰,也不要做朋友圈的诱导转发之类的营销曝光,那是无用功。但是如果有相应的PC端产品的话,此时倒可以考虑点儿po出提升办公效率、舒适度方面的产品简介,但要图文并茂、简洁轻松。
  4. 午休时段,切勿打扰或者无效营销。我就在这个时段因为某些app推送信息,惹得我直接卸载。而且此时段电话我的非熟人号码,一律标成“骚扰”、“诈骗中奖”。此处引用《天下无贼》里面那句经典台词——“黎叔很生气,后果很严重”——简直太贴切了。
  5. 咱们国人最认真工作的时段就是下午2点~5点了。一切烧脑、耗时、高强度的工作,估摸着都在这段时间内了。诸君要是想在此时段内作何营销推广,我也就不多点评了,智者自悟。
  6. 晚上8~11点,为全民“网络high”时段。根据我的亲身体验,也是众多公众号密集推送文章资讯的时段,以及各种转载、集赞、诱导转发的粉墨舞台。诚然,这是信息曝光的“黄金时段”。但是,海量信息竞争,博取用户眼球,这里面也是个红海血腥的拼杀场。如何胜出?技术层面不妨考虑点儿博弈论(此处笔者也是点到即止,有缘者自悟)。

至于去年高峰出现在22:30,而今年为何提前了半小时?这个问题可能简单,也可能很不简单。笔者对此有如下几个方面的猜测:

  1. 随着微信向二、三线城市的渗透,更多新用户加入,他们是社交app的后进者(说句实话这时候才加入微信,不是奥特曼是啥?)。通常这些用户不是互联网行业的,而大多数传统行业、公务员、中老年人,都习惯早睡早起,按时作息,所以他们的加入可能导致大盘的活跃时间提前,相应的睡眠时间也提前。
  2. 经济大环境相比去年更加不景气,人们失业的多了,加班的少了,即使加班可能也没啥紧迫正事儿,于是就玩呗,嗨起来的时间比去年更早点儿了。
  3. 最近两年,互联网和金融行业频频爆出青壮年leader或从业者猝死的新闻,使得人们更加注重健康作息了?

这里可能存在一个悖论。其一是用户更早进入活跃态,说明微信的黏度提高了;其二用户活跃巅峰提前,沉寂也提前的话,也可能是某些其他app或产品或电视节目,覆盖了晚10点到凌晨这个时段。前者是利好,后者是利空。还有一方面值得提的就是,今年好看的电视剧以及网民追剧的现象貌似比去年火热一些,毕竟范冰冰的《武媚娘》、赵丽颖的《花千骨》和胡歌的《琅琊榜》等,都是朋友圈热点话题。用户追剧的同时,拨弄一下微信是常事。若是大量用户集体追剧,而电视剧的播出时间通常是晚8~10点,所以高峰期提前也解释得通。

其次,阅兵节的高峰也比较明显,毕竟今年的反法西斯胜利70周年大阅兵,首次多个外国军队一起参与阅兵,还来了俄罗斯、韩国总统等大腕,而且中国展示了诸多新式武器,着实让国人们振奋了一把。

此外,值得提醒注意的是,国庆和五一的相对低迷,有可能还受到“数据稀疏”问题的影响。说白了就是数据此时存在片面性。因为如果是大量用户外出旅游,很少有人时常发微信的,从而采集到的用户数据偏少,且不一定真实反映用户当时的心情。数据稀疏性和片面性,是数据分析中要特别注意的核心问题。如果不慎,很可能得出错误的结论。

其实,情绪high时是商机,情绪down时也是商机。在商学上有种叫做“焦虑性消费”的说法。想起前两天看了部“无脑高颜值”电影(不想透露名字,免得为烂片做宣传了,而且笔者也没看完,实在看不下去……),里面的女主角就说了句——“女人失恋时最好的良药就是疯狂shopping”。这某种意义上反映的也是焦虑性消费。

虽然互联网圈子的从业者大多是6点晚饭,6:30~7:30之间散步,但是毕竟互联网圈子人口总量相比全国人民还是少数,所以大盘反映出来的民众生活规律是晚8点~9点之间运动高峰。

但是这里可能有个容易误导的地方:并非所有用户晚8~9点都会散步或运动,而是对于全体用户在24小时内的运动量来看,相对而言晚8~9点是峰值。也就是说,很可能大多数的用户8~9点仍是宅在家里、公司里或外面的餐厅等娱乐场所。具体怎样,需要进一步的数据了,但是此份报告中未提及。

对于那些习惯8~9点散步运动的人们,如果在此期间进行公众号文章推送,想必是不太多用户活跃阅读,也不会活跃地在朋友圈转发。尤其是那些focus在运动健康方面的公众号,应该在自己的目标用户开始运动之前,或者运动完毕之后,推送相关的信息。这样的转化率才高,用户心理体验也才最佳。

尤其还有众多做运动方面智能硬件的朋友们,更应该注意了,别再在错误的时间对正确的人干错误的事情……


有没有可能根据用户个人的习惯进行定制化推送,在正确的事件,做正确的事情