通常用这些数据追踪网站事件。就Flickr来说，表示上载照片数、新用户注册数、平均照片大小、总的磁盘空间消耗量、卖出出了多少Pro账号、有多少求助信息登记及解决了多少，等等。因为这些数据一般用来做长期趋势分析，以便进行产品预测或容量规划，因此，以天为采集频度就够了。增加分辨率，一天多采几次，对结果没有任何影响，反而增加生成报表的时间，数据移动起来也很麻烦。每天采集一次这些数据很简单，每天夜里运行一个cron作业即可，将数据存入复制用的数据库子机，这台数据库子机就是用来处理这些数据的。



由于这些数据存于数据库中，而且日期是恒定的，所以对这些数据进行跨地域处理或相关性分析就很直接了。
 
例如，由于节假日期间，新的数码相机经常被作为礼物赠送，所以，与平时比起来，节假日期间的平均照片上载量有很大增长，就不奇怪了。有了这些数据，我们可以针对相同日期计算出其他值来，所以，我们能够毫无困难地观察平均上载大小是如何增加磁盘空间消耗的(因为照片的原始尺寸变大了)，从而相应地增加Flickr Pro账号的订购量(与免费账号相比，Pro账号没有容量限制)。

有了这些高层数据之后，你的机构中面向产品的那些人对这些数据也抱有极大的兴趣，你一点都不用感到惊讶。虽然你可能是用磁盘空间消耗数据为存储需求做容量规划，但他们却另有看法，比如，这些使用情况的数据可以帮助他们做功能发布的时间表。网站使用情况有助于制定产品路线图，产品路线图有助于容量规划，容量规划有助于预算以及基础架构的前途，等等。你很庆幸是以一种简单且可移植的格式存储这些数据的，因为机构中的任何人都可能用到这些数据。

对于应用层面的数据，最有用的是能够跟踪用户的交互情况。比如一个社会网络站点，用户可以与其他用户成为为“好友”、上载照片，或在其他用户页面上发表评论。记录这些事件是不能用正规的时间间隔的方法的，这与采集CPU测量数据不同，采集CPU数据用的是正规的时间间隔方法一比如说，每隔15秒进行采样。这种方法与前述将每天发生的事件进行累加的方式也不同。将这些非周期性事件与周期性事件进行相关性分析时，要确保时间尺度是固定的。

Flickr的这种非正规类型的一个例子如下:我们发布了一个功能，让你导入各种邮件地址簿，并将这些地址簿中的名字及邮箱与你还不是联系人的网站成员进行关联，然后批量添加联系人。如果我们只是将每天产生了多少联系人进行累加的话，我们在图上就会看到那个数据点上有个跳变，但这个功能发布后，并没有看到跳变，在随后的数小时一直到下周，也都没有看到。同样的情况还有用户对照片进行标注(tagging)的功能。了解这些信息有助于我们将来如何发布网站建设新功能，那就是一在发布功能之前，我们应该准备数据采集(对这些情况而言，就是一张MYSQL的汇总表)。