原文地址:https://developer.piwik.org/guides/data-model
> 此文中的内容和《Piwik数据库模式(一)》中相互参照
### 日志数据
HTTP跟踪API(即Piwik\Tracker组件)接收原始分析数据,我们称之为日志数据。
有四种类型的日志数据:
- 访问
- 动作类型
- 转换
- 电子商务项目
归档过程将日志数据聚合到归档数据中。
日志数据从不直接用于Piwik报告,而是使用归档数据。唯一的例外是使用日志数据生成实时报告的Live插件。
##### 持久化
日志数据在PHP中表示为Piwik\Tracker\Visit对象,并存储到下表中:
log_visit 每次访问包含一个条目(返回访问者)
log_action 包含网站上所有可能采取的行动(例如,唯一网址,网页标题,下载网址...)
log_link_visit_action 每个行动的访客包含一个条目(页面浏览,...)
log_conversion 包含访问期间发生的转化(与目标相符的操作)
log_conversion_item 包含电子商务转换项目
这些表(及其相关的PHP实体)的内容将在“ 数据库架构”指南中进行更详细的介绍。
### 存档过程
日志数据不能直接用于最终用户报告,因为它需要在每次需要报告时处理大量的数据。
为了解决这个问题,归档过程将日志数据聚合到归档数据中。然后使用归档数据构建报告。
例
我们举一个例子,在一天内收到1000页浏览量的网站。该日志数据将与其他信息,例如,沿着这1000个的事件列表:
```shell
URL Time ...
/homepage 17:00:19 ...
/about 17:01:10 ...
/homepage 17:05:30 ...
/categories 17:06:14 ...
/homepage 17:10:03 ...
...
```
该归档过程汇总这些原始数据到归档数据。
例如,要构建每页视图数量的报告(查看最受欢迎的页面),归档将列出所有页面并总计每个页面的视图数量:
```shell
URL Page views
/homepage 205
/categories 67
/about 5
...
```
该数据是归档数据。
虽然预计算档案数据对于1000页浏览量来说似乎是多余的,但是在处理较高数据量时并不是这样。
##### 什么时候?
默认情况下,归档数据的计算和缓存点播。当请求具体报告时,Piwik将检查所需的存档数据是否存在,如果不存在则生成。
预归档
当跟踪网站流量很大时,按需归档可能需要太多时间。在这种情况下,必须禁用存档归档,并且预先归档需要在预定时间内在后台运行。
可以使用core:archiveconsole命令为每个站点和期间(自定义日期范围除外)运行预归档:
```shell
$ ./console core:archive
```
通常的设置是使用固定间隔运行该命令cron。
该命令将记住上次执行时,只有存在新的访问时才会存档网站。
##### 怎么样?
日志数据被汇总到每个的归档数据中:
- 现场
- 期间:日,周,月,年或自定义日期范围(自定义日期范围不能预先归档)
- 分割
存档逻辑(即聚合日志数据的方式)由插件定义。由插件定义的所有报告都将归档而不是单独存档。
如果查询中没有分段,找不到数据,则每个插件的每个报告将一次生成并缓存。如果提供了一个段,则将生成和缓存属于与请求的数据相同的插件的报告。
期间聚合
归档数据的计算方式根据期间类型不同:
- “日”期是日志数据的聚合
- “周”,“月”,“年”和自定义日期范围是“日”报告的汇总
例如,通过聚合一周中的7天的归档数据创建一周的归档数据。这比聚合日志数据要快得多。
##### 插件存档
要归档报表和指标的插件定义了一个Archiver扩展的类Piwik\Plugin\Archiver。此类将在归档过程中自动检测并调用。
日志数据聚合由LogAggregator类处理。归档数据聚合由ArchiveProcessor::aggregateDataTableRecords()and ArchiveProcessor::aggregateNumericMetrics()方法处理。
插件可以访问LogAggregator和ArchiveProcessor实例Piwik\Plugin\Archiver。
要了解有关Piwik的MySQL后端如何实现聚合的更多信息,请阅读数据库模式。
##### 持久存档数据
存档数据使用ArchiveProcessor。
使用度量标准插入insertNumericRecord()。
报告首先使用序列化DataTable::getSerialized(),然后插入ArchiveProcessor::insertBlobRecord():
```php
// insert a numeric metric
$myFancyMetric = // ... calculate the metric value ...
$archiveProcessor->insertNumericRecord('MyPlugin_myFancyMetric', $myFancyMetric);
// insert a record (with all of its subtables)
$maxRowsInTable = Config::getInstance()->General['datatable_archiving_maximum_rows_standard'];j
$dataTable = // ... build by aggregating visits ...
$serializedData = $dataTable->getSerialized(
$maxRowsInTable,
$maxRowsInSubtable = $maxRowsInTable,
$columnToSortBy = Metrics::INDEX_NB_VISITS
);
$archiveProcessor->insertBlobRecords('MyPlugin_myFancyReport', $serializedData);
```
持续的报告和指标由网站ID,期间和分段索引。归档的日期和时间也附在数据上。要了解MySQL如何完成此细节,请参阅数据库架构。
##### 报告与记录
当报告被归档时,它被称为不是报告的记录。我们有区别,因为有时可以从一个记录生成多个报告。
例如,UserSettings插件使用一个记录来保存访问者的浏览器详细信息。此记录用于生成UserSettings.getBrowserVersion和UserSettings.getBrowser报告。第二份报告只是处理第一份报告。该插件可以归档这两个报告,但是这将大大浪费空间,考虑到新的报告将被缓存为每个网站/期间/段组合。
##### 记录存储准则
必须注意尽可能少的存放记录。在将记录作为归档数据插入之前,请务必遵循以下准则:
记录不应与字符串列名一起存储。相反,它们应该被替换为整数列ID(有关现有列表的列表,请参阅Metrics)。
可以使用现有数据添加的元数据不应与报告一起存储。相反,当将记录转换为报告时,应将其添加到API方法中。
### 归档数据
归档数据是在创建归档过程中通过汇总日志数据。
Piwik聚合并持续存在两种类型的存档数据:
```shell
度量,它们是单个数值
报告,是二维数组的值
```
报告通常包含指标值,但它们也可以包含其他数据(额外地或代替度量值)。
报告和指标由插件定义,允许任何插件扩展Piwik分析的数据。然而,有几个称为核心指标的指标,由Piwik Core定义。
##### 子集参数
报告和指标提供关于一组事物的分析数据。该集合由三个约束定义:
```shell
一个网站ID
一段时间
一段
```
该网站的ID选择被跟踪特定网站的访问。该ID在具有idSitequery参数的所有HTTP请求中指定。
的期间,选择被跟踪的特定日期范围内的访问。所有HTTP请求中指定的时间段date与period查询参数。
该段根据使用访问属性的布尔表达式选择访问。它在所有HTTP请求中由segmentquery参数指定,可用于选择几乎任何可能的访问子集。
Analytics(分析)参数作为元数据存储在报表中,这意味着它们作为DataTable元数据存储。
##### 度量
核心指标
核心指标是不是由插件定义的,而是Piwik Core。
分析访问次数,操作类型或转化次数的新报告应包含这些指标。
##### 访问指标
一组访问的核心指标:
|名称 | 公制编号 | 描述 |
|:------------ :| :------------ :|
|访问 | nb_visits | 跟踪访问次数 一次访问是一系列事件,每次事件发生不超过30分钟。 |
|独特的访客 | nb_uniq_visitors | 唯一访问来源的数量。访问来源是一个导致访问的实体。 |
|操作 | nb_actions | 跟踪的动作数量。一个行动是Piwik跟踪的一个事件。 |
|最大行动 | max_actions | 一次访问中发生的最大操作次数。 |
|总访问长度 | sum_visit_length | 每次访问的总和时间。 |
|反弹计数 | bounce_count | 仅由一个动作组成的访问次数。 |
|转换访问 | nb_visits_converted | 导致至少一次转化的访问次数。包含网站每个目标的转化。 |
|转换 | nb_conversions | 此次访问跟踪的转化次数。包含网站每个目标的转化。 |
|收入 | revenue | 这些访问产生的总收入。 包括网站的每个目标的收入以及电子商务收入。 |
##### 行动指标
单一动作类型的核心指标:
|名称|公制编号|描述|
| :------------ | :------------ |
|点击|nb_hits|这个动作曾经完成的次数。|
|总和花费时间|sum_time_spent|用户花费这个操作的总时间。|
|总和页面生成时间|sum_time_generation|服务器花费这项操作的总时间。|
|点击与生成时间|nb_hits_with_time_generation|包含生成时间信息的命中数。|
|最小页面生成时间|min_time_generation|服务器为此操作服务的最短时间。|
|最大页面生成时间|max_time_generation|服务器花费此操作的最长时间。|
|独特出境游客|exit_nb_uniq_visitors|在此行动之后退出网站的唯一身份访问者人数。|
|退出访问|exit_nb_visits|通过此操作结束的总访问次数。|
|独特的入场访客|entry_nb_uniq_visitors|通过此操作开始访问的唯一身份访问者总数。|
|入场访问|entry_nb_visits|以此操作开始的总访问次数。|
|进入动作|entry_nb_actions||
|入场和访问长度|entry_sum_visit_length|每次入场访问的总和经过时间。|
|入场反弹计数|entry_bounce_count|由这个动作组成的访问次数,没有其他。|
|点击搜索|nb_hits_following_search|在网站搜索后执行此操作的次数。|
##### 电子商务指标
针对一组访问记录的一组电子商务转换(所有订单或所有已放弃购物车)的核心指标:
|名称|公制编号|描述|
| :------------ | :------------ |
|收入小计|revenue_subtotal|作为这些订单或弃车的一部分的每个项目的总成本。|
|税收收入|revenue_tax|适用于这些订单/弃车的总税额。|
|收入运费|revenue_shipping|运送到这些订单/废弃车的运输总量。|
|收入折扣|revenue_discount|这些订单/弃车的折扣总额。|
|电子商务计数|items|这些订单/弃车的物品总数。
##### 目标指标
一组访问的核心指标和网站的一个目标:
|名称|公制编号|描述|
| :------------ | :------------ |
|目标转换|goal_<idGoal>_nb_conversions|针对特定目标跟踪此次访问的转化。|
|目标收入|goal_<idGoal>_revenue|特定目标的转化所产生的总收入。|
注意:<idGoal>应替换为目标的ID。
目标具体指标存储在goals序列化报告列中的数据库中。该列包含一个PHP数组,将目标ID与目标特定度量值的数组进行映射。这些值被设置为具有上述由AddColumnsProcessedMetricsGoal DataTable过滤器描述的度量名称的普通列值。
##### 已处理的指标
为了归档和数据库大小的效率,一些指标不存储在数据库中。而是在需要时使用其他指标来计算。这些指标称为处理指标。
以下是使用核心指标计算的已处理指标列表。分析访问次数,操作类型或转化次数的新报告应尽可能添加这些指标。
注意:以下列表中会显示多个已处理的指标。这些指标根据他们所在的报告有不同的含义。
一组访问的处理指标:
|名称|公制编号|描述|
| :------------ | :------------ |
|兑换率|conversion_rate|至少有一次转化的访问百分比。|
|每次访问行动|nb_actions_per_visit|单次访问的平均动作次数。|
|平均停机时间|avg_time_on_site|平均每次访问所花费的时间(秒)。|
|跳出率|bounce_rate|导致反弹的访问百分比。|
单个操作类型的已处理指标:
|名称|公制编号|描述|
| :------------ | :------------ |
|平均生成时间|avg_time_generation|服务器提供此操作所需的平均时间。|
|浏览的平均搜索结果页数|nb_pages_per_search|在网站搜索后查看的搜索结果页的平均数量。仅适用于网站搜索关键字和网站搜索类别。|
|平均时间页|avg_time_on_page|用户花费这个时间的平均时间。|
|入场跳出率|bounce_rate|所有访问的百分比组成的这个动作,没有其他。|
|退出率|exit_rate|以此动作结束的所有访问的百分比。|
针对一组访问记录的电子商务订单集的处理指标:
|名称|公制编号|描述|
| :------------ | :------------
|平均订单收入|avg_order_revenue|每个订单的平均收入。|
一组订单或废弃购物车中电子商务集合的处理指标:
|名称|公制编号|描述|
| :------------ | :------------
|平均价格|avg_price|每个项目的平均价格。|
|平均数量|avg_quantity|订单/已放弃购物车中每个商品的平均数量。|
|产品转化率|conversion_rate|包含此项目的订单/弃车的百分比。|
以下是一个特定于一个网站的一个目标的已处理指标列表:
|名称|公制编号|描述|
| :------------ | :------------
|每次访问平均收入|goal_<idGoal>_revenue_per_visit|为此目标每次访问所产生的平均收入金额。|
##### 命名约定
由插件计算和持久化的度量必须使用以下格式命名:PluginName_metricName。例如:MyPlugin_myFancyMetric。
核心指标具有特殊名称,不符合此惯例。
#### 报告
报告使用DataTable类存储在内存中。A DataTable是由行和列组成的二维数组。
每行都包含与一组访问,操作,转换相关的度量...该集合由特殊标签列定义和描述。列描述的集合完全取决于具体的报告。例如,在UserSettings.getBrowser报告中,带有Firefox标签的行将包含使用Firefox浏览器的访问指标。
一些报告VisitsSummary.get就不会有一个标签列:它们只有一行引用整个实体集。
##### 报告元数据
除了指标之外,每一行还可以包含元数据。这个元数据通常会帮助标签列描述行代表的事物集。
一些元数据在Piwik有特殊的含义,例如:
```shell
logo:该值可以是将在UI中的每一行旁边显示的图像的路径
url:该值可以是该行将在UI中链接到的URL
```
##### 子表
报表可以是层次结构的:每行都可以附加到另一个DataTable。附加到行的表称为子表。
子表为行所代表的一组访问提供进一步的分析。例如,Referrers.getSearchEngines报告每个搜索引擎有一行。每行都有一个子表,描述与该搜索引擎一起使用的关键字。以下是一个示意图:
```shell
Search Engine Keyword (subtable) Visitors
--------------|-------------------|----------
Google | 207
--------------|------------------------------
| piwik | 11
| libre analytics | 6
| ...
---------------------------------------------
Duck Duck Go | 121
--------------|------------------------------
| ...
```
##### 命名约定
必须将报告命名为指标如下:PluginName_reportName。例如:MyPlugin_myFancyReport。
- 献给乐于奉献的你
- 一、工作感悟
- 1.1 工作感悟
- 1.2 数据库工作总结
- 二、运维专题(非技术)
- 2.1 公有云运维
- 2.1.1 阿里云采坑记.md
- 三、运维专题(技术类)
- 3.1 Linux(操作系统)
- 3.1.1 常见工作总结
- 3.1.2 常见服务使用和部署
- 3.1.3 操作系统优化
- 3.1.4 常用命令(Centos8)
- 3.2 Docker & K8s(容器技术)
- 3.2.1 Docker
- 1. Docker
- 1-1 容器基础
- 1-2 部署和加速
- 1-3 常用命令
- 1-4 Dockerfile编写
- 1-5 容器网络
- 1-6 数据持久化
- 2. docker-compose
- 2-1 基础
- 3.2.2 kubernetes
- 1. 导读-请先看我
- 2. kubeadm部署集群
- 1-1 k8s-1.14-基于calico
- 1-2 k8s-1.17-基于flanne
- 3. 二进制部署集群
- 4. 日常工作及故障处理
- 4-1 常用命令
- 4-2 故障处理
- 3.2.3 依赖服务部署
- 1. Harbor(镜像仓库)
- 1-1 harbor-2.1.0(单节点)
- 3.3 CICD(持续集成/部署)
- 3.3.1 GitLab
- 1. 服务部署
- 1-1 Gitlab-CE-13.3.4(单节点)
- 2. Git基础
- 3.3.2 Ansible
- 1. 服务部署
- 1-2 ansible-2.5(pip部署)
- 3. ansible-playbook
- 3-1 基于Roles的Playbook
- 3-3 循环语法
- 3.3.3 Jnekins
- 1. Jenkins部署
- 1-1 Jenkins-2.65部署
- 1-2 Jenkins-2.249部署
- 2. Jenkins项目初始化
- 3. Jenkins集成
- 3-1 Jenkins-2.65集成Sonar
- 3.4 LB/HA(负载均衡,反向代理)
- 3.4.1 LVS+Keepalive
- 1. LVS为MySQL读提供负载均衡
- 3.4.2 Pacemaker(HA)
- 1. 常用命令(转)
- 3.5 Runtime(代码运行环境)
- 3.5.1 Tomcat(Web中间件)
- 1. Tomcat部署手册
- 1-1 Tomcat-7.0.76部署
- 2. Tomcat常用脚本
- 3.6 NoSQL(非关系型数据库)
- 3.6.1 redis(非关系数据库)
- 1. Redis 基础
- 2. Redis 4.0变化
- 3. Codis实现Redis的集群
- 4. Redis故障处理
- 5. redis安全第一步
- 6. Redis集群搭建
- 7. CacheCloud部署
- 3.6.1 Redis挑战
- 3.6.2 MongoDB(文档数据库)
- 1. Mongodb基础
- 1-1 Mongodb4.0新特性
- 1-2 支持多大数据量
- 2. Mongodb安装
- 2-1 Mac OS安装Mongodb
- 2-2 Yum安装Mongodb
- 2-3 二进制安装Mongodb
- 2-4 docker容器安装Mongodb
- 2-5 Mongodb 配置文件详解
- 2-6 Mongodb 生产安全清单
- 2-7 用户身份认证和授权
- 3. Mongodb副本集
- 3-1 副本集搭建
- 3-2 用户身份认证与授权
- 4. 日常维护工作
- 4-1 Mongodb磁盘回收
- 4-2 Mongodb备份恢复到任意时间点
- 4-3 Mongodb慢查询分析
- 4-4 Mongodb版本升级
- 4-5 Mongodb副本集成员状态
- 4-6 Mongodb备份恢复工具使用
- 4-7 Mongodb服务启动和停止
- 4-8 修改副本集成员oplog大小
- 4-9 Mongodb 副本集Oplog
- 3.7 MQ(消息队列)
- 3.7.1 Zookeeper(分布式协调系统)
- 1. ZooKeeper基础
- 2. ZooKeeper集群搭建
- 2-1 ZK-3.4.10部署
- 3.2 RabbitMQ(消息队列)
- 1. 服务部署
- 1-1 RabbitMQ-3.8部署
- 2. 常用命令
- 3.8 Monitor(数据收集,监控)
- 3.8.1 Zabbix(运维监控)
- 1. 服务部署
- 1-1 服务端部署
- 1-2 客户端部署
- 2. 监控服务
- 2-1 监控Apache
- 2-2 监控IIS
- 2-3 监控Ningx
- 2-4 监控Tomcat(6/7/8)
- 2-5 监控WebSphere 7
- 2-6 监控MySQL
- 2-7 监控Oracle
- 2-8 监控SQL Servre
- 2-9 监控Weblogic
- 2-10 监控Windows
- 2-11 自定义监控项
- 3. 告警推送
- 3-1 邮件告警
- 3-2 短信告警
- 3-3 告警推到Syslog
- 4. 日常工作
- 4-1 数据库优化(TokuDB)
- 4-2 数据库优化(分区表)
- 4-3 前端定制(Grafana)
- 5. 与Grafana结合
- 3.8.2 ELKBstack(日志收集展示)
- 1. 服务部署
- 1-1 ELK 5.5部署及配置
- 1-1-1 ELKBstack介绍
- 1-1-2 Elasticsearch部署
- 1-1-3 Logstash部署
- 1-1-4 Kibana部署
- 1-1-5 X-pack部署
- 1-1-6 Filebeat部署
- 2. ELK高级配置
- 1. Elasticsearch实战
- 2. Logstash实战
- 3. Filebeat实战
- 5. 引入队列
- 3.9 Virtualization(虚拟化)
- 3.10 Basic(基础服务)
- 3.10.1 Piwik-Matomo(用户行为分析)
- 1. Piwik前期分析
- 2. Piwik介绍和部署
- 2-1 Piwik-3.x版本(早期)
- 3. Piwik 功能配置
- 4. Piwik 模拟数据和压测
- 5. Piwik运转原理
- 6. Piwik数据库模式(一)
- 6-1 第一部分
- 6-2 第二部分
- 3.10.2 Cobbler(系统自动部署)
- 1. Cobbler 可以干什么?
- 2. Cobbler 基础原理
- 3. Cobbler 安装
- 3-1 Cobbler-2.8部署
- 4. Cobbler 基础配置
- 5. Cobbler 配置文件
- 6. 一键优化脚本
- 3.10.3 Rsync(数据同步服务)
- 1. Rsync基础
- 2. 案例:页面部署(服务端拉取)
- 3.10.4 NFS(共享存储)
- 1. NFS部署手册
- 2. 客户端NFS备份脚本
- 3.10.5 Grafana(可视化)
- 1. 安装(8.2.x)
- 3.11 Tools(软件工具)
- 3.11.1 基准测试
- 1. 基准测试方法论
- 2. 压测工具 - Siege
- 3. 压测工具 - http_load
- 3.12 DB(关系型数据库)
- 3.12.1 MySQL(关系数据库)
- 1. MySQL部署
- 1-1 MySQL-5.7部署
- 1-2 Percona-5.7 + TokuDB 部署
- 2. MySQL复制
- 2-1 MySQL异步复制
- 3. MySQL备份恢复
- 3-1 xtrabackup 备份恢复
- 4. MySQL 高可用
- 4-1 MHA(HA)
- 4-1-1 MHA 架构介绍和原理
- 4-1-2 MHA日常管理
- 4-1-3 MHA 自动Failover
- 4-1-4 MHA常用参数
- 4-1-5 MHA 报错
- 4-1-6 MHA相关配置文件和脚本
- 4-2 MyCAT
- 4-2-1 MyCAT 介绍和部署
- 4-1-3 MyCAT读写分离案例解析
- 5. MySQL 常用脚本
- 5-1 MySQL常用统计语句
- 5-2 MySQL性能分析脚本
- 6. MySQL 日常及故障处理
- 6-1 MySQL死锁排查
- 6-2 复制故障
- 6-3 MySQL 升级注意事项
- 6-3 MySQL授权
- 3.12.2 Oracle(关系数据库)
- 1. Oracle部署
- 1-1 Oracle11g单实例部署
- 1-2 Oracle12c单实例部署
- 2. Oracle常用脚本
- 3. Oracle 知识点
- 六、Ansible开源项目
- 6.1 项目初始化手册
- 6.1.1 Ansible错误处理
- 6.1.2 一种预先判断是否操作的方法
- 6.2 System初始化
- 6.3 Nginx/Tnginx部署
- 6.4 Python部署
- 6.5 PHP部署
- 6.6 MySQL部署
- 6.7 Docker部署
- 6.8 Haproxy部署
- 6.9 Redis部署
- 1. 变量和tags信息
- 3. Redis主从部署
- 4. Redis集群部署
- 5. 清理数据
- 6.10 Software软件部署
- 6.11 Zabbix部署
- 6.12 Elastic部署
- 6.13 Tomcat
- 6.14 Kafka部署
- 6.15 Zookeeper部署
- 6.16 Etcd集群部署
- 6.17 M3DB部署
- 6.18 Pormetheus部署
- 七、学习资源推荐
- 八、从瞎搞到放弃
- 8.1 CodeQL(语义代码分析引擎)
- 8.1.1 背景及计划
- 8.1.2 CodeQL概述
- 8.1.3 简单部署和使用
- 8.1.4 后续
- 8.2 dbdeployer(轻松部署MySQL)
- 归档笔记
- 三、常用服务部署(迁移中)
- 3.4 Nginx & PHP(Web服务)
- 3.4.1 Nginx(Web)
- 1. Nginx基础和部署
- 2. Nginx 我的一些思考
- 3. Nginx(Web)配置
- 4. Nginx(Proxy)配置
- 5. Nginx日常管理
- 3.4.3 PHP
- 1. PHP 7.1 部署
- 2. PHP5.6 部署
- 4. PHP原理
- 5. PHP 常用模块
- 二、运维项目实战(迁移中)
- 2.1 标准化 & 工具化项目
- 2.1.1 系统部署和优化
- 2.1.5 全网日志收集展示平台项目
- 1. 项目需求
- 2. 整体方案规划
- 3. 日志收集配置
- 4. 消息缓冲队列
- 5. 日志处理转发
- 6. 日志数据展示(待补充)
- 7. ELK安全配置(上)
- 8. ELK安全配置(下)
- 9. 项目总结
- 2.2 高性能Web项目
- 2.2.1 网站需求(完善中)