请点击此处给我们留言

地址:环亚app下载

电话:

联系人:环亚娱乐ag88登录总经理

当前位置:主页 > 产品案例 >

数据产品经理:6大数据分析平台的“世界观”环亚娱乐ag88旗舰

来源:http://www.sznbo.com 责任编辑:环亚娱乐ag88登录 更新日期:2018-11-19 07:58 字体:
分享到:

  本文从一个不太常见有十分重要的角度切入——数据模型,也就是讲解一些知名的数据分析平台究竟收集了哪些数据,以及为什么要收集它们。将这类内容成为:数据分析平台的世界观。

  GrowingIO、神策、诸葛IO、TalkingData、友盟、Google Analytics for Firebase是数据分析领域广为人知的几家综合性平台,他们在用户行为研究与驱动业务增长等多个方面,都提供了丰富的分析工具和技术支持,成为许多知名企业的数据平台首选。

  另一个特点是,我们都将移动场景下的用户行为分析作为重点之一,而非Web时代的行为分析(这也是Google Analytics for Firebase入选了,而没有选择Google Analytics 360的原因)。

  在数据分析领域,“巧妇难为无米之炊”这句古话常被提起,用来比喻没有高质量的数据,就无法进行高质量的分析、得出高质量的结论。而这6家平台与单纯的数据可视化平台相比,其服务都覆盖了数据采集的部分,也就是从源头开始支撑整个数据分析。

  因此,这个系列就从一个不太常见有十分重要的角度切入——数据模型,也就是讲解一些知名的数据分析平台究竟收集了哪些数据,以及为什么要收集它们。我将这类内容成为:数据分析平台的世界观。

  至于数据分析“出彩”部分,各家也都有自己的侧重点——有偏重用户行为与画像的、有偏重广告与商业变现的、也有偏重营销工具的,各不相同。那么废话不多说,加下来我们就来探讨这几个数据平台的“世界观”。

  如果你对其他平台感兴趣,也欢迎在评论里告诉我,它会加入我的to-do list。

  这是一个根本性的问题,直接决定了后续的所有内容。就像咱们中国古人,认为世界的基本就是阴和阳而已。阴阳的组合与生化,产生了世界万物。对于数据分析平台来说,也会有一些构成世界的基本元素。这些元素之间相互影响、相互作用,演化出了千变万化的数据分析。

  首先,要对GrowingIO、神策和诸葛IO这三位同学加粗标红地提出表扬!!!

  是因为他们仨都很贴心地在文档中提供了一个叫做“数据模型”的部分,极大的减少了爬API文档了解逻辑的时间。文档地址如下:

  另外三家就提供的比较隐晦了,不过多多少少还是能找到相关信息的——这6家平台都采用了“事件模型”来收集数据。(部分数据是自动收集的,没有特别明确的数据模型,后边会详细列举。)

  在这几家平台看来,这个世界就是一大堆错综复杂“事件”(Event)而已。用户是事件的施动者,而每个事件有自己的一些独有的信息。用一句话概括:有人搞了一些事情,我们来分析一下吧。

  其中事件和用户,我们可以称之为两个“实体”(Entity)。他们之间的关系可以用E-R表示为:

  对于事件模型,理解事件(Event)这个概念当然是最重要的。那么什么叫一个事件呢?

  那些在数据分析中耳熟能详的用户行为,都可以叫做一个事件。比如,启动App、注册、登陆、浏览、转化(创建订单、完成支付、发布内容等)、留存、分享、订阅、收藏等等。

  当然,这就存在一个问题了——不同的业务形态,会产生不同的用户行为。有的关注交易,有的关注UGC内容,有的则只是看用户的点点划划。那么对于这几家第三方平台来说,如何给出一套模型能覆盖所有事件呢?

  其实每家平台会把这些事件分为两类:那些已经确定的、不管什么业务类型都会需要的事件,当做了“预留事件”(每家的叫法略有差别,比如:在TalkingData指的就是“灵动分析”部分的数据)。比如:打开App、注册、登陆、浏览(PV/UV)等。也就是说,只要接入了这个平台(并将SDK进行了正确的初始化),就可以收集到这些事件的数据,进行监控和分析。

  另一类,就是“自定义事件”(同样每家的叫法略有差别)。这一类涵盖的就是与不同的业务类型高度相关的那些事件了,比如:单纯的UGC内容平台,就没有订单和支付这些事件;而对于纯粹的电商平台,其关注的核心也不会是超大篇幅的内容产出。这些就应当作为自定义事件。

  其中自定义事件是需要在收集之前,先在平台上“注册”这些事件的,这也是为了方便对事件进行管理。

  但不管是预留事件还是自定义事件,都保留了基本的事件数据结构,一个事件主要包含四部分信息,称作事件的属性(E-R图中与事件连线的椭圆形):

  这部分主要是为了关联事情的发动者是谁,以便支持后续从用户角度开展的分析;

  这也是每个事件的一个基本属性,比如:App启动是一个类型,用户登陆也是一个类型。

  这部分的定义比较宽泛,所以也留了较大的自由度。比如:我们前面讲到的两个例子,如果是创建订单的事件,则会包括订单号、订单金额、商品编号等等;如果是UGC类型的事件,则可能包括内容发布的板块、是否原创、引用链接等等。

  至此,我们可以简单的理解,所谓“事件”,其实可以就按表面意思理解,就是发生了一些事的概念。而后续在进行分析的时候,就得根据分析的需要,重新整理事件的数据。

  用户模型是第二大概念,51case(无忧案例网):以案...也是最爱分析的第二大主体。上一段说到在数据收集之后,进行分析的时候,需要重新对数据进行整理,面向用户的数据汇总就是主要方式之一。通过这样的汇总,我们得到的是用户画像、用户偏好等这些初步的结论,再进行深入分析。

  所谓登录用户,就是已经注册并取得了注册账号的用户,比如:我们注册了QQ就有QQ号,注册了淘宝有淘宝账号等等。对于这样的用户,正因为他们已经有了一个几乎不可能改变的账号,之后所有的行为和属性信息,都会尽可能地与这个不变的账号关联起来。

  这引出一个题外话——账户体系的重要性。在互联网社交刚崛起的阶段,有很多平台致力于做统一账户。关键在于这个跨平台的账户ID关联了用户的所有行为,这种方式对于渴望降低CAC、环亚娱乐ag88旗舰,实现交叉引流的平台有很大帮助。

  但对于那些大平台,就是流量的“净输出”方,而且那些初期需要引流的平台,一定是把第三方账号关联到自己的账户体系上,这就凸显了同一账号的信息中介作用。在大厂开始外推自己的账户体系、信息逐渐开始“对称”起来的时候,统一账号就没有存在空间了。

  说到用户注册和登录,这就产生了另一个问题:当用户没有登陆,甚至还未注册,那怎么办呢?

  问题就在这——我们不知道TA是谁,TA没有登陆,我们已经掌握的历史数据却都是与注册账号相关的。也就是说,这些数据都无法跟这个访问用户对应上。

  历史数据关联问题,特别是与业务有关的数据(比如:订单),一般都是与注册账号ID关联的,而这个访问用户的ID很不稳定,会频繁变动。

  访问用户ID的产生依赖于平台。也就是说,用户使用同一家的App,在没登录的情况下,在iOS、Android和其他平台上上会被当做是两个人,这对于数据分析显然是个灾难。

  这就好像,我们用身份证买了一张机票,如果你不出示身份证,人家自然不会给你办理手续,即使用护照或者其他证件也不行。(惨痛的真实经历…)

  当然,在互联网的领域中从不会“坐以待毙”。对于这样的“无名氏”用户,许多平台已经开始支持记录和管理历史访问设备,也就是你用的手机、平板电脑等设备有自己的ID(比如网卡的MAC地址)。如果某位访问用户使用同一部手机打开了App,我们也可以通过手机的设备号近似的关联到登录用户身上。

  这种从设备到人的映射关系,有些是在账号体系中“强管理”的——关联设备数量有限制,而且需要明确授权。比如:Apple ID。也有“弱管理”的,只是在App中展示一下。更低效的做法,是把关联的工作放到数据分析阶段,再耗费大量计算资源做这个层次的关联。

  用户也会有自己的属性,这些是人们喜闻乐见,喜欢分析的内容。对于一位用户,属性包括以下两种:

  上边还剩一个“端”的实体,但是其自身的分析价值更偏向技术层面,我们暂时忽略。

  分析这部分可能是整篇文章比较吸引人的地方,但其实,说完了前面几方面的内容,才可以开始将分析。这个时候,能分析什么、怎么分析这类问题,才能落到具体的东西上。

  图中的实体(用矩形表示)和实体关系(用连线表示)概括了我们要分析的内容。这张图里有三个主体:端、用户和事件。这也就意味着,我们的分析过程有三个切入点:产品(内容)自身、用户自身以及用户行为。

  当然,我们最常分析的,还是产品与用户关系,以及用户自身的行为这两个大主题。而这两个行为的数据,主要来源于“用户触发事件”这个过程。(下边那些就不是正统的E-R图了哈,能传达含义就行。)

  要做的基本就是指定一些属性的值,然后对实体进行计数。比如:我们要求用户的性别=男性,然后对满足要求的实体计数。再或者,我们要求事件类型=新增,然后统计事件实体的数量,算出来的就是今日的新增用户数DNU(隐含一个去重的过程)。

  另一类统计分析是分析用户的行为路径,比如:用户从打开App,到最终支付成功,经理的怎样的路径呢?

  归因分析需要给发生的事情找到原因,一般的最终目的是通过这种挖掘出来的因果关系,对未来进行预测。比如:如果我们发现了女性用户更可能购买我们的产品,那么在资源有限的情况下,我们就应当着重向平台上的女性用户推广我们的产品。

  另一类例子,就是关于事件和事件之间的,比如经典的“LinkedIn 魔法数字”案例——1周内增加5个社交好友的用户更容易留存。

  而对于第二类行为之间的归因分析,使用过行为之间的交叉来过滤用户,最终仍旧是通过统计用户数量来得出结论的:

  如果你经手过大数据量,可能已经想到了,这样的事件统计计算量会非常非常大!在实战中,更多情况是将这种行为的数量当做用户的一种属性,这也就是前面提到的第二类用户属性。

  但不管哪种分析,都会面临一个问题——用户属性很不稳定,会改变的。比如:用户的年龄段。在用户第一次加好友的时候,其年龄段属性为“21-25岁”,线岁,正处在年龄段交替的时间点;当再次加好友的时候,线岁,其年龄段属性也随之变成了“26-30岁”。

  这就产生问题了:当用户完成了5次社交好友之后,这5次的社交好友应当归因到“21-25岁”呢?还是归因到“26-30岁”年龄段呢?

  类似的问题也出现在一些其他分析上,比如:用户的浏览行为。当用户启动App之后,可能在所有内容之间穿梭很久,最终才决定购买或者其他转化。

  为了避免这种问题,有些平台(如:GrowingIO)在配置自定义事件时提供了明显的配置项(称为“埋点事件”的“归因方式”);也有的平台讲这件事的决定权交给了使用者,湖南省人民政府办公厅关于下达2006年企业基本养老保险费征收目标可以在代码或者事件定义的过程中给出;更有如Google Analytics for Firebase这样的平台,会提供一套专门的“归因模型”,来处理这类转化归因的问题。

  关于归因的问题会单独整理一部分内容。这部分整理还会衍生出一些其它的思考,比如:你的业务增长,真的应该归因给社群裂变吗?