极狐 GitLab

内部分析

内部分析系统提供了跟踪极狐GitLab 实例的用户行为和系统状态的能力，为客户成功服务和进一步的产品开发提供信息。

这些文档页面提供了关于在开发新功能或检测现有功能时如何利用极狐GitLab 内部分析功能的指南和信息。

基本概念#

事件和指标是内部分析系统的基础。理解这两个概念之间的区别对于使用该系统至关重要。

事件#

事件是极狐GitLab 实例内发生的操作的记录。例如，用户交互（如访问议题页面或将鼠标悬停在顶部导航搜索上）就是一个操作。其他操作可能来自后台系统处理，例如计划的流水线成功或从第三方系统接收 API 调用。并非每个操作都会被跟踪并自动转换为记录的事件。相反，如果一个操作有助于得出产品洞察并帮助做出更明智的业务决策，我们可以在操作发生时跟踪一个事件。生成的事件记录至少包含操作已发生的信息，但它也可以包含有关伴随此操作的上下文的附加详细信息。上下文的示例可以是关于谁执行了操作或操作时系统状态的信息。

指标#

单个事件记录的信息量不足，并且可能是由巧合引起的。我们需要寻找具有共同特征的事件集合，以便为分析奠定基础。这就是指标发挥作用的地方。指标是对信息片段执行的计算。例如，在新功能发布后，记录付费用户访问功能页面的单个事件并不能告诉我们这个新功能的成功程度。但是，如果我们计算新功能发布前一周发生的页面浏览事件的数量，然后将其与新功能发布后一周的事件数量进行比较，我们就可以得出由于新功能发布而兴趣增加的洞察。

这个过程引出了我们所说的指标。基于事件的指标计算事件发生的总次数或在指定时间范围内发生的次数。同一事件可用于不同的指标，并且一个指标可以计算一个或多个事件。计数可以但不一定基于唯一性标准，例如仅计算执行事件的不同用户。

指标不必基于事件。指标也可以是对极狐GitLab 实例本身状态的观察，例如设置的值或数据库表中的行数。

检测#

数据发现#

事件和指标数据最终存储在我们的 Snowflake 数据仓库中。它可以直接通过 Snowflake 中的 SQL 进行临时分析，也可以在我们的数据可视化工具 Tableau 中进行可视化，该工具可以访问 Snowflake。这两个平台都需要访问请求（Snowflake、Tableau）。

要在浏览器中跟踪用户交互，需要禁用“请勿跟踪”（DNT）。大多数浏览器默认禁用 DNT。

Tableau#

Tableau 是一个数据可视化平台，允许构建仪表板和基于 GUI 的事件和指标发现。这种发现方法最适合熟悉商业智能工具、基本验证以及创建持久、可共享的仪表板和可视化的用户。访问 Tableau 需要访问请求。

检查事件#

访问 Snowplow 事件探索仪表板。此仪表板显示事件计数以及最频繁触发的事件。您可以向下滚动到“过去 30 天在生产环境中触发的结构化事件”图表，并过滤您的特定事件操作。过滤器仅适用于精确名称。

检查指标#

您可以访问指标探索仪表板。侧面有一个用于指标路径的过滤器，即您的指标的 key_path，以及一个用于安装 ID 的过滤器，包括如何过滤 JihuLab.com 的指导。

自定义图表和仪表板#

在 Tableau 中，还可以完成更高级的图表，例如这个漏斗分析。可以通过在产品数据洞察团队的项目中创建议题来请求自定义图表和仪表板。

Snowflake#

Snowflake 允许在其 UI 中使用 Snowflake SQL 方言直接查询仓库中的相关表。这种发现方法最适合熟悉 SQL 的用户，以及用于快速灵活地检查数据是否正确传播。访问 Snowflake 需要访问请求。

查询事件#

以下示例查询返回 feature_used 事件的每日事件发生次数。

sql
1SELECT
2  behavior_date,
3  COUNT(*) as event_occurences
4FROM prod.common_mart.mart_behavior_structured_event
5WHERE event_action = 'feature_used'
6AND behavior_date > '2023-08-01' --restricted minimum date for performance
7AND app_id='gitlab' -- use gitlab for production events and gitlab-staging for events from staging
8GROUP BY 1 ORDER BY 1 desc

有关其他指标表的列表，请参阅数据模型速查表。

查询指标#

以下示例查询返回过去六个月内为 count_distinct_user_id_from_feature_used_7d 报告的所有值以及相应的 instance_id：

sql
1SELECT
2  date_trunc('week', ping_created_at),
3  dim_instance_id,
4  metric_value
5FROM prod.common.fct_ping_instance_metric_rolling_6_months --model limited to last 6 months for performance
6WHERE metrics_path = 'counts.users_visiting_dashboard_weekly' --set to metric of interest
7ORDER BY ping_created_at DESC

有关其他指标表的列表，请参阅数据模型速查表。

产品分析#

内部分析正在使用极狐GitLab 产品分析功能，该功能也允许您可视化事件。分析仪表板文档解释了如何构建自定义可视化和仪表板。在极狐GitLab 项目内可访问的自定义仪表板定义在一个单独的仓库中。可以基于通过内部事件系统检测的事件构建仪表板。只有由 .com 安装发出的事件才会在这些可视化中计数。

产品分析组的仪表板可以作为如何基于单个事件构建图表的灵感。

数据可用性#

对于极狐GitLab，在 JihuLab.com 和极狐GitLab 私有化部署实例之间的分析设置有本质区别。

私有化部署#

从 18.0 版本开始，我们在私有化部署实例上收集事件级数据，提供更详细的产品使用洞察。

对于极狐GitLab 18.0 及更高版本：私有化部署实例收集事件级数据，提供与 JihuLab.com 上相同的详细洞察。

对于 18.0 之前的版本：仅聚合指标可用。这些指标每周在随机选择的一天计算一次，并通过称为 Service Ping 的流程转发到版本应用。只有在该实例运行的版本之前检测的指标才可用。例如，如果在 16.9 版本的开发过程中检测了一个指标，则它将在运行 16.9 或更高版本的实例上可用，但不会在运行早期版本（如 16.8）的实例上可用。接收到的有效载荷每天导入到我们的数据仓库中一次。

JihuLab.com#

在我们的 JihuLab.com 实例上，单个事件和预计算指标都可用于分析。此外，页面浏览量会自动进行检测。

单个事件和页面浏览量#

单个事件和页面浏览量直接转发到我们的收集基础设施，然后进入我们的数据仓库。然而，在此阶段数据是难以查询的原始格式。因此，数据会被清理并通过仓库传播，直到在数据发现部分中提到的表和图表中可用。

传播过程需要数小时才能完成。下图说明了事件的可用性：

JihuLab.com 上事件收集和传播的时间线

来源

预计算指标#

指标像在私有化部署上一样每周计算一次，唯一区别是大部分计算在仓库内进行，而不是在实例内。对于 JihuLab.com，此过程在周一早上开始，计算从周日 23:59 UTC 到本周日 23:59 UTC 时间范围内的指标。

下图说明了该过程：

JihuLab.com 上 Service Ping 计算的时间线

来源

数据流#

在 SaaS 和私有化部署实例上（从极狐GitLab 18.0 开始），事件记录直接发送到名为 Snowplow 的收集系统并导入我们的数据仓库。对于 18.0 之前版本的私有化部署实例，仅本地记录事件计数。每周，一个称为 Service Ping 的流程将所有预定义和活跃指标的当前值发送到我们的数据仓库。对于 JihuLab.com，指标直接在数据仓库中计算。

下图旨在说明此数据流：

Rendering chart...

数据隐私#

对于极狐GitLab 18.0 及更高版本：极狐GitLab 从私有化部署实例收集事件级数据，并使用假名化标识符以保护隐私。

对于 18.0 之前的版本：极狐GitLab 仅从私有化部署实例接收事件计数或类似的聚合信息。对于 JihuLab.com 版本，单个事件的用户标识符是假名化的。关于通过内部分析系统收集的数据类型的准确描述，请参阅我们的手册。

贡献指南#