深度解密用户数据埋点采集技术 | 您的行踪已曝露
优采云 发布时间: 2020-08-04 08:00据说可视化埋点是可以解放程序员的。当然,这只是理想状态,不然程序员就都待业了。 涉及到业务属性的数据,如订单号、金额、商品数据等须要调插口的埋点,可视化埋点就难以支持了。此外,由于各个端的代码结构各不相同,也未必都能可视化获取所有元素,这也是可视化埋点的局限性。
总而言之,可视化埋点只是个辅助能力,重点就在于可视化。能够满足一部分需求,解放部份生产力。但是稍稍复杂一些的埋点,还是须要编码来完成。
三、目前主流的数据上报技术
前面论述了客户端的埋点技术,下面再来介绍一下主流的上报技术。
3.1 客户端主动上报
无论是 APP 还是浏览器,我们都可以统一叫做客户端。大多数情况下,客户端是通过 HTTP 请求,将数据上报给服务器的。APP 或桌面软件使用相应的程序语言发送恳求,而网页通常使用 Java 脚本语言发送恳求。
这个过程可能发生在用户刚才步入界面时,也可能发生在用户离开界面之前,或者用户执行某个动作时上报,或者在用户无感知的情况下间歇性上报。
图片来自 @姬小光
具体的上报时机选择各有优劣,需要在统计的实时性、服务器压力、数据的准确性之间进行权衡。比如:如果把数据攒一部分再上报,虽然效率提升了,服务器压力也小了,但是丢数据的风险就增强了。
这里可以解释有些时侯数据为何会不确切,因为客户端上报是要通过网路发送恳求的,请求过程可能会遗失数据,称作丢包。再例如极端情况下,客户端刚想发送数据到服务器,但是网路忽然割断了,这时候假如联网时没有重试机制,或者不再联网,那这部份数据必然是统计不到了。
如果是网页端的 Java 脚本上报,还会存在诸如页面的其他业务逻辑出错造成脚本不再执行,或者页面关掉前 onbeforeunload 事件未执行等等。总之,要接受一定程度的上报偏差,只要偏差在可容忍的范围内即可。
3.2 服务端获取信息
在网页中,用户首次见到的一切,都是从服务器返回的(APP 不同,因为部份界面和逻辑早已安装在了用户的设备上,展示这部份界面不需要网路恳求)。那么服务器在应答你的客户端恳求的时侯,也能领到一些基本信息,比如你的浏览器类型、版本号、屏幕分辨率、IP 地址等等。
这些也可以作为基本的剖析数据,比如业务中的网页究竟要兼容什么设备,就可以先参照一下这种统计数据,看看是否要舍弃兼容这些占比特别小的浏览器或设备。
这些数据有部份是可以通过页面中的脚本语言获取,再“异步”上报给服务器的。所谓“异步”,即并非在你访问网页的顿时执行,而是有延迟,异步执行的逻辑。除了服务器能获得的那些基本信息外,其他信息都要通过上文论述的埋点技术获取,并异步发送给服务器记录了。
四、基本的辨识剖析方式 4.1 设备唯一性
前面讲过,设备的基本信息是可以获取的,但是也可能被伪造。那么究竟如何才算是一个真实的设备呢?
至于具体的算法,基本都是依赖设备的 MAC 地址,以及其他辅助信息生成的,具体不展开。
4.2 用户唯一性
同理,用户倘若不加足够的验证条件,也是很容易被伪造的。因此,就要有针对用户的唯一性判定。
我们可以为用户也分配一个惟一 ID,可以叫 uid,uuid,unionId 什么都可以。那么,这个惟一其实是理想状态,根据具体实现不同,我们能做到应用内惟一,业务内惟一,跨业务惟一,全网内惟一等等。
网站数据统计中常说的 UV(Unique Visitor)独立访客,就是指这个惟一用户的访问计数。而 PV (Page View)访问量,就是用户每次打开某个页面的计数。
4.3 用户行为剖析
用户行为剖析这个概念很大,这里简单介绍几个概念和原理,方便你们理解基本的用户行为剖析是如何实现的。
4.3.1 鼠标轨迹
前面介绍过键盘风波的记录原理,那么键盘轨迹记录也很简单了,只要测量到键盘联通,就把当前的位置记出来,再择机发送给服务端即可。
鼠标轨迹的意义,在于看出用户的苦恼与迷茫,思考过程中手部下意识的联通,和真的挪过去又舍弃点击,都可以在一定程度上,根据键盘位置和间隔及逗留时间推断下来。
我们都晓得用户的浏览次序是有统计规律的,所以通常网页的核心信息构架都设计成 F 形。但是用户端没有眼动仪,要想追踪用户的浏览过程是不可能的,除非你黑掉用户的*敏*感*词*。此时,鼠标轨迹的意义就是帮助剖析用户的思索过程,属于用户研究的范畴。
鼠标轨迹再结合逗留时间,就成了一副抽象派的艺术作品,用来做艺术创作也是不错的:
图片来源于网路
4.3.2 关键路径
有些时侯,我们除了希望晓得用户在某个页面是如何操作的,还希望晓得用户在整个网站或应用中的操作流程是如何的,具体从那个界面跳到了那个界面,最后在那里转化,在哪里离开的。然后再按照这种数据优化网站或应用的的关键路径,提高转化率。
上文提及过单个 tag 的上报原理,那么若想记录路径,就须要记录多个节点或操作。这些操作可能是在一个网站或应用中,也可能跨越了不同的网站和应用。无论哪种方式,都要保证这个数据可以仍然传递下去,才有可能记录路径。比如,如果是不同网站之间的传递,可能就须要通过在网址前面附加参数来实现:
图片来自 @姬小光
具体流程如下:
图片来自 @姬小光
访问页面 1 时参数为:
?rel_id=page_1
离开页面 1 访问页面 2 时的参数变为:
?rel_id=page_1,page_2
离开页面 2 访问页面 3 时的参数变为:
?rel_id=page_1,page_2,page_3
如果几个页面不是同个系统,你只能掌控落地页,即 PAGE_3,那么链接上带的参数也足够说明用户的访问路径了。如果路径中的页面你都能掌控,那么也可以依据设备惟一 ID 或者 用户惟一 ID 加上访问的时间次序来确定用户操作路径,即服务器领到的访问记录为:
用户访问了 ?rel_id=page_1用户访问了 ?rel_id=page_2用户访问了 ?rel_id=page_3
这种情况下页面 123 中都须要埋入上报代码,每个页面只上报自己的 URL 即可。上报逻辑应尽可能多地上报原始数据,比如可以附加当前页面的逗留时间等,方便日后进行更复杂的数据剖析。
4.3.3 转化率
路径剖析的目的就是要提升转化率,那么程序逻辑上怎么定义转化率呢?我们先来瞧瞧转化率的定义:
在网站分析中,转化率通常的定义是,实现设定目标的次数,与访问次数的比值。
可见,定义的关键在于分母,即达成目标的次数。我们的目标可以是下单、购买、或者抵达某个页面。如果是抵达页面,那么每一步的页面跳转都有一个转化率,剩下的就是蹦失率,或者叫跳出率了。要想提升转化率,不仅要在落地页(Landing Page)上下工夫,关键路径的优化也很重要。
因此,在关键路径数据的基础上,单独剖析某个页面的抵达次数,可以估算转化率。或者,如果想通过下单或支付来估算转化率的话,一个简单的办法就是,看用户是否抵达了“下单成功”或者“支付成功”页面,并且上面有合理的依赖路径。当然,最准确的方法还是以实际的订单数据和支付数据为准。
五、主流的统计平台及工具
目前互联网上已有诸多成熟的数据统计平台及工具,各家都有自己独到的特性和优势。也有许多公司会考虑自建平台,但不知是否可行,本章将探讨其优劣。
5.1 数据剖析平台
目前主流的 APP 或网站统计平台有:GrowingIO、神策数据、MTA、百度统计、谷歌剖析、诸葛IO、友盟等等。具体你们可以去官网了解,这里不做介绍。
5.2 行业剖析报告
还有许多行业剖析报告的平台,底层也是通过大数据+AI 分析出更高维度的推论,供你们查看。比如艾瑞咨询的数据报告,相信做互联网的同学们都有自己的百宝箱,这里也不赘言。
5.3 自建数据平台的优劣
最后谈谈自建数据平台的优劣。首先,业务数据是敏感数据,接入第三方就要放宽心把数据交给其他平台。而自建平台就没有这个忧愁。其次,第三方平台似乎提供了好多强悍的功能,但未能实现多样化的统计剖析。容易深陷进退两难的窘境。而自建平台灵活性就高好多,但是对人员和资源的要求相对较高。
最后,无论是使用第三方平台还是自建平台,都是逗留在工具层面,若想真正得出有价值的推论,需要资深的数据剖析人员来剖析这种数据。就算是 AI 也要有科学的剖析模型做指导,才能根据正确的路线学习进化下去。
综上,我觉得假如是起步阶段的公司,建议直接使用成熟的平台,基本可以满足需求。如果是成熟的大公司,建议自建和外部同时使用,一方面可以满足多样化需求,一方面可以借鉴外部工具的优点,取长补短,综合参考。
总结
最后,结合上面的知识,我们再回到文初的两个小故事。
No.1 神秘的建行按揭额度
故事中学,招商银行之所以打电话给我,定是在“e招贷”页面进行了埋点上报,并标记为关键操作。如果某用户浏览过这个页面,就将其打标为“缺钱,亟需用钱”等。在营销管理系统中,再将这批用户筛选下来,由营销人员逐个打电话推销产品。
No.2 数据统计差别的迷思
故事中学,数据的差别是如何形成的?
首先,两家平台对用户访问的定义可能不同。本例中百度是统计的用户打开页面算一个访问,而我们自建平台则是定义为有一个设备惟一 ID 进来,算一个访问,这里就形成了差别。
此外,如果是点击按键后打开一个新页面,那么这儿有两个动作,一个是点击,一个是步入新页面,这里的统计口径也可能有差别。
最后,前面 3.1 小节提及了上报时机的权衡,就是由于上报时侯可能会丢数据。比如用户的网路突然断开,还有网路传输过程的丢包,这也会导致一定的差别。所以,遇到这些情况,只要确定逻辑上没有败笔,并且统计口径一致,是准许一定程度的不一致的。
Q & A 网友提问
问:为什么百度微软的搜索结果点击以后就会跳转一次?
答:因为搜索引擎无法主动在我们的页面嵌入统计代码,所以通过跳转带参数的方法(4.3.2), 在中间页进行数据埋点上报操作。
问:为什么所有的约请链接里面都有一串乱码?
答:邀请机制重点在于记录约请关系,那么当你把链接分享给他人,别人再打开的时侯,系统怎样晓得是你分享的呢?这就是链接上的乱码参数的作用。为什么是乱码?这是因为系统希望晓得是谁约请的,但是不希望其他人可以自己破解并篡改参数。比如活动 ID 如果是数字,就可以随意更改,访问其他可能不想使你看见的活动。领券 ID 如果是自增数字,就可以遍历数字发放所有本事领的券。
问:为什么不同系统统计下来的 PV,UV 会不同?
答:根据前文所述,可能有五种缘由:
埋点逻辑不同; 上报机制不同; 统计口径不同; 程序错误; 人为错误。
首先要明晰双方的统计口径,比如是否都以服务端日志统计到的页面打开次数为准,还是以页面脚本上报的打开次数为准。再看上报逻辑,有没有可能错误率不同,或上报的数据不一致。然后再排查系统逻辑是否有问题,或是否有改动。最后,再看是否在统计时发生了人为的错误造成最后统计结果出错。
问:为什么外投广告的展示次数我们统计不到?
答:根据前文所述,若想能埋点上报,首先要嵌入基础的代码。而外投的广告都是在其他平台,一般情况下难以在外部页面嵌入代码,比如:朋友圈广告的展示。
问:如何统计外投广告的真实数据,防止被误导?
答:如果外投位置可以配合埋入代码,或者展示的时侯可以恳求我们自己的资源(图片、视频),或者主动调用我们的插口,那么可以作为辅助参考数据。但这个也可能作假,所以最好是 修改统计口径,比如以实际抵达我们自己的落地页为计费规则全自动采集最新行业文章,或者是 CPS 方式,记录引流,然后以我们实际的成交量为准计费。
问:我们的手机是如何被判断为异常设备的?
答:我们晓得有些设备会被陌陌或百度等判断为异常设备,而拒绝使用其帐号。先不管这个设备究竟做了哪些,我们只说些基本的检查规则。如果是陌陌本身,那么最基本的,账号发的恳求中设备信息是否完整,是否真实设备,设备是否时常登陆过多帐号,设备是否常常换 IP,设备是否有位置变化等等,都是考虑诱因。
还可能依据关联帐号体系的行为共同检查,比如关联的 QQ 号是否有异常。总之,一家公司自己的 APP 矩阵,是可以把数据共享,综合上去判断一台设备的行为的。比如百度系,头条系等等。
问:为什么随意一个网站上都能推荐我在天猫搜索过的商品?
答:网站接入了网店的广告,即这个网站嵌入了网店的代码,那么假如你之前在天猫浏览过个别品类,就会被记录出来,在这种网站中再度推荐给你相关的商品。同样,搜索的相关推荐也一样,你在百度搜了些东西,然后看好多网站就都有这种字样,甚至有时可能有点难堪。
问:我们的数据还有安全可言吗?
答:这个灵魂叩问,可以这样理解:首先,你在网上的一切数据,都只是存在远程的另一些笔记本里。比如建行流水算隐私了吧?
即使通常的建行职员没权限看,银行的 DBA (数据库管理员)总不能闭眼睛操作吧?安全是相对的,互联网公司通常会将用户隐私数据加密储存,普通职工肯定是看不到的,只有拥有相应权限的人员能够看见,所以 总体上可以说是安全的。除非极端情况,比如黑客攻击全自动采集最新行业文章,内部管控问题等。