您的位置: 长宁信息港 > 金融

警惕网站分析监测实施的陷阱上

发布时间:2019-10-13 05:03:05

  警惕站分析监测实施的陷阱(上)

  A5任务 SEO诊断选学淘宝客 站长团购 云主机

  【前言】

  近忙着东游西逛,所以忙中偷闲写东西有些不易,就暂时不准备长文了,大家看着也轻松点。在美国有段时间了,不是不爱国,但挺喜欢这个国家,特别是素不相识的人见面都对你微笑say hello how are you的时候,感觉在异国他乡有温暖。咳,我是有些乐不思蜀了。

  今天暂时不接着上次关于报告的话题继续谈,而是开始一个新的话题,谈一谈站分析的监测实施,因为近也在学习这个领域,勾起了一些回忆,想起自己刚刚入手站分析时所犯的那些实施小错误,正好是梳理一下的时候。本来准备一个文章就搞定,结果一写,发现没那么简单,所以又只好开上下篇了。

  【正文】

  站分析之所以能够实现分析,在于获得了站访问者的行为数据。但是,我从来没有遇见过一种情况,那就是做到了100%地获得了分析所需要的全部数据。相信我,没有,从来没有,无论谁都无法做到,因为有些东西是后知后觉的,你不能在事前百分之百预料到你所需要的数据。

  不过,这并不意味着你可以放弃对更全面更准确数据的追求,拿破仑也无法每次都预料到他将面对的全部战斗细节,但没有那次他不是事前做到准备的。你也是站分析的常胜将军,所以你需要在事前做到,不然很有可能在站分析的站以上一败涂地。

  所以,无法否认,站分析的监测实施异常重要,甚至比如何进行分析本身还要重要。

  下面,我要谈一些我常常遇见的站分析实施中的陷阱,有些可能老生常谈,但对于初学者却很有价值。请注意,下面所写的每个都可以作为监测实施前对站进行检查的扫描列表,在这个系列的末尾我也会做一个站实施准备工作列表。另外,我总结的肯定不全面,希望大家能够在评论框中继续补充,谢谢!

  陷阱一:跨域监测

  这是站分析实施时候容易忘记的问题,我次做,完全不知道有这么一回事,现在想起来当时非常傻。

  跨域监测是对Google Analytics而言的一个问题,Omniture并无此忧虑(当然,它有别的跟域类似的地方要注意)。对于Google Analytics而言,如果你要把不同的域(domain)或者子域(sub-domain)的所有监测结果放在一个 报告集合(profile)中,那么你就不能只是直接把不经处理的标准代码放到每个页面上。

  例如,如果、和这三个主域逻辑上其实是一个站,你想让他们在一个报告集合中呈现,就需要在监测实施时做跨域处理。

  方法很简单,选择正确的代码加到页面中就行了。如下图所示(点击看大图):

  相信您一定知道这个截图来自那里。

  不过,由于跨主域监测情况不多见,所以很多时候我们落不到这个陷阱里面去。我们常常出问题的是在跨子域监测上,因为我们误以为这种情况不是特殊情况。

  子域形如:和,都属于这个主域,但是我们也要给他们特殊的代码,否则部分数据就会混乱。例如,traffic source中会出现和这样的referrer,bounce rate之类的数据也会出现不正常。你的相当部分的数据都毁掉了,基本上就无法进行关键的分析了。

  方法跟上面一样,如下图所示(点击看大图):

  陷阱二:报告结构

  既然涉及到跨域和跨子域的问题,那么,如果再多想一下,就会涉及到报告结构的问题了。什么是报告结构?先举个例子,您就明白了。

  假设有一个很大的站,例如,它有各个地区的站,比如、、 ;它也有各个产品细分的站,比如、、 。

  再假设,您是这个公司的站优化部门总监(一个不错的职位,不是吗?),你的内部客户包括CEO、各个区域的总经理、各个产品部门的总经理,他们都想知道站给他们带来了些什么价值。为了圆满解答他们的问题,你需要怎么监测这个站呢?

  这就涉及到不同范围的报告了。对于CEO,我们肯定至少要给他全局报告,因为只有他和为数不多的人(包括你自己)需要看到全面的情况;对于各个区域的老大们,他们只要了解自己地区的站就好了;对于各个产品部门的头儿,他们看自己的产品站也就足够。

  现在假设我们所使用的站分析工具是Google Analytics,这样可以得到至少如下四种解决方法:

  解决方法一(这个方法是我们容易落入的陷阱)

  给每个子站建一个独立的Profile。这种方法的弊端是没有一个全站的profile,所以为了得到全站的情况,只能自己手动加总求和计算。你千万不能这么做。

  解决方法二(这个方法同样是大陷阱)

  为全站建一个profile,当然已经注意了跨子域的问题。这种方法的弊端是没有一个个子站独立的情况,比如的bounce rate是多少?不知道。解决问题的方法还是自己剥离数据慢慢计算。这方法可相当让人难过的。

  解决方法三

  是把每个站都加至少两套代码:一套是全站的统一代码,建立一个总的profile,跟解决方法三一样;第二套代码则是每个子站自己的代码,这样就能有子站各自独立的报告。这个方法比起前面的来,考虑的周全了很多,能够解决不同用户的需要了。但不完美的地方在于代码实施复杂且存在冗余,所以还不算化的方法。

  解决方法四

  这是我认为的方法。原因在于我么能够通过一套代码实现既有总体,又有细分的报告(profile),大家各不干扰,而且数据精确。怎么做到呢?其实不难。

  我们首先从GA上建立好一个profile,并且获取一套跨子域监测的代码。然后,把这段代码实施到站所有的页面上。这之后,真正的tricks开始了。我们在GA报告的settings后台中复制刚刚建立的profile,有多少个子站就复制多少个,然后,做过滤,只留下各个子站自己的流量,过滤的方法请见这里。

  其实,这个解决方法是Google Analytics实施的入门功课之一,请点击这里学习官方的资料,我推崇哦!

  上面的这个解决方法是Google Analytics的,对于Omniture,思想完全一致,而且方法也类似,为不同的站范围建立不同的report suite,实现不同站范围的报告分割 。

  在这个陷阱的,我要说,站监测结构其实挺重要,因为它能让各个部门都满意,而且,还能让你获得一种生杀予夺的快乐 因为只有你一个掌握了全部的秘密。

  陷阱三:页面动态事件监测

  所谓页面动态事件,即我们常说的页面上的非HTML链接的交互式元素,包括flash/flex中的按钮或链接、JavaScript、AJAX、SilverLight、HTML5中的动态事件等,例如下图中hulu的滚动图中的 watch now 就是一个flash按钮。用户访问这些动态事件的行为,不能够直接通过标准代码获得监测数据,因此需要对监测代码做一定的定制。

  这个地方的陷阱在于,一来我们不知道要做额外的定制化监测,二来我们容易出现监测实施失误。

  在Google Analytics中,监测页面动态事件的方法可以用两种方法,一种被称为virtual page,即虚拟页面;另一种被称为event tracking,即事件追踪。前一种方法,把这些动态事件的点击都等同于打开了一个新的页面;后一种方法,则把这些事件单列出来,作为特殊的情况在专门的Content的event tracking报告中体现。

  Virtual page方法需要用_trackPageview()函数来解决问题,语法是: _sh(['_trackPageview','/events/playvideo']); ,之后,这个事件会在content中的top content报告中以/events/playvideo为页面名出现。

  在实施时,把_trackPageview()函数放到这些动态事件的onclick(或者onrelease)事件中即可,如果您不了解如何添加,您的站前端IT同事一定懂得,请教一下他们,这不是大问题。

  Virtual page方法很简单,但是的麻烦在于会inflate(虚增) top content 报告的数据,而且能够监测到的行为属性也就只是点击一种,做更细的分析时不够用。

  为了弥补这个缺陷,Google Analytics开发了另一种更先进的功能,就是已经不再神秘的event tracking功能,语法是: _sh(['_trackEvent','category','action','lable',value]); ,同样是添加到onclick(或是onrelease)事件中,跟virtual page的添加方法非常类似。

  关于这两个功能,GA官方也有说明,请点击这里。

  我们推荐这个功能的原因在于:

  1. event tracking不会把数据放在top content报告中,从而不会混乱这个报告。它有自己独立的报告,如下:

  2. Event tracking的诸多属性很好用,尤其是增加了 value 这个属性,通过它我们可以为不同的动态事件赋予不同的权值(weight),从而能够很自动的计算engagement index。

  3. 属性的增加也带来了更多的细分分析的可能。我们能够据此加强对页面(或整站)动态事件的分析。

  但是,凡是有利有弊,由于多了几种属性,所以朋友们有时候容易出点儿小差错,这些差错已经在Tenly的文章中提及(请注意这个文章是根据GA旧的代码写的,新的代码已经更新了pagetracker对象为:_sh,但是其他没有变)。如果没有尝试过event tracking的童鞋值得看看这篇文章。

  另一个弊端在于,event tracking是没有pathing的,也就是说,不能了解到它们和页面间的路径关系,而只是单纯的计数。用virtual pageview的功能则可以获得pathing功能,尽管不能说非常准确,但聊胜于无。如何取舍,完全取决于您事先的监测需求。

  另外,还需要注意的是,有时候我们会把这个function加到flash的帧,结果造成页面(上flash)载入的同时,会自动运行这个function,而不是在访问者点击了某个动态事件才运行,这实际上是监测实施事故。

  ,event tracking因为包含多个属性,所以你需要注意命名规则的一致性,如果events都是注册,那么就把他们都丢到registration的category去,而不要既有registration的命名,又有register的命名。否则报告就不那么好读了。

  好了,上节书完,虽然都是很基础的内容,但可能大家还是会有不少问题,现在时间留给您,请在留言框给我回复吧!

  下节我们将会涉及的陷阱包括:外链监测、代码冲突、跳转、框架页面、自定义修正等。Stay tuned!

  原文地址:

民生理财
民生理财
通讯
猜你会喜欢的
猜你会喜欢的