⼤数据是如何产生的?大数据的特点是什么?什么是埋点?如何进行数据埋点?【超详细介绍】

大家早上好,本人姓吴,如果觉得文章写得还行的话也可以叫我吴老师。欢迎大家跟我一起走进数据分析的世界,一起学习!

感兴趣的朋友可以关注我或者我的数据分析专栏,里面有许多优质的文章跟大家分享哦。


⼤数据是如何产⽣的?

我们都知道,EXCEL一个工作表可以存储104w条记录,那在这样的数据级下处理起来是非常慢的。MySQL一次可以存储4000多万条记录,同样也是数据越多,处理越慢。那与MySQL并行存在的ORACLE和SQL Server存储处理能力也是千万级别的。

但是,随着互联网的发展,万物互联的实现,大数据的到来是必然趋势。海量数据的产生,EXCEL和MySQL的存储和处理能力就显得无能为力了。

大数据来源

典型的数据分析系统,要分析的数据种类⽐较丰富,依据来源⼤体可以分为以下⼏部分:
在这里插入图片描述

  • 内部数据也就是公司的产品产生的数据。

  • 前端数据指的是用户在网站等上的浏览点击等行为的数据,可通过JS(PC网站,或者是H5也就是通过http协议与服务器进行交互的)和埋点获取(小程序、APP等)。

  • 后端数据主要是业务系统产生的数据,比如订单数据。可通过接口或日志形式获取。

  • 外部数据包含行业数据以及竞品公司数据,可采用爬虫及搜索引擎的方式来获取。

总之,数据来源越丰富,所开展的数据分析工作也就越全面越具体。接下来我们针对不同的数据来源来具体地了解一下收集方式。

内部数据

首先看看数据分析师经常参与的埋点数据工作。
在这里插入图片描述

如何进⾏埋点?

  • 埋点原理
    对基于⽤户⾏为的数据平台来说,发⽣在⽤户界⾯的,能获取⽤户信息的触点就是⽤户数据的直接来源,⽽建⽴这些触点的⽅式就是埋点。当这些触点获取到⽤户⾏为、身份数据后,会通过⽹络传输到服务器端进⾏后续的处理。
  • 埋点分类
    埋点从准确性⻆度考虑,分为客户端埋点和服务端埋点。客户端埋点,即客户操作界⾯中,在客户产⽣动作时对⽤户⾏为进⾏记录,这些⾏为只会在客户端发⽣,不会传输到服务器端;⽽服务端埋点则通常是在程序和数据库交互的界⾯进⾏埋点,这时的埋点会更准确地记录数据的改变,同时也会减⼩由于⽹络传输等原因⽽带来的不确定性⻛险。

不同埋点方式对比

在这里插入图片描述
客户端埋点有3种方式:代码埋点、全埋点(无埋点)和可视化埋点。

我们能够监测到网站APP上的用户行为,是必需要在网站的每一页或者APP上加一段代码,那在网站上这段代码就叫监测代码,在APP中就叫SDK代码。

毫无例外,也可以叫它基础代码(基础的采集数据代码)。

在收集数据时,总有一些特殊的用户操作行为是不能靠基础代码收集的,最典型的就是被称为事件的这一类。对于什么是事件,在网页上是那些非http类型的交互,例如Flash、各种页面插件的交互等等;在APP上则包含用户点击在内的所有交互。
可以直接理解一个规律,那就是凡是遵循http协议的交互,也就是这些普通的网页链接,都可以由基础代码来监测到用户行为数据。

每一个需要我们监测的事件的互动都被称为一个监测点。那么web上的监测点应该不多,因为大部分的网页都遵循着http协议,而APP上则布满上监测点,为了让这些监测点上的用户互动行为数据被我们收集,我们必须在每一个监测点上部署专用的事件监测代码,这些代码需要手工一个个添加在需要获取数据的监测点上,这个过程就叫代码埋点

总结起来,代码埋点就是在全埋点,也就是无埋点的基础上进行的,因为全埋点只需要放入基础代码就可以了,而代码埋点则需要在基础代码的基础上还要添加事件代码。

显而易见,它的优点就是可以根据自身业务需求,比较方便地设置自定义属性、自定义事件,传递更丰富的数据到服务器。归结一句话,就是采集业务信息更完整了,对分析数据也就更聚焦了。
缺点是每次上线新的埋点或者更新原有埋点的时候,都会发布新的版本,但是难免会有人不更新版本,所以就对数据指标造成影响,有些数据就收集不到。同时,统计代码的引用对性能也有影响,开发人员的工作量也比较大一点。

再来看可视化埋点。由于代码埋点是在全埋点的基础上增加了事件监测代码,增加了开发人员的工作量,所以就提出了一个需求:有没有一种方式可以进行圈选式的定义事件,这样运营人员和开发人员就可以自行地进行埋点了。所以就有了可视化埋点,它是在嵌入基础代码的基础上通过可视化圈选的形式来定义事件的,所以与代码埋点相比,开发人员的工作量变小了,业务人员的工作量变大了,但总体变得简单了。

服务端埋点主要进行接口调用和数据结构化。那与前端的代码埋点进行比较,更灵活更准确,数据上传更及时,但是缺点就是缺少了一些前端数据例如一些环境信息等。

所以,大部分公司都是由数据产品经理或者是业务线的数据分析师来结合版本迭代过程进行埋点,如果是代码埋点还需要开发人员。

埋点采集工作流程

在这里插入图片描述
其中需求评审主要是为了技术研发人员、数据产品经理、业务方等对埋点需求的理解是一致的,避免各类人员在面对不确定的需求的时候按照自己的理解来进行埋点,会导致上线之后获取的数据和需求不一致。

埋点测试:这是保证埋点质量的关键一环。通常应该从以下几个方面来进行。

  1. 所有监测点是否监测到;
  2. 点击位以及相关事件位的参数是否正常加入埋点,也就是收集的数据是否够全面;
  3. 收集到的数据是否正常上报到服务端。

埋点数据采集维度

我们都是采集用户行为数据的,也就是什么用户在什么时间什么地点发生了什么行为,所以我们就从4W1H来看。
在这里插入图片描述

埋点的目的是为了收集数据,数据的价值在于驱动业务。所以不同的业务需求的埋点方式以及上报的信息都是有所差异的,而同一产品的埋点数量又是非常的多,为了区分整理应用这些埋点数据,就需要整理埋点文档,记录好相关的埋点信息。

埋点⽂档输出

⽂档必备要素包含以下⽅⾯:

要素备注
事件名称埋点的事件名称,如优惠卷领取/优惠卷使⽤
事件定义⽤户点击领取优惠卷,则上报该事件
包含属性⽤户进⾏了该⾏为,上报事件中需要传输那些内容,如⽤户ID、时间、应⽤版本、⽹络环境、⼿机型号、IP、内容ID等;如某些属性在所有事件中都需要上传,则可以整理公共属性进⾏管理;
属性定义说明属性的定义,如⽤户地址: ⽤⽤户主动上传的地址,如没有则⽤⽤户IP代替
属性值类型说明传输属性的类型,字符串、数值、bool
开发名称对应的开发变量名,可以由开发进⾏补充。如userID、contentID;
当前状态明当前该变量的状态。如待开发、开发中、验收中、已上线、已下线
上线版本说明该内容在那个版本进⾏上线。如2.3.1
备注备注中可记录该属性的变动情况和常⻅值等内容。

案例

在整个埋点⼯作流程中,埋点设计环节是最关键的⼀环,在这个环节整体可以根据需求梳理和转化的路径,分为业务分解、分析指标、事件设计、属性设计的四个阶段。其中,业务分解和分析指标,是事件设计和属性设计的关键信息输⼊,通过对业务场景和分析需求的梳理,确认埋点的内容和范围, ⽽事件和属性设计,则是将这些业务分析诉求,转换成⾯向幵发的需求语⾔,让开发能看懂需要他在什么场景和规则下采集哪些数据。接下来,我们以优惠券营销场景为案例,讲述该如何进⾏埋点设计。
在这里插入图片描述
埋点采集中常⻅事件属性的类型举例,主要包含⽤户属性、事件属性、对象属性和环境属性四⼤类。
在这里插入图片描述

外部数据

  • 竞争对⼿数据——爬取数据
    电⼦商务⾏业最初对爬⾍的需求来源于⽐价(现在比价可以用⽣意参谋,⽣e经)。
    爬取方法:除自行实现代码外,也可以用⽕⻋头,⼋⽖⻥,后羿等爬⾍软件。

  • 行业数据——国家统计局
    行业数据可以由国家统计局提供。

  • 友商提供。

⼤数据特点

以阿里对于大数据的定义为参考。
在这里插入图片描述

结束语

一直在学习路上!


推荐关注的专栏

👨‍👩‍👦‍👦 机器学习:分享机器学习理论基础和常用模型讲解
👨‍👩‍👦‍👦 数据分析:分享数据分析实战项目和常用技能整理


关注我,了解更多相关知识!

CSDN@报告,今天也有好好学习

  • 22
    点赞
  • 69
    收藏
    觉得还不错? 一键收藏
  • 打赏
    打赏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

报告,今天也有好好学习

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值