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

emr_implementation【前言】

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

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

【正文】

  网站分析之所以能够实现分析,在于获得了网站访问者的行为数据。但是,我从来没有遇见过一种情况,那就是做到了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的命名。否则报告就不那么好读了。

 

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

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

未经允许不得转载:版权归宋星及chinawebanalytics.cn所有宋星的数字观 » 警惕网站分析监测实施的陷阱(上)
分享到: 更多 (0)

评论 24

  • 昵称 (必填)
  • 邮箱 (必填)
  • 网址
  1. #-49

    暂时还没遇到以上情况,不过给大家打了个预防针

    Leon14年前 (2010-07-28)回复
  2. #-48

    呵呵!~新手学习ing ,提醒的是。

    DJ14年前 (2010-07-28)回复
  3. #-47

    精彩!

    Ann14年前 (2010-07-28)回复
  4. #-46

    正在测试ga的事件跟踪,很有帮助的文章

    Robbins14年前 (2010-07-29)回复
  5. #-45

    分析的很前沿,不过目前没有碰到过,看了这篇文章眼界开阔了很多,谢谢!

    尘风14年前 (2010-07-29)回复
  6. #-44

    既然virtual page和event tracking都有一定程度上的优劣,那索性就2个profile吧。万一哪天老板或者客户要相关数据了却找不到就乐子大了。
    非常期待下一篇文章。

    Leslie14年前 (2010-07-29)回复
  7. #-43

    首先谢谢大师,其实这个对于做一两年分析的人来说基本都遇见过了。我现在最投放的是不同广告渠道的监测和转化效果跟踪与评估。
    比如:百度来源的流量,需要区分跟踪:付费广告的流量和自然排名的流量,付费又需要分别作关键词、图片以及内容网络的,自然排名跟踪倒是简单些;然后还在要跟踪网址导航渠道,地方门户广告等等。
    同时要对所有渠道数据进行ROI分析,我规则建立出来了,但是很多数据由于各家搜索引擎的不一致,导致在入口统计出现很多问题。
    希望大师可以分享下广告跟踪这块的心得,再次感谢!

    刘良玉14年前 (2010-07-29)回复
    • 能具体给我一个Email说一说你目前遇到的challenge吗?这样有助于我思考从哪个角度写这个文章。谢谢!

      Sidney Song14年前 (2010-08-08)回复
  8. #-42

    正好在系统的看GA的帮助文档,看的云里雾里。
    看到这篇文章终于明白了GA帮助里那些说明的用处。。。。哗~~~

    jane14年前 (2010-07-29)回复
    • 谢谢!你这样的回复我感到非常高兴!能帮到大家的忙是最好的!

      Sidney Song14年前 (2010-08-08)回复
  9. #-41

    介绍的方法都很实用,也是平常都会遇到的问题,期待下篇。

    joegh14年前 (2010-07-29)回复
  10. #-40

    正遇到这个问题,nan

    nono14年前 (2010-07-30)回复
  11. #-39

    请教一个奇怪的问题:
        我网站有2级域名,按解决方法四进行的设置(在“五个实用的Google Analytics过滤设置”已经有朋友提到过滤检测子域流量第五招有问题了)。另一个奇怪的地方是,在全站看到该子域的访问情况,显示也是正常的该子域的URL,但通过GA访问该URL时,奇怪的变成了www.***.com/子域名。好像GA在这里将子域做为了www下的子目录处理。同时在热图上,子域下的页面GA数据出错,没有数据,而WWW下的页面只要涉及了调用子域的,该模块一律没有数据。
         我怀疑是GA在这个地方存在一定的问题,也导致了通过过滤方法统计子域流量有误。
         希望宋兄可以抽空看看,一解心中之惑。

    etopyang14年前 (2010-08-13)回复
  12. #-38

    子域形如:blog.chinawebanalytics.cn和http://www.chinawebanalytics.cn,都属于chinawebanalytics.cn这个主域,但是我们也要给他们特殊的代码,否则部分数据就会混乱。例如,traffic source中会出现blog.chinawebanalytics.cn和http://www.chinawebanalytics.cn这样的referrer,bounce rate之类的数据也会出现不正常。你的相当部分的数据都毁掉了,基本上就无法进行关键的分析了。
     
    我的网站属于这个类型的
    但是在GA分析中,所有浏览页面全部都是www的“`不知道是什么原因造成的,我当时选择的代码是正确的啊

    网站策划14年前 (2010-09-06)回复
  13. #-37

    星哥:
    您好!非常感谢您的博文。我们站采用的就是“陷阱2:报告结构”描述的第一种解决办法。
    但这样有一个问题是:从www域名跳到x 域名,这样算一个跳出。但我们x域名下的内容url都是www开始的。 这样又出现一个情况:从x首页点击其下面的内容也算作一个跳出。
    现在我们在每个统计代码中设置了跨子域跟踪,但设置后,各子域的直接流量飙升了400%…不知设置是否正确?期待星哥解答

    猫爹14年前 (2010-11-24)回复
    • 设置应该是正确的,但是流量来源这一块因为很多流量都是从其他子域来,可能被算入了直接流量。建议用HttpWatch看一下子域到另一个子域时记录的referring有没有改变。

      Sidney Song14年前 (2010-11-26)回复
  14. #-36

    星哥:
    您好!非常感谢您的博文。我们站采用的就是“陷阱2:报告结构”描述的第一种解决办法。
    但这样有一个问题是:从www域跳到x 域,这样算一个跳出。但我们x域名下的内容url都是www开始的。 这样又出现一个情况:从x首页点击其下面的内容也算作一个跳出。
    现在我们在每个统计代码中设置了跨子域跟踪,但设置后,各子域的直接流量飙升了400%…不知设置是否正确?期待星哥解答

    猫爹14年前 (2010-11-24)回复
  15. #-35

    多谢星哥解答,我们的直接流量从11月17号开始飙升,24号恢复正常。。。。如果从其他子域过来的流量被算作直接流量为什么会出现这种情况?

    猫爹14年前 (2010-11-30)回复
  16. #-34

    HttpWatch看子域到另一个子域时记录的referring并没有改变。

    猫爹14年前 (2010-11-30)回复
  17. #-33

    你好!我的网站属于有多子域的网站。在添加ga代码时已经按照上述图中方法了,但是任然出现了从不同子域带来的ref流量,请问可能是存在什么原因呢?

    Z13年前 (2011-09-02)回复