标签归档:Apache日志

网站分析的数据来源

Data-Center   Avinash Kaushik在他的《Web Analytics》一书中将数据的来源分为4部分:点击流数据(Clickstream)、运营数据(Outcomes)、调研数据(Research/Qualitative)和竞争对手数据(Competitive Data)。点击流数据主要指的是用户浏览网站时产生的数据;Outcomes我更习惯叫做运营数据,主要指用户在网站中应用服务或者购买产品时记录下来的数据;调研数据主要是网站通过某些用户调研手段(线上问卷或者线下调研)获取的一些定性数据;Competitive Data直译为竞争对手数据可能不太合适,因为根据Avinash Kaushik的阐述,更像是跟网站有业务关系或竞争关系或存在某种利益影响的一切网站的可能的数据来源。

  在获取上述几类数据的同时,也许我们还可以从其他方面获取一些更为丰富的数据。下面是我对网站分析数据获取途径的整理:

网站内部数据

  网站内部数据是网站最容易获取到的数据,它们往往就存放在网站的文件系统或数据库中,也是与网站本身最为密切相关的数据,是网站分析最常见的数据来源,我们需要好好利用这部分数据。

服务器日志

  随着网站应用的不断扩张,网站日志不再局限于点击流的日志数据,如果你的网站提供上传下载、视频音乐、网页游戏等服务,那么很明显,你的网站服务器产生的绝不仅有用户浏览点击网页的日志,也不只有标准的apache日志格式日志,更多的W3C、JSON或自定义格式的输出日志也给网站分析提供了新的方向。

  网站分析不再局限于网页浏览的PV、UV,转化流失等,基于事件(Events)的分析将会越来越普遍,将会更多的关注用户在接受网站服务的整个流程的情况:上传下载是否完成,速度如何;用户是否观看的整部视频,视频的加载情况;及用户在玩网页游戏时的操作和体验分析等。Google Analytics已经支持了基于事件的分析——Event Tracking,通过JS的动作响应获取数据,但是还存在着一定的局限性。

网站分析工具

  当然,通过网站分析工具获得数据是一个最为简便快捷的方式,从原先的基于网站日志的AWStats、webalizer,到目前非常流行的基于JS Tags的Google Analytics、Omniture的SiteCatalyst,及JS和网站日志通吃的WebTrends。通过网站分析工具获得的数据一般都已经经过特殊计算,较为规范,如PV、UV、Exit Rate、Bounce Rate等,再配上一些趋势图或比例图,通过细分、排序等方法让结果更为直观。

  但通过网站分析工具得到数据也不远只这些,上面的这些数据也一样可以通过统计网站日志获得,但网站分析工具的优势在于其能通过一些嵌入页面的JS代码获得一些有趣的结果,如Google Analytics上的Overlay或者也叫Click Density——网站点击密度分布,及一些其它的网站分析工具提供的点击热图,甚至鼠标移动轨迹图。这些分析结果往往对网站优化和用户行为分析更为有效。

数据库数据

  对于一般的网站来说,存放于数据库中的数据可以大致分为3个部分:

  • 网站用户信息,一般提供注册服务的网站都会将用户的注册账号和填写的基本信息存放在数据库里面;
  • 网站应用或产品数据,就像电子商务的商品详细信息或者博客的文章信息,如商品信息会包含商品名称、库存数量、价格、特征描述等;
  • 用户在应用服务或购买产品时产生的数据,最简单的例子就是博客上用户的评论和电子商务网站的用户购买数据,购买时间、购买的用户、购买的商品、购买数量、支付的金额等。

  当然,这一部分数据的具体形式会根据网站的运营模式存在较大差异,一些业务范围很广,提供多样服务的网站其数据库中数据的组合会相当复杂。

其它

Customer-Service

  其它一切网站运营过程中产生的数据,有可能是用户创造,也有可能是网站内部创造,其中有一大部分我们可以称其为“线下数据(Offline Data)”。如用户的反馈和抱怨,可能通过网站的交流论坛,也有可能通过网站时公布的客服电话、即时通讯工具等,如果你相信“客户中心论”,那么显然对于这些数据的分析必不可少;另外一部分来源就是网站开展的线下活动,促销或推广,衡量它们开展的效果或投入产出,以便于之后更好地开展类似的线下推广。

外部数据

  网站分析除了可以从网站内部获取数据以外,通过互联网这个开放的环境,从网站外部捕获一些数据可以让分析的结果更加全面。

互联网环境数据

  即使你的网站只是一个很小的网站,但如果想让你的网站变得更好,或者不至于落后于互联网的前进脚步,那么建议你关注一下互联网的发展趋势。可以上Alexa查一下互联网中顶级网站的访问量趋势;看看comScore发布的数据或者艾瑞的数据分析报告;如果经营电子商务网站,那么刚刚上线的淘宝数据中心也许会让你感兴趣。

竞争对手数据

  时刻关注竞争对手的情况可以让你的网站不至于在竞争中落伍。除了在Alexa及一些其他的网站数据查询平台以外,直接从竞争对手网站上获取数据也是另外一条有效的途径,一般网站会出于某些原因(信息透明、数据展示等)将自己的部分统计信息展现在网站上,看看那些数据对于掌握你的竞争对手的情况是否有帮助。

合作伙伴数据

  如果你有合作的网站或者你经营的是一个电子商务网站,也许你会有相关的产品提供商、物流供应商等合作伙伴,看看他们能为你提供些什么数据。

用户数据

  尝试跟踪用户的脚步去看看他们是怎么评价你的网站的。如果你的网站已经小有名气,那么尝试在搜索引擎看看用户是怎么评价你的网站,或者通过Twitter、新浪微博等看看用户正在上面发表什么关于你的网站的言论。

  当然通过用户调研获取数据是另外一个不错的途径,通过网站上的调查问卷或者线下的用户回访,电话、IM调查,可用性实验测试等方式可以获取一些用户对网站的直观感受和真实评价,这些数据往往是十分有价值的,也是普通的网站分析工具所获取不到的。

  在分析网站的外部数据的时候,需要注意的是不要过于相信数据,外部数据相比内部数据不确定性会比较高。网站内部数据即使也不准确,但我们至少能知道数据的误差大概会有多大,是什么原因造成了数据存在误差。而外部数据一般都是有其他网站或机构公布的,每个公司,无论是数据平台、咨询公司还是合作伙伴都可能会为了某些利益而使其公布的数据更加可信或更具一定的偏向性,所以我们在分析外部数据是需要更加严格的验证和深入的分析。而对于用户调研中获取的数据,我们一般会通过统计学的方法检验数据是否可以被接受,或者是否满足一定的置信区间,这是进行数据分析前必须完成的一步。

WEB日志的作用和缺陷

log-file  Avinash Kaushik将点击流数据的获取方式分为4种:log files、web beacons、JavaScript tags和packet sniffers,其中包嗅探器(packet sniffers)比较不常见,最传统的获取方式是通过WEB日志文件(log files);而beacons和JavaScript是目前较为流行的方式,Google Analytics目前就是采用beacons+JavaScript来获取数据的,我们可以来简单看一下传统的网站日志和beacons+JavaScript方式各自的优缺点:

WEB日志文件

  优势:简单方便,不需要修改网页代码,可以自定义日志格式;较多的现成的日志分析工具的支持(AWStats、Webalizer等);获取网络爬虫数据的唯一途径;可以收集底层数据供反复的分析。

  缺陷:数据的质量较低,网站日志包含所有日志数据,包括CSS、图片、脚本文件的请求信息,所以过滤和预处理来提升数据质量必不可少;页面缓存导致浏览无日志记录,这个是比较致命的。

beacons+JavaScript

  优势:只需要在页面代码中操作,不需要配置服务器;数据的获取有较高的可控性,可以只在需要统计的页面植入代码;能够获取点击、响应等数据;不需要担心缓存等的影响,数据的准确度较高;可用第三方cookie实现多网站跟踪比较。

  缺陷:当浏览器禁止接收图片或者禁用JS时,都可能导致数据获取的失败;只在应用服务层操作,无法获取后台的数据;对图片、文件等请求信息的获取难度相对较大;过多地JS可能导致页面性能的下降,虽然这方面的影响一般可以忽略。

无论通过何种方式,最终数据都是通过日志文件来记录的,只是通过JS可以更容易控制想要获取的数据,并通过在URL带参数的方式记录到日志文件中共解析和统计。所以底层的数据形式无非就是记录在日志文件中的那几项,在WEB日志格式一文中,已经对网站日志的类型和组成做了基本的介绍,这里就再来解析下WEB日志中各项对网站数据分析的作用,以及存在的不确定性和缺陷。

WEB日志中各项的作用

  根据WEB日志的组成,下面来介绍下各项在网站数据统计和分析中的作用。其中IP一般在为记录cookie的情况下被用于识别唯一用户的标准,标识符和授权用户一般情况下都为空,而日期时间标识日志生成的时间戳,是一个必备信息。

请求(request)

  请求类型比较少会被用于统计,只有少数的统计表单提交情况是会被用到,而版本号对统计来书基本是无用的。

  请求的资源一般跟域名(domain,一般在包含子域名需要分开统计,或者多个站点的日志被收集到同一日志服务器是,会在网站日志里面自定义加入域名信息以区分)一起决定本次请求的具体资源,页面点击、图片获取或者其他。当然在URL后面加入一些自定义的参数可以获得一些特殊的统计数据,Google Analytics就是通过这种方式实现session和cookie的定义和获取的。

状态码(status)

   状态码比较常被用于一些请求响应状态的监控,301页面重定向或者404错误,统计这些信息可以有效地改进页面的设计,提高用户体验。

传输字节数(bytes)

  也比较少被用到,可以判断页面是否被完全打开,文件是否已被读取,操作是否被中断。但在动态页面无法判断。

来源页面(referrer)

  referer涉及的统计较为常见,一般是统计访问的来源类型、搜索引擎、搜索关键字等;同时也是点击流中串连用户访问足迹的依据。

用户代理(agent)

  识别网络爬虫;统计用户的系统、浏览器类型、版本等信息,为网站开发提供建议,分析各类浏览器的使用情况和出错概率等。

session和cookie

  关于session和cookie,可以参考session和cookie的辨析。session被用于标识一个连续的访问,用户统计visits这个度量;而cookie主要用于用户识别,也是统计Unique Visitor的依据。

  另外还有一种特殊的网站日志,即记录服务器的提示、警告及错误信息,这类日志可以被用于分析用户的错误。

日志的不准确性

  WEB日志在技术层面的获取方式及各类外部因素的影响使基于网站日志的数据分析会存在许多的不准确性,下面来介绍下WEB日志中那些项目可能造成数据的不准确,以及造成这些缺陷的原因。

客户端的控制和限制

  由于一些浏览网站的用户信息都是有客户端发送的,所以用户的IP、Agent都是可以人为设置的;另外cookie可以被清理,浏览器出于安全的设置,用户的可以在访问过程中限制cookie、referrer的发送。这些都会导致用户访问数据的丢失或者数据的不准确,而这类问题目前很难得到解决。

缓存

  浏览器缓存、服务器缓存、后退按钮操作等都会导致页面点击日志的丢失及referrer的丢失,目前主要的处理方法是保持页面信息的不断更新,可以在页面中添加随机数。当然如果你使用的JavaScript的方法,那么就不需要担心缓存的问题。

跳转

  一些跳转导致referrer信息的丢失,致使用户的访问足迹中断无法跟踪。解决方法是将referer通过URL重写,作为URL参数带入下一页面,不过这样会是页面的URL显得混乱。

代理IP、动态IP、局域网(家庭)公用IP

  IP其实准确性并不高,现在不止存在伪IP,而且局域网共享同一公网IP、代理的使用及动态IP分配方式,都可能使IP地址并不是与某个用户绑定的,所以如果有更好的方法,尽量不要使用IP来识别用户。

session的定义与多cookie

  不同的网站对session的定义和获取方法可能差异,比如非活动状态session的失效时间、多进程同时浏览时sessionid的共享等,所以同一个网站中session的定义标准必须统一才能保证统计数据的准确。cookie的不准确一方面是由于某些情况下cookie无法获取,另一方面是由于一个客户端可以有多个cookie,诸如chrome、Firefox等浏览器的cookie存放路径都会与IE的cookie存放路径分开,所以如果你是用不同的浏览器浏览同一网站,很有可能你的cookie就是不同的。

停留时间

  停留时间并不是直接获取的,而是通过底层日志中的数据计算得到的,因为所有日志中的时间都是时刻的概念,即点击的时间点。这里不得不提的是一个session的最后一个页面的停留时间是无法计算得到的,可以来看一下停留时间的计算过程:

  假设一个用户在一个session里面依次点击了A->B->C这3个页面,并在点完C之后关闭了浏览器,或者长时间的禁止导致了session的中断。那么我们可以从日志中获得的数据为3个页面的点击时间(HitTime),假设A、B、C点击时间分别为HTA、HTB、HTC,那么A和B页面的停留时间(StayTime)就可以通过计算得到:STA= HTB-HTA,STB= HTC- HTB,而因为我们无法获取session结束的时间,所以STC是无法通过计算得到的,所以一般session最后页面的停留时间是0,而session得停留时间,即一次访问的时间(Time on site)是HTC- HTA,其实是从打开第一个页面到打开最后一个页面的时间间隔,也是不准确的。

  另外,我们也无法获知用户在浏览一个页面的时候到底做了什么,是不是一直在阅读博客上的文章或者浏览网站上展示的商品,用户也有可能在期间上了个厕所、接了通电话或者放空的片刻,所以计算得到的停留时间并不能说明用户一直处于Engagement的状态。

session和cookie的辨析

  session和cookie是网站浏览中较为常见的两个概念,也是比较难以辨析的两个概念,但它们在点击流及基于用户浏览行为的网站分析中却相当关键。基于网上一些文章和资料的参阅,及作者个人的应用体会,对这两个概念做一个简单的阐述和辨析,希望能与大家共同探讨下。

  session和cookie的最大区别在于session是保存在服务端的内存里面,而cookie保存于浏览器或客户端文件里面;session是基于访问的进程,记录了一个访问的开始到结束,当浏览器或进程关闭之后,session也就“消失”了,而cookie更多地被用于标识用户,它可以是长久的,用于用户跟踪和识别唯一用户(Unique Visitor)。

关于session

  session被用于表示一个持续的连接状态,在网站访问中一般指代客户端浏览器的进程从开启到结束的过程。session其实就是网站分析的访问(visits)度量,表示一个访问的过程。

session

  session的常见实现形式是会话cookie(session cookie),即未设置过期时间的cookie,这个cookie的默认生命周期为浏览器会话期间,只要关闭浏览器窗口,cookie就消失了。实现机制是当用户发起一个请求的时候,服务器会检查该请求中是否包含sessionid,如果未包含,则系统会创造一个名为JSESSIONID的输出cookie返回给浏览器(只放入内存,并不存在硬盘中),并将其以HashTable的形式写到服务器的内存里面;当已经包含sessionid是,服务端会检查找到与该session相匹配的信息,如果存在则直接使用该sessionid,若不存在则重新生成新的session。这里需要注意的是session始终是有服务端创建的,并非浏览器自己生成的。

  但是浏览器的cookie被禁止后session就需要用get方法的URL重写的机制或使用POST方法提交隐藏表单的形式来实现。

  这里有一个很关键性的注意点,即session失效时间的设置,这里要分两方面来看:浏览器端和服务端。对于浏览器端而言,session与访问进程直接相关,当浏览器被关闭时,session也随之消失;而服务器端的session失效时间一般是人为设置的,目的是能定期地释放内存空间,减小服务器压力,一般的设置为当会话处于非活动状态达20或30分钟时清除该session,所以浏览器端和服务端的session并非同时消失的,session的中断也并不一定意味着用户一定离开了该网站。目前Google Analytics和Omniture都定义当间隔30分钟没有动作时,算作一次访问结束,所以上图中session的最后一步不只是离开,也有可能是静止、休眠或者发呆的状态。

  还有一点需要注意,就是现在的浏览器好像趋向于多进程的session共享,即通过多个标签或页面打开多个进程访问同一网站时共享一个session cookie,只有当浏览器被关闭时才会被清除,也就是你有可能在标签中关闭了该网站,但只要浏览器未被关闭并且在服务器端的session未失效前重新开启该网站,那么就还是使用原session进行浏览;而某些浏览器在打开多页面时也可能建立独立的session,IE8、Chrome默认都是共享session的,在IE8中可以通过菜单栏中的文件->新建会话来建立独立session的浏览页面。

关于cookie 

cookie

  cookie 是一小段文本信息,伴随着用户请求和页面在Web服务器和浏览器之间传递。用户每次访问站点时,Web应用程序都可以读取cookie包含的信息。

  session的实现机制里面已经介绍了常见的方法是使用会话cookie(session cookie)的方式,而平常所说的cookie主要指的是另一类cookie——持久cookie(persistent cookies)。持久cookie是指存放于客户端硬盘中的cookie信息(设置了一定的有效期限),当用户访问某网站时,浏览器就会在本地硬盘上查找与该网站相关联的cookie。如果该cookie 存在,浏览器就将它与页面请求一起通过HTTP报头信息发送到您的站点,然后在系统会比对cookie中各属性和值是否与存放在服务器端的信息一致,并根据比对结果确定用户为“初访者”或者“老客户”。

  持久cookie一般会保存用户的用户ID,该信息在用户注册或第一次登录的时候由服务器生成包含域名及相关信息的cookie发送并存放到客户端的硬盘文件上,并设置cookie的过期时间,以便于实现用户的自动登录和网站内容自定义。

  Apache自带的mod_usertrack模块可以在用户首次来到当前网站的时候给用户种下一个唯一的cookie(较长时间过期),这个cookie是用户首次来当前网站的IP地址加上一个随机字符串组成的。同时在自定义WEB日志中在最后增加%{cookie}n字段可以实现cookie在apache日志中的输出,用于数据统计与用户跟踪。

WEB日志格式

 apache-log  WEB日志是网站分析和网站数据仓库的数据最基础来源,了解其格式和组成将有利于更好地进行数据的收集、处理和分析。

1、日志格式类型

  目前常见的WEB日志格式主要由两类,一类是Apache的NCSA日志格式,另一类是IIS的W3C日志格式。NCSA格式又分为NCSA普通日志格式(CLF)和NCSA扩展日志格式(ECLF)两类,目前最常用的是NCSA扩展日志格式(ECLF)及基于自定义类型的Apache日志格式;而W3C扩展日志格式(ExLF)具备了更为丰富的输出信息,但目前的应用并不广泛,所以这里主要介绍的是NCSA扩展日志格式(ECLF)。

2、常见日志格式的组成

  这是一个最常见的基于NCSA扩展日志格式(ECLF)的Apache日志样例:

58.61.164.141 – - [22/Feb/2010:09:51:46 +0800] “GET /reference-and-source/weblog-format/ HTTP/1.1″ 206 6326 ” http://www.google.cn/search?q=webdataanalysis” “Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1)”

  可以看到这个日志主要由以下几个部分组成:

访问主机(remotehost)

  显示主机的IP地址或者已解析的域名。

标识符(Ident)

  由identd或直接由浏览器返回浏览者的EMAIL或其他唯一标示,因为涉及用户邮箱等隐私信息,目前几乎所有的浏览器就取消了这项功能。

授权用户(authuser)

  用于记录浏览者进行身份验证时提供的名字,如果需要身份验证或者访问密码保护的信息则这项不为空,但目前大多数网站的日志这项也都是为空的。

日期时间(date)

  一般的格式形如[22/Feb/2010:09:51:46 +0800],即[日期/月份/年份:小时:分钟:秒钟 时区],占用的的字符位数也基本固定。

请求(request)

  即在网站上通过何种方式获取了哪些信息,也是日志中较为重要的一项,主要包括以下三个部分:

  请求类型(METHOD)

  常见的请求类型主要包括GET/POST/HEAD这三种;

  请求资源(RESOURCE)

  显示的是相应资源的URL,可以是某个网页的地址,也可以是网页上调用的图片、动画、CSS等资源;

  协议版本号(PROTOCOL)

  显示协议及版本信息,通常是HTTP/1.1或HTTP/1.0。

状态码(status)

  用于表示服务器的响应状态,通常1xx的状态码表示继续消息;2xx表示请求成功;3xx表示请求的重定向;4xx表示客户端错误;5xx表示服务器错误。

传输字节数(bytes)

  即该次请求中一共传输的字节数。

来源页面(referrer)

  用于表示浏览者在访问该页面之前所浏览的页面,只有从上一页面链接过来的请求才会有该项输出,如果是新开的页面则该项为空。上例中来源页面是google,即用户从google搜索的结果中点击进入。

用户代理(agent)

  用于显示用户的详细信息,包括IP、OS、Bowser等。

3、日志格式扩展

  apache日志格式可以自定义来配置其输出格式,常见的基于NCSA扩展日志格式(ECLF)自定义添加的包括域名(domain)cookie。其中域名在一个网站拥有二级域名或者子域名时,可以更好地区分日志;而cookie可以作为用户的身份标识。其他具体的自定义信息详见:Custom Log Formats