标签归档：Cookie

网站分析的基本度量

21 条回复

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

　　下面的度量都是来源于网站点击流数据，但根据点击流数据获取方式的不同（来源于网站原始日志文件或通过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代码来监控站外链接的点击，对于一些广告、宣传、推荐等点击情况跟踪比较有用，可以衡量网站对资源推广的能力和价值。

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

网站用户的识别

49 条回复

web-users　　用户分析是网站分析中一个重要的组成部分，在分析用户之前我们必须首先能够识别每个用户，分辨哪些是”New Customer”，哪些是”Repeat Customer”。这样不但能够更加清晰地了解到底有多少用户访问了你的网站，分辨他们是谁（用户ID、邮箱、性别年龄等）；同时也能够帮助你更好地跟踪你的用户，发现它们的行为特征、兴趣爱好及个性化的设置等，以便于更好地把握用户需求，提升用户体验。

　　通常当你的网站提供了注册服务，而用户注册并登陆过你的网站，那么用户可以更容易地被识别，因为网站一般都会保存注册用户的详细信息；但是你的网站并不需要注册，而用户的行为以浏览为主，这是用户识别就会显得较为困难，下面提供了几种常用的用户识别的方法：

识别用户的几种方法

　　当用户并未注册登录的情况下，识别用户的唯一途径就只剩下用户浏览行为的点击流数据，通常情况下它们会保存在WEB日志里面，关于WEB日志的详细说明可以参考我之前的文章——WEB日志格式。而WEB日志本身存在的缺陷可能导致用户识别的不准确性，关于WEB日志的缺陷可以参考之前的文章——WEB日志的作用和缺陷，所以我们在选择用户识别方法的过程中，在条件允许的情况下尽量选择更为准确的方法：

1、基于IP的用户识别

　　IP地址是最容易获取的信息，任何的WEB日志中均会包含，但其局限性也较为明显：伪IP、代理、动态IP、局域网共享同一公网IP出口……这些情况都会影响基于IP来识别用户的准确性，所以IP识别用户的准确性比较低，目前一般不会直接采用IP来识别用户。

　　获取难度：★

　　准确度：★

2、基于IP+Agent的用户识别

　　同样基于最简单形式的WEB日志，我们可以增加一项——Agent，来提高单一IP方式识别用户的准确性。Agent也是WEB日志中一般都会包含的信息，通过IP+Agent的方式可以适当提高IP代理、公用IP这类情况下用户的分辨度，同时通过Agent还可以识别网络爬虫等特殊“用户”，但同样准确度也欠高。

　　获取难度：★

　　准确度：★★

3、基于cookie的用户识别

　　当你通过自定义Apache日志格式或者JavaScript的方法获得用户cookie的时候，其实你已经找到了一个更有效的用户识别的手段。cookie在未被清除的其前提下可以认为是跟某个访问客户端电脑绑定的（一个客户端有可能包含多个cookie），所以用cookie来标识用户其实指的是用户使用的客户端电脑，而并非用户本身。

　　用cookie识别用户的方法当然也存在缺陷：最常见的就是cookie被清除而导致用户无法与原先记录实现对应；同时由于客户端电脑会被共用，或者用户会在不同的电脑上访问你的网站，这个时候cookie就无法直接对应到该用户了。

　　获取难度：★☆

　　准确度：★★☆

4、基于用户ID的用户识别

　　基于用户ID的用户识别是最为准确，因为一般情况下用户不同共享他的用户ID，所以我们可以认为数据中的userid唯一地指向该用户，几乎不存在偏差。当然要使用用户ID来识别用户是需要一定的前提条件的：网站必须是提供用户注册登录服务的，并且可以通过一些手段在点击流数据中记录userid。

　　获取难度：★★

　　准确度：★★★

　　所以对于一个需要用户ID注册登录的网站来说，用户唯一标识符的选择可以遵从以下顺序：当用户注册登录时以userid为准，当用户在未登录状态浏览时以用户的cookie为准，当用户未登录且cookie无法获取的情况下以IP+Agent为准；这样就能从最大程度上识别唯一用户。

　　这里推荐一个网站日志中cookie项的自定义设置方法，以便更好地识别用户。cookie是从用户端存放的cookie文件记录中获取的，这个文件里面一般在包含一个cookieid的同时也会记下用户在该网站的userid（如果你的网站需要注册登陆并且该用户曾经登录过你的网站且cookie未被删除），所以在记录日志文件中cookie项的时候可以优先去查询cookie中是否含有用户ID类的信息，如果存在则将用户ID写到日志的cookie项，如果不存在则查找是否有cookieid，如果有则记录，没有则记为”-”，这样日志中的cookie就可以直接作为最有效的用户唯一标识符被用作统计。当然这里需要注意该方法只有网站本身才能够实现，因为用户ID作为用户隐私信息只有该网站才知道其在cookie的设置及存放位置，第三方统计工具一般很难获取。

获取用户信息的途径

　　通过以上的方法实现用户身份的唯一标识后，我们可以通过一些途径来采集用户的基础信息、特征信息及行为信息，然后为每位用户建立起详细的Profile：

　　1)　用户注册时填写的用户注册信息及基本资料；

　　2)　从网站日志中得到的用户浏览行为数据；

　　3)　从数据库中获取的用户网站业务应用数据；

　　4)　基于用户历史数据的推导和预测；

　　5)　通过直接联系用户或者用户调研的途径获得的用户数据；

　　6)　有第三方服务机构提供的用户数据。

识别并获取用户信息的价值

　　通过用户身份识别及用户基本信息的采集，我们可以通过网站分析的各种方法在网站是实现一些有价值的应用：

  • 基于用户特征信息的用户细分；
  • 基于用户的个性化页面设置；
  • 基于用户行为数据的关联推荐；
  • 基于用户兴趣的定向营销；
  • ……

WEB日志的作用和缺陷

8 条回复

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的辨析

8 条回复

　　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日志格式

33 条回复

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

１、日志格式类型

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

２、常见日志格式的组成

　　这是一个最常见的基于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