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点击时间分别为HT_A、HT_B、HT_C，那么A和B页面的停留时间（StayTime）就可以通过计算得到：ST_A= HT_B-HT_A，ST_B= HT_C- HT_B，而因为我们无法获取session结束的时间，所以ST_C是无法通过计算得到的，所以一般session最后页面的停留时间是0，而session得停留时间，即一次访问的时间（Time on site）是HT_C- HT_A，其实是从打开第一个页面到打开最后一个页面的时间间隔，也是不准确的。

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