## Background Product Intelligence enables groups to understand how users interact with GitLab. This is currently possible using a variety of approaches, including Snowplow, Service Ping with Redis, RedisHLL, and direct database access. This enables many use cases but also means it can be complicated for users to understand which approach they should use and when. GitLab plans to offer [Product Analytics](https://about.gitlab.com/direction/analytics/product-analytics/) capabilities to external users in the future as well, so this confusion about which technology to use will only get more confusing. ## Proposal * Provide a single, unified interface to users for tracking that abstracts away the underlying technical implementation approach that is used by default. This interface should provide reasonable defaults and only require specifying underlying technical approach if desired. * The key here is that to the user, they are using the same APIs and it feels like a single approach, even if under the hood it is branching to Redis/Snowplow/etc * This unified interface should allow the same behavior that the current Redis, RedisHLL, and Snowplow APIs do. * Our goal is to eventually have this interface replace the database APIs that we have today, but that will be addressed in future work. As part of this epic, we don't need to build it but we should design with extending to this use case later in mind. * This interface should be built with the expectation that it will support Product Analytics in the future. * Consider looking at the Product Analytics [Javascript SDK](https://gitlab.com/groups/gitlab-org/-/epics/8611) for what this might require. This set of APIs will become or be a wrapper on top of what we ship to customers for the Product Analytics [Ruby SDK](https://gitlab.com/groups/gitlab-org/-/epics/8840). Designs should be considered with this in mind and in making decisions about where/when to include GitLab-specific code in a wrapper vs general code that goes in the SDK. The following drawing should serve as an inspiration towards what the future of event tracking at Gitlab could look like. This epic is regarding the first step in this process:  ### Personas served Consider [the personas](https://about.gitlab.com/direction/analytics/product-intelligence/#personas-that-we-work-with) that PI group works with as part of developing this. Specifically: * [Product groups within GitLab](https://about.gitlab.com/direction/analytics/product-intelligence/#product-groups-within-gitlab) * These are the teams that are primarily implementing whatever Product Intelligence provides. * [External GitLab users](https://about.gitlab.com/direction/analytics/product-intelligence/#external-gitlab-users) * These users will use the provided APIs as a way to instrument their own apps to send data to GitLab Product Analytics. This will form the [Ruby SDK](https://gitlab.com/groups/gitlab-org/-/epics/8840) used with Product Analytics. In the context of mirroring Redis, Redis HLL metrics with Snowplow events, as well as inspired by conversation at https://gitlab.com/gitlab-org/gitlab/-/issues/379739#note_1186357298 it might be worth to consider if different event tracking frameworks can be unified ## Goal Consider if it worth and what it would take to provide unified tracking interface that would cover both self managed and SaaS instance. It might considerable to provide new or extend existing `GitLab::Tracking.event` method to route events to different directories based on `Gitlab.com?` response *This page may contain information related to upcoming products, features and functionality. It is important to note that the information presented is for informational purposes only, so please do not rely on the information for purchasing or planning purposes. Just like with all projects, the items mentioned on the page are subject to change or delay, and the development, release, and timing of any products, features, or functionality remain at the sole discretion of GitLab Inc.* ## Prototype documentation Available at https://about.gitlab.com/handbook/engineering/development/analytics/analytics-instrumentation/event_system_draft.html