从“埋点技术已死?”开始说起

大数据时代的到来意味着数据量的爆炸,也意味着收集数据的难度将大幅增加。为了将海量的数据收集起来,埋点技术应运而生。然而随着大数据的发展和深入,用户的要求越来越高,埋点技术开始变得力不从心。

近期,一些公司开始以“无埋点技术”为卖点,开始到处宣传无埋点比埋点好,那么到底事实如何了?

埋点技术的时代

埋点技术通过在代码的关键部位植入统计代码,追踪用户的点击行为;或者植入多段代码,追踪用户的连续行为;并通过建立模型等方法,得出用户操作行为;最终作为建立产品数据系统的一个环节准确的收集数据。

那么为什么通过埋代码就可以准确的收集数据呢?

原因有三:

  • 首先,每个操作的界面都有其独立的标示性,具有无重复性,利用此可以统计访问、访客等;
  • 其次,每个界面的事件针对当前页面都是独立的、唯一的,相互之间具有独立性,对此进行埋代码后可以统计事件行为;
  • 最后,在任一界面都会有一个或者多个事件,每个事件会有不同的参数,每个事件参数都具有完整性,在埋点后通过建模可以得出准确的数据,最终目的是为未来产品优化方向做指导的。

这是笔者在以前公司时候,写的前端代码:

<%= link_to "全部雇员#{corp.staffers_count}", employees_corp_path(corp.pretty_abbrev, from: 'corps_detail_all_employee'), class: 'more', onclick: "addGaTrackEvent('corps_detail','goto_all_employee','corps_detail_right')" %>

       像这样addGaTrackEvent的onclick事件几乎遍布整个项目,而且因为浏览器的兼容问题,有时候还不得不采用这种简单粗暴的方式添加“埋点”


埋点技术的弊端 

其实,从上面的代码就看出了这种“埋点技术”的弊端,

  • 首先,IT人员在埋点的时候,必须先清楚要收集的是什么数据,这些数据用来做什么,在什么地方收集这些数据,而且往往会导致代码的丑陋。
  • 其次,一旦数据有问题,想要纠正则需要重新进行埋点,使得之前的工作变成无用功。
  • 最后,埋点增加了测试的难度,需要考虑业务其外的东西。

所谓无埋点技术,并非完全不用埋点,而是不用在设置代码前先行定义需要采集的事件或功能

大多对于可交互式的应用程序,例如Android应用,iOS应用,网站,Windows Phone应用,Windows的窗体程序、Java的窗体程序等等,其实在界面渲染时都有几点共性:

  • 图形背后都有图形树,我们所看到的输入框、文本框、按钮等等其实都是view,而view的摆放其实也都是有对应的视图方式,例如线性布局、网格布局、表格布局、相对、绝对等等,然后view加布局就组成了我们要看到的界面,比如最简单的就是网站的DOM结构了,有层级关系,对于Android而言就是View视图的层级关系了,调用系统级API基本上都能获取这个树结果。
  • 窗体都有生命周期,比如Android的Activity的生命周期
  • 对于我们可视的这些界面元素,当他们显示出来、被点击了、被选中了、被滑动等等操作的时候,系统也都会有相应的接口给开发者通知他们去处理,所以也就是对于View而言可以绑定或者委托或者是监听他们的一些触发事件,比如刚刚提到的加载、点击、选中等操作。

讲到这里,应该很清楚了,应用程序在呈现程序界面的时候,其实有一套生命周期的准则在里面,控制了从界面元素创造到响应用户操作到销毁,同时也有一个图形树的准则在里面,控制了这些界面元素的显示层级和顺序,最后在用户交互(包括展现)各个界面元素的时候,会给开发者提供一系列的接口,让开发者去处理这些行为。

所以原理清楚了,后续无埋点其实也就能想到怎么做了,现在市面上主流有两种,一种是预先跟踪所有的渲染信息,一种是滞后跟踪的渲染信息。两种做法不太一样,后者要简单一些,前者要重一些,但是也有一些办法优化(不交互的元素肯定多于交互元素),各家也就都有自己的方法在里面。

无埋点技术的弊端:只看数据采集的方式,而不考虑数据的传输,存储,分析,可视化反馈,都是耍流氓。

因为你根本没办法定义“所有的信息”。抓取的信息越多,也就意味着浪费的流量也越多,存储和索引的成本也越高。

信息检索有一个最关键的概念是 precision/recall。无埋点是尽可能地提高 recall,而这个成本一部分是终端客户承受,另一部分是在 SaaS 服务的数据管线上增加压力。对于 PC 端的应用,这可能不是问题。但是对于移动端的应用,这就意味着更多的移动数据成本和耗电,此外还有相关的隐私风险。

时间: 2024-12-23 08:03:48

从“埋点技术已死?”开始说起的相关文章

是SEO技术已死,还是你不懂SEO?

中介交易 http://www.aliyun.com/zixun/aggregation/6858.html">SEO诊断 淘宝客 云主机 技术大厅 现在各个博客的SEO文章同质化比较严重,因为SEO被大家都写烂了,写来写去无非就是内容.外链.用户体验. 但我总是看到很多人评论说SEO技术已死,我实在忍不住想写一下. 这些人为什么这么说?无非就是天天写原创或伪原创,发点小外链,然后发现TMD排名怎么还没变化?还是那个样?然后就想,SEO技术果然不行. 当然,更多的人是因为说,现在百度竞价和

互联网已死-大数据的未来在哪里?

一.大数据的未来在哪里 1.互联网已死 大数据的未来在哪里?以BAT为代表的互联网公司之外是否还会有新的互联网巨无霸诞生,基于技术和资本两方面的考虑,几无可能,未来的互联网世界只能是一个几家独大,行业细分的市场,新生互联网公司的机会在于细分,而不在于挑战传统互联网巨无霸.具体到大数据应用来讲,大数据在互联网行业的应用也必将是一个行业细化的过程,而BAT的触角几乎无处不在,新公司的崛起任重而道远,大数据发挥价值的空间也就变成了BAT手中的玩具. 2.传统行业才是大数据的春天 大数据向传统行业的渗透

SEO已死? 好的SEO策略与优质内容依然有效

Chris Dixon写了篇文章<SEO已死:创业企业难用SEO获取更多浏览>,称搜索引擎优化已经不再是创业企业的一种可行的营销战略.原文在这里.(作者是美国消费创意网站Hunch联合创始人.投资了Skype.Foursquare与StackOverflow等创业网站.) Chris Dixon的论点是: 1. 虽然当今多数成功的资讯网站最初的增长都很依赖SEO,包括Yelp.维基百科.但是在他进行过沟通的很多创业企业中,几乎没有一家在2008年后通过SEO获得过很多流量. 2. 开展激进SE

数据库已死

现代软件和以往传统软件主要区别在于:现代软件基于internet互联网技术,运行于开放的网络环境,不象传统软件只是运行在封闭的局域网,运行环境的区别就决定了软件操作用户的多少,在一个开放互联网环境, 你的软件系统用户是不断增长,特别是那些对所有人群开放的社区网站系统,更是承受前所未有的访问负载.那么,这些软件系统承受的压力主要会集中在软件的哪个环节呢?如果你使用传统软件的设计思路,那么无疑压力都集中在数据库上. 随着用户的爆发量增长,在某个凌晨醒来时,你发现:数据库已死. 传统软件系统实则应该叫

2012,独立B2C已死!天猫战后观格局

虎嗅注:在整整半年前的5月13日,电商分析师李成东为虎嗅(那时还未正式上线)写了第一篇文章,题目是<传统零售公司或将面临柯达命运>,谈到电子商务渠道对传统零售渠道商的灭顶式冲击.在这半年里,我们看到京东作为新兴B2C与传统零售大佬苏宁的对决,看到天猫淘宝创下一日狂卷191亿元的全球零售单日记录. 对未来不能再迟疑. 而当下的电商格局是怎样的呢?在虎嗅上线半年之际,李成东应虎嗅之约写出这篇"电商年度观察",希望对大家理解该产业有所帮助. 他的主要观点是: •独立B2C已死.

病毒已死!钱盾构建“全流程屏障”治理黑灰产业

"病毒已死!" 11月8日,在2017国际反病毒大会上,阿里巴巴集团安全部技术副总裁杜跃进博士演讲时表示,"在PC时代,病毒是最大的安全危害:但是进入到互联网时代,病毒本身带来的威胁已经是过去式,当前最大的安全威胁来自于利用病毒等多种技术手段运作的网络黑灰产业." 阿里巴巴集团安全部技术副总裁杜跃进博士在会上进行专题分享 杜跃进博士指出,当前网络黑灰产从业人员超过150万,产业规模高达1000亿元,已经从原来结构松散.手段低级的小团伙,发展成一个相互依存.相互合作的

OOP已死,AOP为未来而生(.net+java)

OOP已死,AOP为未来而生   未来用于构建复杂的基于服务的应用将是面向方面编程AOP(Aspect-Oriented Programming),而面向对象编程OOP将成为辅助.   •控制反转(IOC:Inversion of Control)模式.这个通用模式描述为支持插件架构,其中的对象可以"查询",他们需要的其他对象的实例方法.•依赖注入(DI:Dependency Injection)模式.这是IoC模式一种特殊情况,是基于改变类行为的接口编程技术,而不改变类的内部.开发人

[译] 跨站请求伪造已死!

本文讲的是[译] 跨站请求伪造已死!, 原文链接:Cross-Site Request Forgery is dead! 原文作者:Scott 译文出自:掘金翻译计划 译者:XatMassacrE 校对者:newbieYoung,DeadLion 跨站请求伪造已死! 在连续不断的被跨站请求伪造折磨了这么多年后,我们现在终于有了一个合理的解决方案.一个对网站拥有者没有技术负担.实施起来没有难度.部署又非常简单的方案,它就是 Same-Site Cookies. 和互联网历史一样悠久的跨站请求伪造

研发周报:API已死,API永存!

研发周报:API已死,API永存! 发表于2013-03-15 13:18| 次阅读| 来源CSDN| 0 条评论| 作者夏梦竹 研发周报apiGitHub开源编程语言 摘要:我们精心为您准备了CSDN研发频道一周最精彩的技术热点,以飨读者!本周看点:前Google资深研究员赵勇回国创业分享计算机视觉/模式识别经验谈:TIOBE 2013年3月编程语言排行榜,Java.Objective-C依然强劲,Ruby反超Perl:Meteor--让实时Web App成为主流:API已死,API永存等.