Internal Event Tracking
This page provides detailed guidelines on using the Internal Event Tracking system to instrument features on GitLab.
Currently Internal Event Tracking is consolidating the following systems:
- Service Ping
- Snowplow
- AiTracking (Duo Chat) WIP
Internal Events is an unified interface to track events in GitLab. Each tracking call represents a user action and the associated properties. Internal Events then provides underlying systems the properties they require for their specific analytics needs.
Analytics systems summary:
| Function\System | Service Ping | Snowplow |
|---|---|---|
| Primary function | Provide aggregated analytics data | Track raw events (user interactions with the service) |
| Data storage | Local instance (Redis, Postgres etc) | Snowflake |
| Data granularity | None (data is aggregated) | Per event |
| Extra parameters | None | Any amount of custom data |
| Receiving delay | Up to 1 week | A few minutes |
| Implementation | Utilises Internal Events, Database records, System Settings | Internal Events plus custom tracking context |
This page is a work in progress. If you have access to the GitLab Slack workspace, use the
#g_monitor_analytics_instrumentation channel for any questions or clarifications.
Docs
Edit this page to fix an error or add an improvement in a merge request.
Create an issue to suggest an improvement to this page.
Product
Create an issue if there's something you don't like about this feature.
Propose functionality by submitting a feature request.
Feature availability and product trials
View pricing to see all GitLab tiers and features, or to upgrade.
Try GitLab for free with access to all features for 30 days.
Get help
If you didn't find what you were looking for, search the docs.
If you want help with something specific and could use community support, post on the GitLab forum.
For problems setting up or using this feature (depending on your GitLab subscription).
Request support