精华内容
下载资源
问答
  • 来源:电商用户行为埋点数据,包括:1.事件类型:install安装|launch启动|interactive交 互|page_enter_h5页面曝光|page_enter_native页面进入|exit退出等。2.行为类型:click点击|view浏览|slide滑动|input输入
  • 作为数据分析师的你,是否和我一样经常会被业务方拿着两个不同数据平台的报表数据进行灵魂拷问。下面的场景你应该在熟悉不过了。情景1一场拉新促活的活动之后,运营拿着两个不同团队维护的报表数据来...

    作为数据分析师的你,是否和我一样经常会被业务方拿着两个不同数据平台的报表数据进行灵魂拷问。下面的场景你应该在熟悉不过了。

    情景1

    一场拉新促活的活动之后,运营拿着两个不同团队维护的报表数据来问我,为什么两份报表统计出来的日活跃用户(DAU)数量不一致?

    我解释道,“你确定两份报表的统计口径是一致的吗,最小的统计维度是一致的吗?”

    运营说,“都是一样的啊,统计的都是DAU。”

    我说,“DAUaccount_id为最小维度进行统计或者以device_id或者以open_id为最小维度进行统计的结果都会有一定的差距。我们这边是以account_id为最小单位统计的DAU。而且,即使统计口径一致,埋点和上报方法也有区别。”

    后来,我向另外一个数据平台的相关人员咨询之后,发现他们统计DAU的最小单位是open_id,不同的统计口径会造成一定的数据差异。而统计口径的差异不止出现在报表统计阶段,在数据埋点阶段也会出现口径不一致的问题,触发事件的条件、数据埋点的方式、数据上报的方式不同都会造成数据不一致的情况出现。

    为了避免这些问题,小编把自己踩过的坑总结出来并形成一套方法论,希望初学的你或即将转行的你能够少采坑,高效地完成数据埋点工作!

     

    01

    数据埋点流程

     

    数据埋点是数据治理流程中重要的一环,是一项多部门协作共同完成的工作,数据分析师在这个流程当中承担着重要的角色。我们将数据埋点流程梳理为下图,数据分析师从数据需求评估阶段直至数据应用阶段都会参与流程,可谓是埋点工作的中流砥柱。

     

    在数据埋点这项工作中,数据分析师需要立足于当前的数据需求,提炼出数据指标方案,并且构思要看这些指标需要有哪些数据,这些数据也就是需要埋的点。当然,这只是一些初步的埋点方案,想要让埋点指标变得“准”而“全”当然还需要另外一些方法实现,比如用户路径之类的。有了初步的埋点规划之后,分析师还需要确定时间触发机制和上报机制,因为不同的机制意味着不同的统计口径。对于新业务来说,为了避免统计口径不一致而出现乌龙事件,最好能和之前的口径一致,以方便横向比较。除此之外呢,统一各个项目之间的字段命名和表结构也是一项必不可少的工作,这个步骤也是数据治理流程当中必不可少环节。完成这些步骤之后,一份初步的埋点就差不多完成了。在和需求方以及程序的反复讨论中修改完善埋点文档,将埋点文档交付程序进行埋点,在此期间分析师需要通过测试环境的数据验证当前埋点是否存在一定的问题,若有问题还可以在该阶段进行修改,若无问题可上线埋点事件。

     

    02

    六个步骤实现数据埋点设计

     

    数据埋点设计师数据分析师是埋点的重中之重,埋点设计得好能够极大地方便后续的数据应用。对于数据埋点设计,我们也总结了六个关键步骤。

     

    1.确认事件与变量

    这里的事件指产品中的功能或者用户的操作,而变量指描述事件的属性或者关键指标。确认事件与变量可以通过AARRR模型或者UJM模型进行逐步拆解,理清用户生命周期和行为路径,抽象出每一个步骤的关键指标。

     

    TipsAARRR模型和UJM模型会在之前的文章中有讲过,点击阅读原文即可跳转。

     

     

    2.明确事件的触发时机

     不同的触发时机代表不同的计算口径,因此触发时机是影响数据准确的重要因素。以用户付款为例,是以用户点击付款界面作为触发条件,还是以付款成功作为触发条件进行埋点呢?二者口径不同,数据肯定会有一定差异,因此明确事件触发条件非常重要。

    而在用户付款这个例子中,我们建议使用两个字段记录用户付款行为,一个字段记录点击付款界面这个行为,另一个字段记录是否付款成功。

     

     

    3.明确事件的上报机制

    不同的上报机制也是数据准确性的重要影响因素之一,客户端上报数据可能会由于网络原因出现丢包的情况,前面章节已经详细介绍过,这里就不在赘述上报机制之间的异同。而作为数据分析师,在完成埋点工作的时候也需要确定数据是实时上报还是异步上报,以确定埋点是否合理,并及时调整数据埋点方案。

     

     

     

    4.设计数据表结构

    统一的数据表结构,方便团队内部进行数据的管理和复用,建议团队内部形成一套统一的数据结构规范。例如,将表分为不同的层级,第一层记录用户的基础信息,包括id,地区,昵称等;第二层记录玩家行为信息。

     

     

    5.统一字段命名规范

    有了统一的数据表结构档案还是不够的,统一数据命名规范数据埋点工作的重要一环。确保同一变量在所有的数据表当中都用统一的字段,比如消费金额这个字段,我们希望所有的表只要出现消费金额都用Amount字段,不要出现money,pay等其他字段。

    建立公司内部或者团队内部的命名规范是非常必要的,可以采用「动词+名词」或者「名词+动词」的规则来命名,比如「加入购物车」事件,就可以命名为:addToCart。

     

     

    6.明确优先级

    数据埋点都是为数据应用做铺排,埋点之后分析师可能面临着搭建指标体系和数据报表体系的工作,可以根据报表的优先级、埋点的技术实现成本以及资源有限性为数据埋点确定优先级。

     

    03

    以电商购物成交转化为例实现数据埋点设计

     

    1)通过UJM模型拆分用户购买商品的路径:将用户购买路径拆解为注册-登录-商品曝光-商品点击-浏览页面详情-加入购物车-生成订单-订单支付步骤,根据产品或策划提的数据需求,确定每一个步骤学要看哪些字段才能实现数据需求。

    2)确认触发机制:明确是在点击按钮时记录行为还是在用户完成该步骤时记录行为。

    3)确认上报机制:明确数据上报机制,是实时上报还是异步上报,不同的上报机制采集到的字段可能不一样,或者说需要将字段拆分到不同表进行记录。

    4)统一字段名:业务内同一变量在所有的数据表当中都用统一的字段,例如,用户编号用account_id,用户所属国家用region,用户所属地区用ip_region等等。

    5)统一表层级结构:我们这里采用两层数据表结构,第一层存放用户基信息,第二层存放用户行为信息。这个根据团队内部的数据接入规范进行调整,只要是统一的结构,对于数据分析师的分析都是有利的。

    6)明确数据优先级:根据埋点需求的紧急程度,给每一个买埋点任务标上优先级。

     

     

    根据上面的六个步骤,将每一个步骤需要记录的字段按照标准格式汇总到文档,即可完成初步的埋点设计。当然完成初版埋点设计之后,还需要与产品、策划、程序一遍一遍过文档内容,不断修改完善,直至三方会谈达成统一意见。

     

     

    参考链接

    http://www.woshipm.com/pd/3070837.html

    https://mp.weixin.qq.com/s?__biz=MzI2MTAxOTk5OQ==&mid=2650945421&idx=1&sn=b16a4fbe3b535b91b21baa8a2855aa8b&chksm=f19657bdc6e1deab3568d0020033a58ffeea90806eff483d9e8d8d32f3115e9160db0a72f68b&scene=21#wechat_redirect

    https://www.cnblogs.com/flzs/p/13815329.html

    更多精彩回顾

    书讯 | 1月书讯:Hello 2021! (上)

    书讯 | 1月书讯:Hello 2021! (下)

    资讯 | 2020年云原生技术关键趋势总结

    书单 | 适合的才是最好的,小众数据库黑马不可小觑

    干货 | 手把手教你如何制作可视化大屏!

    收藏 | 读完《Effective Java》后,我总结了 50 条开发技巧

    上新 | 华为首席开源联络官执笔,带你了解5G时代的边缘计算

    展开全文
  • 点击上方 蓝字 关注我们作为数据分析师的你,是否和我一样经常会被业务方拿着两个不同数据平台的报表数据进行灵魂拷问。下面的场景你应该在熟悉不过了。情景1一场拉新促活的活动之后,运营拿着两个...

    点击上方 蓝字 关注我们

    作为数据分析师的你,是否和我一样经常会被业务方拿着两个不同数据平台的报表数据进行灵魂拷问。下面的场景你应该在熟悉不过了。

    情景1

    一场拉新促活的活动之后,运营拿着两个不同团队维护的报表数据来问我,为什么两份报表统计出来的日活跃用户(DAU)数量不一致?

    我解释道,“你确定两份报表的统计口径是一致的吗,最小的统计维度是一致的吗?”

    运营说,“都是一样的啊,统计的都是DAU。”

    我说,“DAUaccount_id为最小维度进行统计或者以device_id或者以open_id为最小维度进行统计的结果都会有一定的差距。我们这边是以account_id为最小单位统计的DAU。而且,即使统计口径一致,埋点和上报方法也有区别。”

    后来,我向另外一个数据平台的相关人员咨询之后,发现他们统计DAU的最小单位是open_id,不同的统计口径会造成一定的数据差异。而统计口径的差异不止出现在报表统计阶段,在数据埋点阶段也会出现口径不一致的问题,触发事件的条件、数据埋点的方式、数据上报的方式不同都会造成数据不一致的情况出现。

    为了避免这些问题,小编把自己踩过的坑总结出来并形成一套方法论,希望初学的你或即将转行的你能够少采坑,高效地完成数据埋点工作!

     

    01

    数据埋点流程

     

    数据埋点是数据治理流程中重要的一环,是一项多部门协作共同完成的工作,数据分析师在这个流程当中承担着重要的角色。我们将数据埋点流程梳理为下图,数据分析师从数据需求评估阶段直至数据应用阶段都会参与流程,可谓是埋点工作的中流砥柱。

     

    在数据埋点这项工作中,数据分析师需要立足于当前的数据需求,提炼出数据指标方案,并且构思要看这些指标需要有哪些数据,这些数据也就是需要埋的点。当然,这只是一些初步的埋点方案,想要让埋点指标变得“准”而“全”当然还需要另外一些方法实现,比如用户路径之类的。有了初步的埋点规划之后,分析师还需要确定时间触发机制和上报机制,因为不同的机制意味着不同的统计口径。对于新业务来说,为了避免统计口径不一致而出现乌龙事件,最好能和之前的口径一致,以方便横向比较。除此之外呢,统一各个项目之间的字段命名和表结构也是一项必不可少的工作,这个步骤也是数据治理流程当中必不可少环节。完成这些步骤之后,一份初步的埋点就差不多完成了。在和需求方以及程序的反复讨论中修改完善埋点文档,将埋点文档交付程序进行埋点,在此期间分析师需要通过测试环境的数据验证当前埋点是否存在一定的问题,若有问题还可以在该阶段进行修改,若无问题可上线埋点事件。

     

    02

    六个步骤实现数据埋点设计

     

    数据埋点设计师数据分析师是埋点的重中之重,埋点设计得好能够极大地方便后续的数据应用。对于数据埋点设计,我们也总结了六个关键步骤。

     

    1.确认事件与变量

    这里的事件指产品中的功能或者用户的操作,而变量指描述事件的属性或者关键指标。确认事件与变量可以通过AARRR模型或者UJM模型进行逐步拆解,理清用户生命周期和行为路径,抽象出每一个步骤的关键指标。

     

    TipsAARRR模型和UJM模型会在之前的文章中有讲过,点击阅读原文即可跳转。

     

     

    2.明确事件的触发时机

     不同的触发时机代表不同的计算口径,因此触发时机是影响数据准确的重要因素。以用户付款为例,是以用户点击付款界面作为触发条件,还是以付款成功作为触发条件进行埋点呢?二者口径不同,数据肯定会有一定差异,因此明确事件触发条件非常重要。

    而在用户付款这个例子中,我们建议使用两个字段记录用户付款行为,一个字段记录点击付款界面这个行为,另一个字段记录是否付款成功。

     

     

    3.明确事件的上报机制

    不同的上报机制也是数据准确性的重要影响因素之一,客户端上报数据可能会由于网络原因出现丢包的情况,前面章节已经详细介绍过,这里就不在赘述上报机制之间的异同。而作为数据分析师,在完成埋点工作的时候也需要确定数据是实时上报还是异步上报,以确定埋点是否合理,并及时调整数据埋点方案。

     

     

     

    4.设计数据表结构

    统一的数据表结构,方便团队内部进行数据的管理和复用,建议团队内部形成一套统一的数据结构规范。例如,将表分为不同的层级,第一层记录用户的基础信息,包括id,地区,昵称等;第二层记录玩家行为信息。

     

     

    5.统一字段命名规范

    有了统一的数据表结构档案还是不够的,统一数据命名规范数据埋点工作的重要一环。确保同一变量在所有的数据表当中都用统一的字段,比如消费金额这个字段,我们希望所有的表只要出现消费金额都用Amount字段,不要出现money,pay等其他字段。

    建立公司内部或者团队内部的命名规范是非常必要的,可以采用「动词+名词」或者「名词+动词」的规则来命名,比如「加入购物车」事件,就可以命名为:addToCart。

     

     

    6.明确优先级

    数据埋点都是为数据应用做铺排,埋点之后分析师可能面临着搭建指标体系和数据报表体系的工作,可以根据报表的优先级、埋点的技术实现成本以及资源有限性为数据埋点确定优先级。

     

    03

    以电商购物成交转化为例实现数据埋点设计

     

    1)通过UJM模型拆分用户购买商品的路径:将用户购买路径拆解为注册-登录-商品曝光-商品点击-浏览页面详情-加入购物车-生成订单-订单支付步骤,根据产品或策划提的数据需求,确定每一个步骤学要看哪些字段才能实现数据需求。

    2)确认触发机制:明确是在点击按钮时记录行为还是在用户完成该步骤时记录行为。

    3)确认上报机制:明确数据上报机制,是实时上报还是异步上报,不同的上报机制采集到的字段可能不一样,或者说需要将字段拆分到不同表进行记录。

    4)统一字段名:业务内同一变量在所有的数据表当中都用统一的字段,例如,用户编号用account_id,用户所属国家用region,用户所属地区用ip_region等等。

    5)统一表层级结构:我们这里采用两层数据表结构,第一层存放用户基信息,第二层存放用户行为信息。这个根据团队内部的数据接入规范进行调整,只要是统一的结构,对于数据分析师的分析都是有利的。

    6)明确数据优先级:根据埋点需求的紧急程度,给每一个买埋点任务标上优先级。

     

     

    根据上面的六个步骤,将每一个步骤需要记录的字段按照标准格式汇总到文档,即可完成初步的埋点设计。当然完成初版埋点设计之后,还需要与产品、策划、程序一遍一遍过文档内容,不断修改完善,直至三方会谈达成统一意见。

     

     

    参考链接

    http://www.woshipm.com/pd/3070837.html

    https://mp.weixin.qq.com/s?__biz=MzI2MTAxOTk5OQ==&mid=2650945421&idx=1&sn=b16a4fbe3b535b91b21baa8a2855aa8b&chksm=f19657bdc6e1deab3568d0020033a58ffeea90806eff483d9e8d8d32f3115e9160db0a72f68b&scene=21#wechat_redirect

    https://www.cnblogs.com/flzs/p/13815329.html

    如果您觉得我们的文章还不错,请分享,点赞,再看,一键三连!!!

    END

    指标体系相关文章持续更新中,欢迎加入数据人专属交流群

    数据埋点|从隐私保护浅谈数据生命周期,初识数据埋点

    2021-01-19

    指标体系|入职新公司如何为新业务搭建一套通用的指标体系并快速实现指标体系落地

    2021-01-14

    数据分析师在数据治理流程中承担的角色

    2021-01-11

    指标体系|四个模型教会你指标体系构建的方法

    2021-01-04

    指标体系|从中国人口数据谈指标体系构建

    2020-12-28

     



    分享数据知识,成就数据理想

    点个在看 你最好看

    展开全文
  • 埋点数据

    千次阅读 2019-05-15 11:30:25
    本文作者将从一个埋点系统设计者的角度通俗系统地讲解埋点的全过程,涉及到埋点基础知识、埋点作用、埋点方法、埋点数据流程、埋点应用、埋点管理等信息。 埋点是什么 埋点是互联网领域非常重要的数据信息获取...

    原文源自:http://www.woshipm.com/pmd/751876.html

           本文作者将从一个埋点系统设计者的角度通俗系统地讲解埋点的全过程,涉及到埋点基础知识、埋点作用、埋点方法、埋点数据流程、埋点应用、埋点管理等信息。

    埋点是什么

    埋点是互联网领域非常重要的数据信息获取方式。埋点采集信息的过程一般也称作日志采集。

    通俗点讲,就是在APP或者web产品中植入一段代码,监控用户行为事件(例如某个页面的曝光)。用户一旦触发了该事件,就会上传埋点代码中定义的、需要上传的有关该事件的信息。

    常见的信息包括:用户会话id,用户id,当前页面编码,当前事件编码,触发时间,用户设备id,ip信息等等。

    埋点作用

    可以看到,除了像电商购物提交的订单报表等信息是用户填写之后,通过业务数据库中进行读取的;用户在APP或web产品上的行为信息,更多需要靠埋点方式进行获取。典型的应用场景就是某个运营活动,页面的点击量(PV)有多少,点击用户数目(UV)有多少,都是用埋点数据进行计算,来对运营活动有数据上的评估。

    当然这些信息并不是消费一次就没有用处了。通过埋点收集到的信息,可以作为监控,看到APP的长期表现,也可以作为基础原料,进行复杂的运算,用于用户标签、渠道转化分析、个性推荐等等。

    埋点种类

    按照信息采集发生的位置来分,埋点可分为客户端埋点、服务端埋点、H5埋点。客户端埋点即监控APP当地发生事件的埋点,例如APP某页面曝光,一旦APP客户端加载了该页面,客户端埋点就会发送相应信息;H5埋点可能是在APP中跳转到的某个H5页面(如运营活动页)上的埋点,也可能是web某页面上的埋点。

    下文重点讲的是客户端或H5埋点的方式,服务端埋点一般较少,埋点方式也较为通用。

    1、手动埋点

    这是埋点最古老的方式。具体的步骤一般是,产品经理在提需求,需要在APP某个页面的某个事件进行埋点,在这个过程中,产品会对该页面和事件按照一套规则进行编码命名(若事件数不多,页面编码命名这一层也可以省略),以便后续通过该编码对上传上来的信息进行辨认;同时,产品也会将这一埋点需要上传的参数告知前端开发。开发明确需求后就会进行埋点。

    优点:

    • 手动埋点方式简单灵活,来一个埋一个,埋点代码实现过程对开发来说也较为简单,不会占用太多时间。
    • 可对埋点中需要上传信息的字段进行个性化选择,满足复杂业务场景。例如页面曝光埋点中,上传的信息只需要是这个页面编码等就可以了,但如果是某个下拉控件的事件,可能上传的信息中还需要带上下拉控件后最终选择了第几项。

    缺点:

    • 埋点过多时,大量重复性操作较为枯燥且容易出错。新版本发布可能要埋100个点,人工手动去埋,总可能出现某一个忘记埋或者某个应该在A处埋的点埋到了B处的情况。
    • 沟通成本较高。需要PM和开发确认。
    • 埋点周期长。手动埋点如果出现漏埋情况,必须依赖下一版本发版,补上漏埋的那个埋点,才能看到数据。如果新增一个埋点需求,要看数据也只能等下期了。

    2、半自动埋点

    看了上面的手动埋点描述,可能很多人都会有疑问,所有的埋点都需要手工去埋是否有必要。就比如100个埋点中,可能有80个埋点都是页面曝光事件,这类埋点非常相似,完全可以用一套埋点手段去解决。那么半自动埋点就是为了解决这种问题,把部分人工的工作进行标准化,做成SDK。阿里埋点实践中的“黄金令箭”方案就是半自动埋点的典型例子。PM提埋点需求时候,直接将自己申请的埋点进行注册,调用符合自己要求的埋点SDK,并进行下发,那么APP或web产品中就会集成该段埋点代码,而不再需要沟通前端开发进行埋点。当然,在半自动埋点不完善的阶段,可能调用SDK的工作是由开发完成的。

    友盟、神策分析、growing IO等传统的商用化埋点服务,也均是通过埋点SDK这种手段实现的。另外值得一提的是,近来兴起的可视化埋点方案(腾讯MTA、百度移动统计近期也刚新加入了该功能),也算是半自动埋点的一种。通过可视化埋点的方案,PM可以直接看到APP或web产品的界面,在界面上捕捉需要进行埋点的元素如页面或控件等,再通过可视化的点击录入过程,赋予埋点业务含义。也就是说,可视化埋点方案可以通过所见即所得的方式,方便埋点需求方进行埋点。

    优点:

    • 将通用的埋点方式进行整合,提高埋点效率,通过同一套SDK,埋点上传的信息也较为规范,便于后续数据处理。
    • PM直接调用SDK的方式,使得埋点需求提出过程和埋点过程统一,无需付出复杂劳动,省略了整理埋点需求和沟通的环节,也节约了开发进行埋点的工作量。
    • 可视化埋点方案可以更加形象可视地将埋点业务含义和物理代码连接起来,也可以更清晰直观看到哪些控件已有注册埋点。

    缺点:

    • 同样存在埋点周期长的问题。如果漏埋还是要等下一版本发布。
    • 可视化埋点一般只适用于比较简单的APP,如果版本过多,显示的内容不同,需要打开并进行埋点的可视化页面过多,导致管理混乱。
    • 公司自行开发可视化埋点方案成本较高。

    3、全自动埋点

    全自动埋点在一些宣传当中也被称为“无痕埋点”。这种方式和上文的手动和半自动埋点有产生方式上的本质不同。手动和半自动埋点是需求方需要了,才去埋。而全自动埋点则是不管需不需要,将所有的点都埋了。通常这种埋点也是通过SDK实现的,这种SDK不需调用,已经直接嵌入在APP中。因为全自动埋点都是自动生成的,用于对每一个埋点进行标识的埋点编码也是按照既定规则进行生成。通常这种标识是不可读的,需要PM和开发沟通,对埋点编码进行和业务含义上的映射。

    全自动埋点方法听起来挺简单粗暴,优点和缺点也同样突出。

    优点:

    • 根本上解决漏埋问题,缩短埋点周期。
    • 无需对页面、控件是否需要进行埋点做区分,需要数据时直接取数据。

    缺点:

    • 全自动埋点一套SDK对应一套数据上传方式,需要尽可能通用,个性化的数据采集无法满足。一般只能对页面曝光、关闭,控件点击这种通用事件进行全自动埋点。
    • 全自动埋点覆盖面广,数据传输压力大,可能有很多上传上来的信息是不需要的。
    • 和一些半自动埋点中PM可自行通过SDK自助进行埋点相比,全自动埋点仍需要PM和开发沟通。因为全自动埋点中埋点编码为自动生成,其意义只有开发明白,要想对应到业务含义,必须由开发参与。
    • 安卓APP和IOS APP往往是两组开发人员开发的。全自动埋点这种“埋点创造于开发过程而不是需求过程”的模式,很容易导致同一个埋点事件,其埋点物理编码在安卓和IOS上是不同的,这就需要埋点需求方花费时间去做对应。对应过程是复杂而艰辛的。

    因而,全自动埋点适用于产品比较小,页面、控件少,上传的数据也较少的情况。同样,全自动埋点也可以配合可视化埋点方案,此时可视化页面中不仅仅是捕捉到页面或控件,同样可以显示其已存在的埋点编码名称,埋点需求方可将该不易读的编码录入到可读的业务含义上。

     

    正如上文所提的,埋点是互联网公司获取数据信息的重要方式。数据的全流程一般涉及到采集、传输、加工、存储、应用等过程。下面就将按照这个顺序,对埋点全流程进行说明。最后,加入了一个埋点系统设计者对埋点管理过程的理解,期待同行的交流~

    采集过程

    上文提到了埋点信息采集的方式,那么具体埋点信息采集的过程是怎么样的呢?

    以H5网页某页面曝光埋点为例子,先讲一下网页页面展现的流程。框图如下:

    具体细节如下:

    1. 用户点击或输入某页面链接。
    2. APP客户端或浏览器向服务器发送HTTP请求。该请求内容一般包括请求的URL、请求方法、请求报头(一些必要的内容例如用户cookie等)、请求内容。
    3. 服务器接受HTTP请求,进行解析,并将内容返回给客户端或浏览器。返回内容一般包括返回状态(是否成功,例如著名的404就是在这里进行添加的),返回具体内容(请求的网页中包含的内容如图片等),返回报头(cookie等)
    4. 客户端或浏览器对返回内容进行解析,并把内容展示给用户。

    这样就完成了一个页面的曝光展示。如果对该曝光事件加上埋点,前两步是没有影响的,在第三步:服务器在返回HTTP内容时,会加入一段与埋点相关的脚本代码(如上文埋点方式部分所说,这段代码可能是手动埋点写入的,也可能是半自动或全自动埋点方式写入的)。

    客户端或浏览器解析到这部分内容时,会向埋点日志接收服务器(以下简称埋点服务器)发送一个请求。这个请求中即带有我们通过埋点想获得的宝贵的数据信息。埋点服务器接受到请求后,会返回一个已接收的信息给客户端。同时,埋点服务器会将这些信息传输到后续环节。如下图:

    这里再说一下和数据准确性有关的内容。在客户端向埋点服务器发送信息的过程中,可能存在丢包,即数据发送失败信息没有传输过去的情况。该发送过程一般通过POST格式,发送JSON串信息,具体方式分两种:一种是单条发送;一种是在本地打包成zip包,积累一定量后发送。两种方式中,zip的丢包情况更严重些。所以PM在看数据时候,也应当清楚,数据会有一定误差。(据作者实践经验,单条POST格式数据误差一般不超过2%)

    传输流程:

    埋点数据产生之后,被埋点服务器接收,有些时候会进行解析操作,然后会通过消息订阅通道例如kafka之类进行消息的分发,进入离线或实时的储存中,用于后续的计算和分析。

    加工存储

    加工:经过加工存储这一步后,埋点数据基本可以从收集到的原材料状态变为可以为业务服务的有用数据了。上文提到,埋点数据都是一条一条,是用户触发埋点对应事件时上传的。

    这些数据可能包括:用户会话id,用户id,当前页面编码,当前事件编码,触发时间,用户设备id,ip信息等,这些零散的信息需要通过加工处理进行聚合,变成更加通用常用的数据,便于后续调用。

    例如一些通用的处理:针对APP首页曝光事件,选取当日首页曝光事件上传的数据条数,对用户id去重并加和即可以得到当日的UV。

    存储:对于离线存储来说,埋点原始数据会以表(类似excel表)的形式存储于数据仓库的原始数据层,经过上述处理过的数据,会以另外一张表的形式存储于数据仓库的汇总层。如果数据仓库建设比较完善,通用的业务数据,直接从汇总层甚至更上层的应用层中取即可,而不必再去取原始层的埋点数据,省去了每次计算的工作量。

    埋点管理过程

    最原始的埋点管理方式是用文档或表格记录下来埋点的编码命名、业务含义及其他必备信息,在埋点业务方内部共享即可。

    但当公司的产品越做越多越做越大,相应的埋点就会越多(多达成千甚至上万)。对互联网规模企业,管理大量埋点往往也需要配套的工具:埋点信息管理系统。

    埋点信息管理系统主要有的功能:

    • 提供埋点信息的录入功能。
    • 记录各埋点是否存在,进行埋点层级管理。因为埋点较多,往往需要按照APP-页面-控件的层级进行分类、记录和查询。
    • 展示并可查询某埋点的详细信息。例如物理编码信息和对应的业务含义信息,埋点的上线版本和时间,埋点管理员责任人,埋点信息储存的数仓表名称以及必要的埋点数据结构体(对个性化埋点可能出现的上传数据中新加字段的解释)。
    • 辅助功能。如埋点数据量的监控,埋点信息预览,埋点数据通用分析及可视化展示等。

    埋点管理是建立在埋点生成、传输、储存等过程的基础之上的。管理的重点和难点,在于大量埋点物理编码(命名编码)和业务含义的对应。这个对应是将不可读的英文编码字段和易于理解的汉语业务含义连接起来的过程。对应可能是一对多,多对一,甚至多对多的。

    1.对应过程在手动埋点中,反应在PM与开发沟通及开发具体埋点行为中。首先PM需要根据业务含义,选择要埋的点并取或生成一个物理编码;之后开发按照这个对应关系,将物理编码写入到业务含义对应的页面或事件上。这个过程是抽象且容易出错的。

    2.对应过程在全自动埋点中,反应在PM和开发沟通并“认领”自动埋点的行为中。PM需要向开发了解,已经存在的某物理编码代表的是什么意思即其业务含义是什么,然后将这两者关联。往往还需要将IOS和安卓两个不同的物理编码关联到同一业务含义上,因为这两个物理编码实际就是同一页面或控件。这个过程,也是抽象易错的。

    抽象易错,主要是因为需要凭脑中想象将两种文字编码级的内容进行关联。上文提到的可视化埋点则可通过直观的APP展现,显示出物理编码及业务含义,解决抽象的问题。伴随着产品迭代埋点数目增长,似乎有效的可视化埋点是大公司做埋点管理有必要尝试的方向。

    原文源自:http://www.woshipm.com/pmd/751876.html

           本文作者将从一个埋点系统设计者的角度通俗系统地讲解埋点的全过程,涉及到埋点基础知识、埋点作用、埋点方法、埋点数据流程、埋点应用、埋点管理等信息。

    埋点是什么

    埋点是互联网领域非常重要的数据信息获取方式。埋点采集信息的过程一般也称作日志采集。

    通俗点讲,就是在APP或者web产品中植入一段代码,监控用户行为事件(例如某个页面的曝光)。用户一旦触发了该事件,就会上传埋点代码中定义的、需要上传的有关该事件的信息。

    常见的信息包括:用户会话id,用户id,当前页面编码,当前事件编码,触发时间,用户设备id,ip信息等等。

    埋点作用

    可以看到,除了像电商购物提交的订单报表等信息是用户填写之后,通过业务数据库中进行读取的;用户在APP或web产品上的行为信息,更多需要靠埋点方式进行获取。典型的应用场景就是某个运营活动,页面的点击量(PV)有多少,点击用户数目(UV)有多少,都是用埋点数据进行计算,来对运营活动有数据上的评估。

    当然这些信息并不是消费一次就没有用处了。通过埋点收集到的信息,可以作为监控,看到APP的长期表现,也可以作为基础原料,进行复杂的运算,用于用户标签、渠道转化分析、个性推荐等等。

    埋点种类

    按照信息采集发生的位置来分,埋点可分为客户端埋点、服务端埋点、H5埋点。客户端埋点即监控APP当地发生事件的埋点,例如APP某页面曝光,一旦APP客户端加载了该页面,客户端埋点就会发送相应信息;H5埋点可能是在APP中跳转到的某个H5页面(如运营活动页)上的埋点,也可能是web某页面上的埋点。

    下文重点讲的是客户端或H5埋点的方式,服务端埋点一般较少,埋点方式也较为通用。

    1、手动埋点

    这是埋点最古老的方式。具体的步骤一般是,产品经理在提需求,需要在APP某个页面的某个事件进行埋点,在这个过程中,产品会对该页面和事件按照一套规则进行编码命名(若事件数不多,页面编码命名这一层也可以省略),以便后续通过该编码对上传上来的信息进行辨认;同时,产品也会将这一埋点需要上传的参数告知前端开发。开发明确需求后就会进行埋点。

    优点:

    • 手动埋点方式简单灵活,来一个埋一个,埋点代码实现过程对开发来说也较为简单,不会占用太多时间。
    • 可对埋点中需要上传信息的字段进行个性化选择,满足复杂业务场景。例如页面曝光埋点中,上传的信息只需要是这个页面编码等就可以了,但如果是某个下拉控件的事件,可能上传的信息中还需要带上下拉控件后最终选择了第几项。

    缺点:

    • 埋点过多时,大量重复性操作较为枯燥且容易出错。新版本发布可能要埋100个点,人工手动去埋,总可能出现某一个忘记埋或者某个应该在A处埋的点埋到了B处的情况。
    • 沟通成本较高。需要PM和开发确认。
    • 埋点周期长。手动埋点如果出现漏埋情况,必须依赖下一版本发版,补上漏埋的那个埋点,才能看到数据。如果新增一个埋点需求,要看数据也只能等下期了。

    2、半自动埋点

    看了上面的手动埋点描述,可能很多人都会有疑问,所有的埋点都需要手工去埋是否有必要。就比如100个埋点中,可能有80个埋点都是页面曝光事件,这类埋点非常相似,完全可以用一套埋点手段去解决。那么半自动埋点就是为了解决这种问题,把部分人工的工作进行标准化,做成SDK。阿里埋点实践中的“黄金令箭”方案就是半自动埋点的典型例子。PM提埋点需求时候,直接将自己申请的埋点进行注册,调用符合自己要求的埋点SDK,并进行下发,那么APP或web产品中就会集成该段埋点代码,而不再需要沟通前端开发进行埋点。当然,在半自动埋点不完善的阶段,可能调用SDK的工作是由开发完成的。

    友盟、神策分析、growing IO等传统的商用化埋点服务,也均是通过埋点SDK这种手段实现的。另外值得一提的是,近来兴起的可视化埋点方案(腾讯MTA、百度移动统计近期也刚新加入了该功能),也算是半自动埋点的一种。通过可视化埋点的方案,PM可以直接看到APP或web产品的界面,在界面上捕捉需要进行埋点的元素如页面或控件等,再通过可视化的点击录入过程,赋予埋点业务含义。也就是说,可视化埋点方案可以通过所见即所得的方式,方便埋点需求方进行埋点。

    优点:

    • 将通用的埋点方式进行整合,提高埋点效率,通过同一套SDK,埋点上传的信息也较为规范,便于后续数据处理。
    • PM直接调用SDK的方式,使得埋点需求提出过程和埋点过程统一,无需付出复杂劳动,省略了整理埋点需求和沟通的环节,也节约了开发进行埋点的工作量。
    • 可视化埋点方案可以更加形象可视地将埋点业务含义和物理代码连接起来,也可以更清晰直观看到哪些控件已有注册埋点。

    缺点:

    • 同样存在埋点周期长的问题。如果漏埋还是要等下一版本发布。
    • 可视化埋点一般只适用于比较简单的APP,如果版本过多,显示的内容不同,需要打开并进行埋点的可视化页面过多,导致管理混乱。
    • 公司自行开发可视化埋点方案成本较高。

    3、全自动埋点

    全自动埋点在一些宣传当中也被称为“无痕埋点”。这种方式和上文的手动和半自动埋点有产生方式上的本质不同。手动和半自动埋点是需求方需要了,才去埋。而全自动埋点则是不管需不需要,将所有的点都埋了。通常这种埋点也是通过SDK实现的,这种SDK不需调用,已经直接嵌入在APP中。因为全自动埋点都是自动生成的,用于对每一个埋点进行标识的埋点编码也是按照既定规则进行生成。通常这种标识是不可读的,需要PM和开发沟通,对埋点编码进行和业务含义上的映射。

    全自动埋点方法听起来挺简单粗暴,优点和缺点也同样突出。

    优点:

    • 根本上解决漏埋问题,缩短埋点周期。
    • 无需对页面、控件是否需要进行埋点做区分,需要数据时直接取数据。

    缺点:

    • 全自动埋点一套SDK对应一套数据上传方式,需要尽可能通用,个性化的数据采集无法满足。一般只能对页面曝光、关闭,控件点击这种通用事件进行全自动埋点。
    • 全自动埋点覆盖面广,数据传输压力大,可能有很多上传上来的信息是不需要的。
    • 和一些半自动埋点中PM可自行通过SDK自助进行埋点相比,全自动埋点仍需要PM和开发沟通。因为全自动埋点中埋点编码为自动生成,其意义只有开发明白,要想对应到业务含义,必须由开发参与。
    • 安卓APP和IOS APP往往是两组开发人员开发的。全自动埋点这种“埋点创造于开发过程而不是需求过程”的模式,很容易导致同一个埋点事件,其埋点物理编码在安卓和IOS上是不同的,这就需要埋点需求方花费时间去做对应。对应过程是复杂而艰辛的。

    因而,全自动埋点适用于产品比较小,页面、控件少,上传的数据也较少的情况。同样,全自动埋点也可以配合可视化埋点方案,此时可视化页面中不仅仅是捕捉到页面或控件,同样可以显示其已存在的埋点编码名称,埋点需求方可将该不易读的编码录入到可读的业务含义上。

     

    正如上文所提的,埋点是互联网公司获取数据信息的重要方式。数据的全流程一般涉及到采集、传输、加工、存储、应用等过程。下面就将按照这个顺序,对埋点全流程进行说明。最后,加入了一个埋点系统设计者对埋点管理过程的理解,期待同行的交流~

    采集过程

    上文提到了埋点信息采集的方式,那么具体埋点信息采集的过程是怎么样的呢?

    以H5网页某页面曝光埋点为例子,先讲一下网页页面展现的流程。框图如下:

    具体细节如下:

    1. 用户点击或输入某页面链接。
    2. APP客户端或浏览器向服务器发送HTTP请求。该请求内容一般包括请求的URL、请求方法、请求报头(一些必要的内容例如用户cookie等)、请求内容。
    3. 服务器接受HTTP请求,进行解析,并将内容返回给客户端或浏览器。返回内容一般包括返回状态(是否成功,例如著名的404就是在这里进行添加的),返回具体内容(请求的网页中包含的内容如图片等),返回报头(cookie等)
    4. 客户端或浏览器对返回内容进行解析,并把内容展示给用户。

    这样就完成了一个页面的曝光展示。如果对该曝光事件加上埋点,前两步是没有影响的,在第三步:服务器在返回HTTP内容时,会加入一段与埋点相关的脚本代码(如上文埋点方式部分所说,这段代码可能是手动埋点写入的,也可能是半自动或全自动埋点方式写入的)。

    客户端或浏览器解析到这部分内容时,会向埋点日志接收服务器(以下简称埋点服务器)发送一个请求。这个请求中即带有我们通过埋点想获得的宝贵的数据信息。埋点服务器接受到请求后,会返回一个已接收的信息给客户端。同时,埋点服务器会将这些信息传输到后续环节。如下图:

    这里再说一下和数据准确性有关的内容。在客户端向埋点服务器发送信息的过程中,可能存在丢包,即数据发送失败信息没有传输过去的情况。该发送过程一般通过POST格式,发送JSON串信息,具体方式分两种:一种是单条发送;一种是在本地打包成zip包,积累一定量后发送。两种方式中,zip的丢包情况更严重些。所以PM在看数据时候,也应当清楚,数据会有一定误差。(据作者实践经验,单条POST格式数据误差一般不超过2%)

    传输流程:

    埋点数据产生之后,被埋点服务器接收,有些时候会进行解析操作,然后会通过消息订阅通道例如kafka之类进行消息的分发,进入离线或实时的储存中,用于后续的计算和分析。

    加工存储

    加工:经过加工存储这一步后,埋点数据基本可以从收集到的原材料状态变为可以为业务服务的有用数据了。上文提到,埋点数据都是一条一条,是用户触发埋点对应事件时上传的。

    这些数据可能包括:用户会话id,用户id,当前页面编码,当前事件编码,触发时间,用户设备id,ip信息等,这些零散的信息需要通过加工处理进行聚合,变成更加通用常用的数据,便于后续调用。

    例如一些通用的处理:针对APP首页曝光事件,选取当日首页曝光事件上传的数据条数,对用户id去重并加和即可以得到当日的UV。

    存储:对于离线存储来说,埋点原始数据会以表(类似excel表)的形式存储于数据仓库的原始数据层,经过上述处理过的数据,会以另外一张表的形式存储于数据仓库的汇总层。如果数据仓库建设比较完善,通用的业务数据,直接从汇总层甚至更上层的应用层中取即可,而不必再去取原始层的埋点数据,省去了每次计算的工作量。

    埋点管理过程

    最原始的埋点管理方式是用文档或表格记录下来埋点的编码命名、业务含义及其他必备信息,在埋点业务方内部共享即可。

    但当公司的产品越做越多越做越大,相应的埋点就会越多(多达成千甚至上万)。对互联网规模企业,管理大量埋点往往也需要配套的工具:埋点信息管理系统。

    埋点信息管理系统主要有的功能:

    • 提供埋点信息的录入功能。
    • 记录各埋点是否存在,进行埋点层级管理。因为埋点较多,往往需要按照APP-页面-控件的层级进行分类、记录和查询。
    • 展示并可查询某埋点的详细信息。例如物理编码信息和对应的业务含义信息,埋点的上线版本和时间,埋点管理员责任人,埋点信息储存的数仓表名称以及必要的埋点数据结构体(对个性化埋点可能出现的上传数据中新加字段的解释)。
    • 辅助功能。如埋点数据量的监控,埋点信息预览,埋点数据通用分析及可视化展示等。

    埋点管理是建立在埋点生成、传输、储存等过程的基础之上的。管理的重点和难点,在于大量埋点物理编码(命名编码)和业务含义的对应。这个对应是将不可读的英文编码字段和易于理解的汉语业务含义连接起来的过程。对应可能是一对多,多对一,甚至多对多的。

    1.对应过程在手动埋点中,反应在PM与开发沟通及开发具体埋点行为中。首先PM需要根据业务含义,选择要埋的点并取或生成一个物理编码;之后开发按照这个对应关系,将物理编码写入到业务含义对应的页面或事件上。这个过程是抽象且容易出错的。

    2.对应过程在全自动埋点中,反应在PM和开发沟通并“认领”自动埋点的行为中。PM需要向开发了解,已经存在的某物理编码代表的是什么意思即其业务含义是什么,然后将这两者关联。往往还需要将IOS和安卓两个不同的物理编码关联到同一业务含义上,因为这两个物理编码实际就是同一页面或控件。这个过程,也是抽象易错的。

    抽象易错,主要是因为需要凭脑中想象将两种文字编码级的内容进行关联。上文提到的可视化埋点则可通过直观的APP展现,显示出物理编码及业务含义,解决抽象的问题。伴随着产品迭代埋点数目增长,似乎有效的可视化埋点是大公司做埋点管理有必要尝试的方向。

    展开全文
  • 系统埋点设计 1、数据分类 在工厂环境中,我们将数据仓库获取的数据划分为业务数据和用户行为数据。 1. 业务数据:业务流程中产生的交易、状态流转、用户等相关的数据,通常存储在 DB 中, 包括 rdbms、nosql等,这...

    系统埋点设计

    1、数据分类

    在工厂环境中,我们将数据仓库获取的数据划分为业务数据和用户行为数据。

    1. 业务数据:业务流程中产生的交易、状态流转、用户等相关的数据,通常存储在 DB 中, 包括 rdbms、nosql等,这部分数据是业务相关的,具体哪些数据需要保留一般由业务侧设计,不需要过度关注,按实际需要采集即可。

    2. 用户行为数据:用户在使用产品过程中,与 C 端产品 (面向个人消费者的产品,比如:微信、头条、抖音、美团等等) 交互过程中产生的数据,比如页面浏览、点击、停留等,这部分数据由于不影响业务流程本身,所以通常不受关注,但对运营、产品优化至关重要,所以通常也是数据建设的一部分,需要单独设计数据埋点、采集策略

    2、用户行为数据埋点设计

    用户行为数据埋点的设计有三个关键点:

    1. 用户标识体系建立
    2. 多屏用户标识打通(多屏:手机、PC、Pad)
    3. 埋点方案设计

    2.1 用户标识体系建立

    在电商场景中经常会遇到用户在不登录/注册的情况下访问网站的情况,对于电商平台来说,希望能够收集到用户所有的访问行为数据,包括用户在未登录/注册之前的行为数据, 这就涉及到了用户标识的问题,如何在用户不登录/注册的情况下对用户进行标识,并且将不登录/注册情况下的用户行为数据追加到用户完整的用户行为数据中,这是用户标识体系需要完成的工作。

    同样的,对于运营、产品和研发部门,需要根据用户在注册前后的行为,明确是什么吸引了用户最终完成注册。因此需要将用户注册之前的行为与注册之后的行为关联起来,也就是将注册前后的信息打通。

    2.2 用户标识建立方案

    考虑到移动端和 PC 端的区别,我们在建立用户标识时划分两个场景,分别是 PC 端和APP 端:

    • 1)PC 端
      PC 端的电商平台在浏览器中进行展示,也就是以 H5 的形式进行展示,采用 cid 和 uid 相结合的方式对用户进行标识。

      cid:类似于 cookie id,但不是 cookie id,cid 随着不同的用户切换在改变,我们的目的是用 cid 来标识用户,同一个用户在不同的屏幕上是不同的 cid
      uid:是用户注册后分配给用户的,可以唯一标识一个用户的序号。

    • 2)APP端
      APP 端同样采用 cid 和 uid 相结合的方式对用户进行标识。

      cid:使用设备 imei/IDfa 根据某种规则生成唯一设备标识,作为 cid。
      浅谈移动端设备标识码https://www.jianshu.com/p/38f4d1a4763b

      uid:是用户注册后分配给用户的,可以唯一标识一个用户的序号。
      设备标识码
      以上的两种方案都引入了 cid 和 uid 的概念,只不过不同的平台 cid 的定义不同

      在用户注册/登录前,使用 cid 作为设备标识,跟踪用户行为数据;用户注册/登录后, 使用 uid 标识用户,跟踪用户行为数据。

      ① 一个新设备,从来没有访问过电商平台,第一次无登录访问时,电商平台给他分配一个 cid,然后,用户登录了,由于不是切换用户,那么 cid 不变,登录后的数据有一个 uid, 根据登录后的 cid 和登录前的 cid 进行数据的匹配。

      ② 一个新设备,从来没有访问过电商平台,第一次无登录访问时,电商平台给他分配一个 cid,然后,用户注册了,由于是新注册,cid 不变,用户登录后电商平台分配给他一个新的 uid,根据登录后的 cid 和登录前的 cid 进行数据的匹配。

      ③ 一个老设备,一个人登录后,cid=xyz,uid=123,退出登录后,cid 不变,uid 不变, 之后所有的未登录访问行为的 cid 和 uid 都是上一次登录的人的 cid 和 uid,因此全部会被划分到上一个登录的人的行为里。

      ④ 一个老设备,一个人登录后,cid=xyz,uid=123,退出登录后,cid 不变,uid 不变, 之后有人再次登录,如果 cookie 中的 uid 和之前的不一致,那么判定为用户登录切换,是不同用户,cid 改变,uid 改变,如果 cookie 中的 uid 和之前的一致,那么 cid 和 uid 都不变化。

      根据③可知,如果一个人登录后再推出登录,在下次登录之前,即使是多个不同的人访问了电商平台,也会被记为上次登录的人的访问行为。虽然 cid 并不是非常精确,但是他能够让数据找到归属。

    2.3 多屏用户打通

    一个用户可能同时拥有手机、平板、电脑等设备,我们将多种不同的电子设备称为多屏。我们希望能够将同一个用户在多屏上的数据进行打通

    同一用户在不同屏幕上的 cid 是不同的,但是 uid 是相同的,但是如果只使用 uid,那么注册/登录之前的数据就会丢失,因此必须将 cid 和 uid 结合使用。

    综上所述,通过 cid 和 uid 相互结合,实现未注册/登录数据与注册/登录数据的整合,然后通过 uid 实现多屏数据的打通

    2.4 埋点设计

    2.4.1 埋点对象分类

    在生产环境下,我们主要的埋点对象有两类:Native APP、Web H5

    PC 端的用户主要访问的是 H5 页面,移动端用户主要是使用 APP 进行访问,当前我们所接触到的APP 有多种类型,如 Native APP、Web APP、Hybird APP,在详细讨论埋点设计之前,我们先了解一下几种不同的 APP:

    1)Native App
    Native App 是一种基于智能手机本地操作系统如 iOS、Android、WP并使用原生程式编写运行的第三方应用程序,也叫本地 app。一般使用的开发语言为 JAVA、C++、Objective-C。

    Native App 因为位于平台层上方,向下访问和兼容的能力会比较好一些,可以支持在线或离线,消息推送或本地资源访问,摄像拨号功能的调取。但是由于设备碎片化,App 的开发成本要高很多,维持多个版本的更新升级比较麻烦,用户的安装门槛也比较高。

    2)Web APP
    Web App 就是运行于网络和标准浏览器上,基于网页技术开发实现特定功能的应用。

    WebApp 是指基于 Web 的系统和应用,其作用是向广大的最终用户发布一组复杂的内容和功能。
    当用户登录一个网站(如百度、淘宝),大家很容易理解这是在访问一个 Web App。但是对那些仅仅提供基础服务(如电话查询或是信息查询)的网站,区分用户是否在访问 WebApp 就变得相当困难了。
    其实这些服务大多都是 Web App。常常这样问自己“这个程序是否完成了某个任务?”。即便它只完成了某个非常小的任务,那么它也是一个 Web App。Google 的搜索引擎就是一个 Web App,它本质上和电话查询服务没有什么区别。

    3)Hybrid APP
    Hybrid App(混合模式移动应用)是指介于 web-app、native-app 这两者之间的 app兼具“Native App 良好用户交互体验的优势”和“Web App 跨平台开发的优势”。

    Hybrid App 虽然看上去是一个 Native App,但只有一个 UI WebView,里面访问的是一个 Web App,比如街旁网最开始的应用就是包了个客户端的壳,其实里面是 HTML5 的网页,后来才推出真正的原生应用。再彻底一点的,如掌上百度和淘宝客户端 Android 版,走的也是 Hybrid App 的路线,不过掌上百度里面封装的不是 WebView,而是自己的浏览内核,所以体验上更像客户端,更高效。

    Native APP 无法获取 URL 相关信息,Web APP 无法获取设备相关的信息,因此,市面上现有的 APP 大部分是 Hybird APP,它兼具 Native APP 和 Web APP 的特点,能够同时获得设备信息和 URL 信息。

    通常设计埋点时针对 Native App、Web H5 采用不同的规范,但不利于数据整合和使用, 推荐采用事件模型进行埋点设计,即把用户的一切行为动作都看作事件,包括页面浏览、按钮悬停、点击等,这样 Native 和 H5 统一数据标准,实际数据仅参数上的区别

    2.4.2 埋点分类

    根据埋点位置,可分为客户端埋点、服务端埋点

    两种埋点方式各有利弊,比如服务端埋点对无后台请求的用户行为无法捕获(比如用户在页面上的悬停,这种事件是有意义的,比如用户会悬停在感兴趣的品类、商品或者广告上),而客户端埋点可能会由于用户的环境问题存在数据包丢失,客户端可能无法获取全部的数据(有些数据存储在服务端,因为页面不会存储过多不会经常使用的信息,客户端需要一些调用才能够获取到,对性能会有影响)等,所以无特殊情况下,建议采用服务端埋点方案

    APP 的更新时是周期性的,你没有办法强制用户去更新 APP,如果在客户端埋点的话就会由于版本更新的问题没有办法改变埋点,但是如果在服务器埋点的话就没有这个问题, 可以在服务器端按照需求设置埋点,不关心 APP 的版本。

    如果有一些类似于悬停这种事件,服务端无法捕获到,而这些事件又是非常重要的,那么可以在页面上加入一些代码,当发生这些事件的时候执行一个请求服务器的动作,让服务端进行埋点,负责这部分数据的落地

    3、业务数据埋点设计

    业务数据一般存储于 rdbms 中,由业务 RD(研发工程师) 根据业务流程设计,具体记录信息无需过度关注,但在可能的情况下,尽可能提出相应的规范。

    • ① 每张业务表必须有自增 id 能够唯一标识一行记录。
    • ② 必须包含该记录的写入时间(created_time)、数据更新时间(updated_time),部分表最好能够
      updated_time 列构建索引
      (方便后续的数据采集,根据时间进行数据的获取)。

    独立的业务数据埋点:由业务服务端根据具体场景的需要,独立记录和业务强相关数据日志(不是用户行为数据),通常落地于相应业务应用的服务器磁盘,需要单独采集, 方案可以参考用户行为数据的采集。

    4、数据埋点案例分析

    4.1 背景

    某电商平台,产品覆盖 app、pc 端,其中 app 为 hybrid 架构,业务数存储 mysql 库中。

    4.2 需求

    需要分析用户访问路径、各步转化、流失等,进行页面优化、运营效果评估、商品推荐。

    4.3 设计埋点规范

    • ①一切用户操作行为都看作事件
    • ②应覆盖事件的核心要素
      在这里插入图片描述

    4.4 数据格式

    为确保灵活、可扩展性,上报数据采用 json 格式不要太深的嵌套99%的埋点都是一层),将数据分为两部分:公有参数、自定义私有参数。

    • ① 公有参数
      公有参数需要覆盖事件核心要素,实际上报数据时不可缺失。

      埋点数据公有参数:
      在这里插入图片描述

    • ② 私有参数
      私有参数即根据事件发生时的场景、需求,定义需要抓取的数据内容。
      某种意义上该部分数据也分公共参数与私有参数,比如事件发生在 app 中,一般都会伴随当时的设备信息;事件发生在 h5 中,一般会伴随 url。

      对于一般的推广 H5,需要抓取基本数据
      currurl(当前页面的 URL)、refferurl(上一级页面的独立 URL)、refferpage(上一级页面的独 立名称)(适配 App 页面)、sourceid(跟踪访问的源头,是微信、微博还是其他的推广平台,用以判断哪边的推广效果更好)、自定义参数(比如商品 ID、活动 ID、商家 ID、posid 等)。

      对于 App,一般需要附加设备信息
      refferpage(上一级页面的独立名称)、自定义参数( 商品 id、商家 id 等等)、设备信息(imei、idfa、os、gps、wifi 等信息)。

      对于 hybrid APP
      其中包括 native 和 h5,虽然是 h5,但由于在 app 中,依然能够拿到相关设备信息,因此按照 app 的参数设计进行埋点,同时也要包括 h5 自身的特有数据,比如 url、refferurl 等。

    4.5 埋点数据内容设计

    4.5.1 APP 启动埋点

    本着抓取高价值、符合需求、不影响用户体验和性能的原则,仅在用户启动 app 时触发,在用户授权的情况下抓取用户手机中安装的 app 信息、通讯录信息,频率可以自定义。
    在这里插入图片描述

    4.5.2 列表页

    在这里插入图片描述

    • 1) 普通版本:
      在这里插入图片描述

    • 2)计费版本一:
      页面采用翻页模式,一页只有一个事件,进入列表页后,将这一页的所有商品进行上报。
      在这里插入图片描述

    • 3)计费版本二
      对于精确的曝光计费,特别是滚动刷新的方式(非翻页),用户不真正看到商品是不是计入 goodlist 的,之后用户真正滚动到了商品的位置,才会计入 goodlist,上报服务器。

      在计费方式二的情况下,会随着每次页面的翻转发送一条列表页日志数据。
      在这里插入图片描述

    4.5.3 详情页

    在这里插入图片描述

    • 1) click
      在这里插入图片描述

    • 2) preview
      preview 事件的 PV(page view面浏览量)往往低于 click 事件,因为有的访问会加载失败。如果 preview 和 click 相差太多(同一个页面),那么就要审视是否是产品出了问题,为什么这么多次没有加载出来,是后台性能太差还是网络一直有问题。
      在这里插入图片描述

    4.5.4 首页

    我们关注用户是通过什么途径进入主页的,这就涉及到渠道推广,因为很多电商在其他平台进行推广,而推广是需要交纳一定费用的,而其他平台向你提出的收费额度,你怎么确定是否准确,就要通过首页的埋点进行采集。
    在这里插入图片描述
    在这里插入图片描述

    4.5.5 banner(横幅)

    页面上的不同广告位的定价不同,同一广告位会有多个广告(滚动屏,自动切换),这些广告由于前后位置的不同收费不同,除了首页占据大面积的滚动屏,还有固定位置的广告。
    在这里插入图片描述
    埋点参数等设计完毕后,提交相关开发组开发。

    若存在客户端埋点,需考虑用户网络环境下的数据丢失、数据上报性能:

    • 对于 h5,实时、异步上报
    • 对于 App 客户端缓存,小批量压缩上报,尤其是数据比较大时;比如缓存 3s 或者数据大于 1M 主动上报。

    4.6 埋点数据采集系统搭建

    埋点数据的采集方案有多种选择,下图为企业常用的埋点数据采集方案之一:
    在这里插入图片描述
    如上图所示,APP 以及 H5 端的埋点数据首先被发送到 Nginx 中,由 Nginx 负载均衡到Tomcat 服务器,Tomcat 服务器中部署的 Servlet 接受埋点数据,处理后调用 Kafka API 发送到 Kafka 集群,离线数据处理和实时处理分别通过 Kafka 消费者消费 Kafka 集群中的数据, 然后进行后续的处理工作。

    根据 Kafka 消息队列的特性,消息队列实现了生产者与消费者的隔离,在上述的采集方案中,控制层的 Servlet 为生产者,数据处理层的离线业务或者实时业务为消费者,通过 Kafka 的特性,实现了控制层与数据处理层的隔离。

    • 离线业务消费埋点数据后,会将用户行为数据写入 ODS 层的表格中,之后在数据仓库中进行数据的分析处理。
    • 实时业务消费埋点数据后,会对数据进行实时的分析和处理,之后存入数据库

    4.7 数据同步策略

    4.7.1 增量型

    1).无状态变更数据

    假设数据源是流水数据,此类数据没有状态变更,写入数据库后基本不再改变,数据中一般包含 Created_time 信息,可以根据 Created_time 的值获取增量数据,或者记录上次的获取到的 ID,然后从下一个 ID 开始获取,这是一种纯增量采集
    在这里插入图片描述
    2).有状态变更数据

    假设表比较大,比如说一些订单表,这些表的状态变化周期一般偏长,状态变化一直会更新,而且状态变化会跨零点

    此时要求所有的源系统数据库的设计需要加入 Created_time、updated_time,在 Source层把昨天发生变化的数据抽取过来(updated_time >= T-1 0:0:0),没有设置 updated_time < T 0:0:0,因为你昨天对数据进行了修改,可能在今天采集数据之前又进行了修改,因此,只要昨天修改过就符合抽取条件,如果想更更精准地获取数据,或者说让抽取的数据量小一点, 那么可以加入 Created_time 的限制条件(updated_time >= T-1 0:0:0 and Created_time < T 0:0:0),通过这种抽取条件就可以获得昨天更新的数据和昨天新增的数据。
    在这里插入图片描述
    获取到更新数据后进行合并,两张表进行比对(根据主键进行比对):(A 表为 T-2 全量数据,B 表为增量数据)

    1. 如果 A 表中包含的数据(根据自增主键判断)在 B 表中也包含,那么就代表数据在昨天发生了变化,那么就用 B 中的数据替换 A 中的数据。
    2. 如果 A 表中没有的数据在 B 表中包含,那么就代表数据时昨天新插入的,那么就将 B 中数据插入 A。
    3. 如果 A 表中包含的数据在 B 表中没有,那么就代表数据在昨天没有被更新;

    经过上述逻辑后,将更新后的全量数据放到 A 表的 T - 1 分区中,成为了 T - 1 的全量数据,按照这一规则,每一天的全量数据都会被保存一份。

    完成数据更新后 B 表就可以被丢弃了。

    4.7.2 全量型

    假设表不是很大,而且数据状态会发生变化,可以进行全量采集,采集所有数据。此表格每天一个快照,累计时间长了之后,数据量也会很大。

    数据仓库中的表格 Dw_a 按照日期进行分区:
    在这里插入图片描述
    每个分区中保存的是全量数据(全量快照)。不论是全量抽取还是增量抽取,每个分区Dt 中保存的都是截止到当日最后一刻,这张表的快照。

    05-09 是 5 月 9 号的全量快照,5 月 10 号时,采集当天的增量数据 A_incr-20180510, 然后用增量数据 A_incr-20180510 和 Dt=2018-05-09 中的数据进行合并,写入 Dt=2018-05-10 分区中,这样就能保证 0510 是全量数据。如果没有发生变化,那么 5 月 10 号的快照和 5月 9 号的快照是一样的。
    在这里插入图片描述
    所有的表都可以采用这种方式,但是我们考虑,如果表的数据不是很大,那么使用全量采集也没有问题,但是随着数据量的不断增加,每天进行全量采集的代价越来越高,此时可以考虑使用增量采集。例如订单表,本身数据量很大,变化周期长,那么可以直接采用增量采集。

    展开全文
  • 因此,对数据埋点的精确设计和高效采集可以说是每个希望通过数据驱动增长的公司所需重点关注的。源头数据有问题,一切的后续动作只会是空中楼阁。本篇文章讲分享自己在了解神策的数据埋点之后,对数据埋点设计过程中...
  • 数据埋点是什么? 数据埋点数据产品经理、数据运营以及数据分析师,基于业务需求(例如:CPC点击付费广告中统计每一个广告位的点击次数),产品需求(例如:推荐系统中推荐商品的曝光次数以及点击的人数)对用户...
  • 我是wilton,华仔。1.曾任职科大讯飞,现任富力环球商品贸易港数据中台产品负责人。...本文我们以电商产品的商品详情页为例,介绍如何做用户浏览以及点击行为的数据埋点。案例中包含一个页面(商品详情页)...
  • 本文整理自火山引擎开发者社区 Meetup 第四期演讲,主要介绍了字节跳动流量平台的埋点内容解决方案和埋点链路解决方案,揭秘了流量平台如何支撑起字节跳动万亿+的实时数据处理。作者|Cody...
  • 数据埋点(转载)

    千次阅读 2020-03-16 22:50:48
    第一章:初始埋点 第二章:埋点之前 第三章:设计埋点 ...数据埋点数据采集的一种重要方式,主要用来记录和收集终端用户的操作行为,其基本原理是在App/H5/PC等终端部署采集的SDK代码,当用户的行为...
  • 数据埋点实现

    2021-08-27 17:47:36
    文章目录数据埋点整体流程数据采集数据传输数据存储数据统计分析数据可视化 整体流程 采集流程 架构图 数据采集 立方体模型 立方体建模是为了细化采集指标,最大限度得复用数据,减轻埋点工作量,统一埋点...
  • 数据分析之埋点方案

    千次阅读 2020-07-28 19:20:48
    一、前言  ...而埋点作为一种重要的采集手段,可以将用户行为信息转化为数据资产,为产品分析、业务决策、广告推荐等提供可靠的流量数据支持。 在业务需求少的情况下,可以运用一些简单的方法...
  • 埋点设计思路 - 基础知识和设计流程 一. 埋点 埋点:又称为事件追踪(Event Tracking),指的是针对特定用户行为或事件进行捕获,处理和发送的相关技术及其实施过程。 功能方面,埋点是用来收集用户行为数据。...
  • 如何埋点获得数据并进行数据分析

    千次阅读 2019-11-27 09:09:32
    一、埋点是什么? 数据分析的前提是数据。对于电子商务平台来说,数据分为以下几类:1、用户基本属性数据 ...通过埋点(也可通过定制access Log)就可以取得这部分数据。 通常是业务方、PD、BI,...
  • SaaS数据埋点模型设计

    2021-04-24 15:09:49
    企业 企业ID 企业名称 用户 用户ID 用户姓名 浏览器 厂商 版本 ...模块数据 子模块 子模块名称 操作 操作id 页面 页面数据 页面地址 页面版本 数据 数据版本 自定义指标 met...
  • 本文由作者董小矿于社区发布前言:本篇是从数据产品经理如何设计、管理和应用埋点的角度重新整理的文章,其中:1.埋点类型、2.1新增埋点设计、2.3产品指标地图部分的内容,与本人之前的文...
  • 我的个人见解,埋点数据化的体现,数据化的定义回到最初,都是对时间,空间的定义,最简单的的埋点描述,就是基于时空论法则的什么人在什么空间什么时间段做了什么事。 既然如此,数据表的定义就可以给出,比如...
  • 近日,神策数据依托服务的 1000 余家企业客户的数据采集实战经验,将沉淀的企业数据采集埋点的最佳实践通过《企业埋点体系搭建方法论及实践经验》白皮书分享给广大企业或数据分析爱好者,颇受好评。 现如约发布备受...
  • 用户行为埋点是用来记录用户在操作时的一系列行为,也是业务做判断的核心数据依据,如果缺失或者不准确将会给业务带来不可恢复的损失。闲鱼将业务代码从Native迁移到Flutter上过程中,发现原先Native体系上的埋点...
  • sa-sdk-java 神策简介 神策数据 (Sensors Data),隶属于神策网络科技(北京)有限公司,是一家专业的大数据分析服务...SensorsAnalytics SDK 是国内第一家开源商用版用户行为采集 SDK,目前支持代码埋点、全埋点、Ap
  • 服务端埋点系统设计

    千次阅读 2020-04-07 18:27:03
    所谓“埋点”,是数据采集领域(尤其是用户行为数据采集领域)的术语。指的是针对特定用户行为或事件进行捕获、处理和发送的相关技术及其实施过程。 埋点的技术实质,是先监听软件应用运行过程中的事件,当需要关注...
  • 1.序篇-先说结论宝贝们,还记得前几天博主去的火山引擎大数据场嘛,其中比较令大家感兴趣的就是最后一讲,字节一站式埋点平台的 flink 标准化清洗及拆流任务。其中大家感觉比较流啤的就是的就...
  • 数据埋点方式

    2020-04-28 15:41:41
    需要做的数据分析的场景,设计数据需求,撰写数据需求文档,然后交由开发在每个需要采集的数据点写入代码,通过写入的代码进行数据监测与上报 优势 :1. 同时适用于客户端与服务器端数据采集 2. 可进行多维度属...
  • 前端监控和前端埋点方案设计 在线上项目中,需要统计产品中用户行为和使用情况,从而可以从用户和产品的角度去了解用户群体,从而升级和迭代产品,使其更加贴近用户。用户行为数据可以通过前端数据监控的方式获得,...
  • 用户行为数据分析——数据埋点

    千次阅读 2020-04-09 16:25:28
    在用户行为数据分析当中,我们常用的采集数据方式有两种,一种是埋点数据,另一种是无埋点技术,我们今天主要来分析一下埋点技术与无埋点技术的优劣势,他们的之间的特点及其使用场景。在这篇文章里面,我会对数据...
  • 数据分析——埋点
  • 前端页面数据埋点

    千次阅读 2020-09-11 23:05:02
    书中写到在项目上线后,通过数据监控发现: ...我们需要对页面进行各种数据埋点,从数据的角度研究需求的实际效果、用户的实际行为和后续的改进措施。 一、埋点 1)PV和UV PV:Page View,页面访问次数
  • 数据埋点之神策全埋点总结

    千次阅读 2019-09-11 14:28:57
    数据埋点之神策全埋点总结项目介绍埋点流程功能快捷键合理的创建标题,有助于目录的生成如何改变文本的样式插入链接与图片如何插入一段漂亮的代码片生成一个适合你的列表创建一个表格设定内容居中、居左、居右...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 12,106
精华内容 4,842
关键字:

埋点数据表设计