标签归档：Session

网站分析的基本度量

　　我们在使用各种网站分析工具的时候，会看到很多不同的度量指标，可能不同的工具会有不同的命名和定义，这里列举一些常见的度量，简单说明一下它们是如何计算得到的。

　　下面的度量都是来源于网站点击流数据，但根据点击流数据获取方式的不同（来源于网站原始日志文件或通过beacons和JavaScript的方式获取的网站日志，如同样免费的AWStats和Google Analytics）得到的度量也会有差异，某些度量只有通过特定的方式才能获得。关于网站日志的介绍，请参考这篇文章——WEB日志格式。

Hits

　　来源于网站原始日志，即用户浏览网站时发起的请求数，包括页面请求，也包括图片、CSS、Flash等，所以一般打开一个页面会发送多个请求，根据网页设计的差异Hits会是PV（Page Views，下面会有介绍）的N倍，比如我的博客的AWStats统计中Hits数一般是PV的3-5倍。

Page Views

　　即PV，页面浏览数，页面被打开（请求）的次数，是网站分析中最常见的度量。注意Ajax架构或Flash下同一URL下可以浏览多个页面，进行多个操作，这些都无法在PV中体现。还需要注意Unique Page的定义，当一个页面被刷新多次时，其实用户浏览的始终是同一页面，所以这时的Unique Page Views还是1。

Visits

　　访问量，也是常见度量之一，用于衡量用户的一次访问（从打开进入网站到离开网站，其中可能浏览了多个页面（PV））的数量，也就是网站Session的个数（关于Session，可以参考我的这篇文章——Session和Cookie的辨析）。

Unique Visitors

　　UV，被用于标识访问网站的唯一用户数，关于如何识别用户，请参考这篇文章——网站用户的识别。注意一个Unique Visitors可能会有多个Visits。

Time on Page

　　页面停留时间，即用户从打开页面到离开页面的时间间隔，这个度量一般只有当用户在你的网站中点击了下一个页面时才会有记录，否则是0，所以所有Visits的最后一个页面的Time on Page一般都为0，具体参见WEB日志的作用和缺陷中关于停留时间的说明。所以我们在计算页面平均停留时间（Avg. on Page）的时候一般会过滤Time on Page=0的记录。

Time on site

　　即每个Visits的停留时间，一个Session的开始到结束。跟Time on Page同样需要注意其计算中存在的误差，取平均的时候注意过滤长度为1的session。

Bandwidth

　　这个度量也一般只能从原始日志中获取，Bandwidth是AWStats中的命名，统计网站的流量，需要将所有请求的传输字节数相加得到结果。一般用于衡量网站的流量情况，服务器IO负荷，及某些限制了月流量最大值的虚拟主机流量使用情况。

Bounce Rate and Conversion Rate

　　关于Bounce Rate ，有一句很形象的描述——“I came, I puked, I left.” 即进入你的网站，什么事都没干就直接离开了。关于Bounce Rate的注意点，请参考这篇文章——关于Bounce Rate定义的疑问。

　　如果一个访问没有Bounce，那么我们就可以跟踪其访问足迹统计Conversion Rate，即从上一步进入的访问率（Current Visits/ Previous Visits）。转化率对于某些网站的关键流程的优化可以起到重要作用，比如电子商务网站的购买流程等。

Entrances and Exit Rate

　　Entrances一般用户衡量网站首页或Landing Page的进入情况，指First Page of Visits。Exit Rate可以作为每个页面的基本度量，衡量从该页面离开的比率，即该页面是整个Visits的最后一个页面。

Sources and Search Key Phrase

　　来源于referrers的统计，Sources即网站的来源（搜索引擎、广告或其它），用于广告投放效果分析、SEM等。

　　Search Key Phrase是基于来源是搜索引擎referrer的解析，统计来源的搜索关键词，Avinash Kaushik建议我们使用Key Phrase而非KeyWords。有助于SEO和发现用户需求。

Engagement

　　参与度对于不同网站来说定义不一，可以是电子商务网站的购买、反馈行为，也可以是论坛的发帖、跟帖行为，还有视频网站的观看视频、游戏网站的线上游戏等。每个访问的参与度可以用Engagement Rate = Engagement Index / visits来计算，即参与度 = 参与标识/访问量。

Destinations

　　即点击站外链接，一般通过JS代码来监控站外链接的点击，对于一些广告、宣传、推荐等点击情况跟踪比较有用，可以衡量网站对资源推广的能力和价值。

　　上面列举的都是网站分析中一些比较基本的指标和度量，我们在网站分析过程中可以基于这些度量通过求和、比例、平均等方式获得更多我们希望得到的数据，进而为我们的分析结果提供更充分的依据。

WEB日志的作用和缺陷

8 条回复

　　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的状态。

session和cookie的辨析

8 条回复

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

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

关于session

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

　　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 是一小段文本信息，伴随着用户请求和页面在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日志中的输出，用于数据统计与用户跟踪。