[PM]警惕网站分析监测实施的陷阱

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

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

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

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

  • 陷阱一:跨域监测

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

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

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

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

image

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

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

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

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

image

  • 陷阱二:报告结构

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

假设有一个很大的网站,例如sony.com,它有各个地区的网站,比如 china.sony.com、japan.sony.com、gemany.sony.com……;它也有各个产品细分的网站,比如 psp.sony.com、notebook.sony.com、movie.sony.com……。

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

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

image

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

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

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

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

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

  • 解决方法三

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

  • 解决方法四

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

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

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

image

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

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

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

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

image

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

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

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

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

image

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

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

image

image

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

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

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

image eventTracking

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

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

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

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

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

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

来源:http://www.chinawebanalytics.cn/wa-implementation-trap-1/

 

Advertisements

发表评论

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / 更改 )

Twitter picture

You are commenting using your Twitter account. Log Out / 更改 )

Facebook photo

You are commenting using your Facebook account. Log Out / 更改 )

Google+ photo

You are commenting using your Google+ account. Log Out / 更改 )

Connecting to %s

%d 博主赞过: