Add backend event tracking to Observability pages (dashboard, setup, settings, access requests)

Analytics Instrumentation Agent Implementation Issue

Reference:

Analytics Instrumentation quick start guide

1 · Summary

Track: Backend page views and actions across the Observability feature's controllers — the group and project dashboard (observability#show), the setup/enablement page (observability/setup#show), the group settings page (observability/o11y_service_settings#edit / #update), and access requests (observability/access_requests#create).

Goal: We currently have zero backend instrumentation for any Observability page. Measure adoption and drop-off across the full flow — landing on setup, enabling access, configuring settings, and returning to the dashboard — to understand where users succeed or abandon the feature.

2 · Ownership

Field	Value
Product group	`platform_insights`
Product category	`observability`
Tiers	`free`, `premium`, `ultimate`
DRI (engineer)	@dakotadux

3 · Event(s) to Track

#	Proposed action name	Description	Where triggered
1	`visit_group_observability_dashboard`	User visits the group-level Observability dashboard	`Groups::ObservabilityController#show`, successful render branch only
2	`visit_project_observability_dashboard`	User visits the project-level Observability dashboard	`Projects::ObservabilityController#show`, successful render branch only (not on 404 / redirect-to-setup)
3	`visit_observability_setup_page`	User lands on the Observability setup/enablement page (group or project)	`Groups::Observability::SetupController#show` / `Projects::Observability::SetupController#show` (shared via `Observability::SetupActions#show`)
4	`create_observability_access_request`	User requests access to enable Observability	`Observability::AccessRequestActions#create`, on success branch
5	`visit_o11y_service_settings_page`	User views the group Observability service settings page	`Groups::Observability::O11yServiceSettingsController#edit`
6	`update_o11y_service_settings`	User saves changes to the group Observability service settings	`Groups::Observability::O11yServiceSettingsController#update`, on success branch only

4 · Identifiers

user — a logged-in user is always present (before_action :authenticate_user! on all these controllers)
project — present for project-level dashboard/setup events
namespace — present for group-level events (group dashboard, setup, settings); derived from project.group for project events where applicable
feature_enabled_by_namespace_ids

5 · Additional Properties

Property name	Type	Description / example values
`label`	string	For dashboard visit events: the observability sub-path being viewed, e.g. `traces`, `logs`, `metrics`, or empty for the root path
`property`	string	For `update_o11y_service_settings`: outcome context if useful (e.g. `created` vs `updated`)

6 · Metrics

#	Linked event (action name)	Metric type (A/B/C)	Unique by	Filter (if C)	description
1	`visit_group_observability_dashboard`	B	user	—	Weekly/monthly distinct users visiting the group Observability dashboard
2	`visit_project_observability_dashboard`	B	user	—	Weekly/monthly distinct users visiting the project Observability dashboard
3	`visit_observability_setup_page`	B	user	—	Weekly/monthly distinct users reaching the setup/enablement page
4	`create_observability_access_request`	B	user	—	Weekly/monthly distinct users requesting access
5	`visit_o11y_service_settings_page`	B	user	—	Weekly/monthly distinct users viewing settings
6	`update_o11y_service_settings`	B	user	—	Weekly/monthly distinct users successfully saving settings

Proposed key_path pattern: redis_hll_counters.count_distinct_user_id_from_<action_name> Time frames: 7d, 28d Data source: internal_events

7 · Instrumentation Location

7a · Backend (Ruby)

Class type: Controllers + shared concerns
File path(s):
- app/controllers/groups/observability_controller.rb (#show)
- app/controllers/projects/observability_controller.rb (#show)
- app/controllers/concerns/observability/setup_actions.rb (#show, shared by group + project setup controllers)
- app/controllers/concerns/observability/access_request_actions.rb (#create, shared by group + project access-request controllers)
- app/controllers/groups/observability/o11y_service_settings_controller.rb (#edit, #update)
Trigger point:
- Dashboard #show: fire only on the successful render branch (format.html { render } / format.json), not on render_404 or the redirect-to-setup branches.
- Setup #show: fire on every successful render of the setup page.
- Access request #create: fire only when result.success? (skip the "already enabled" and failure branches).
- Settings #edit: fire on every page view.
- Settings #update: fire only when result.success? (skip the render :edit failure branch).

Likely pattern per controller (using ProductAnalyticsTracking for controllers, or Gitlab::InternalEventsTracking directly inside shared concerns):

include Gitlab::InternalEventsTracking

track_internal_event(
  'visit_o11y_service_settings_page',
  user: current_user,
  namespace: group
)

7b · Frontend (Vue / JS / HAML)

Not applicable — this issue is scoped to backend-only tracking. Frontend instrumentation (e.g. "Enable Observability" button clicks, quick-start snippet copy actions) can be tracked in a follow-up issue.

8 · Duo / AI Feature?

Yes
No — standard product feature

Existing event(s): click_observability_on_project_overview (CE, tracks the entry-point click from the project overview page); EE's view_tracing_page, view_tracing_details_page, view_logs_page, view_metrics_page, view_metrics_details_page (legacy tracing/metrics/logs sub-pages, predate the consolidated Observability product).
Existing metric(s): none found for the events proposed above.
Related MR / issue: none currently open; the agent should verify no in-flight MR duplicates this work before opening a new one.

10 · Acceptance Criteria

Event YAML(s) created under config/events/ for all six actions above, with all required fields
Metric YAML(s) created under config/metrics/counts_all/ with correct key_path, time_frame: [7d, 28d], data_source: internal_events
Instrumentation code added at each identified call site
RSpec tests added using trigger_internal_events / increment_usage_metrics matchers, including negative tests for failure/redirect/404 branches
introduced_by_url updated to the MR URL after the MR is opened

11 · Open Questions / Assumptions

Assumes all six events should ship together in one MR; may be split into per-controller MRs if reviewers prefer smaller diffs.
Assumes tiers: [free, premium, ultimate] since Observability access is gated by feature flag (observability_sass_features / observability_saas_features_user_namespace), not by tier.
Assumes the dashboard label additional property (sub-path) is useful; confirm with DRI/data team before implementing, since it adds cardinality.
No project-level settings controller exists today (settings are group-only), so there is no visit_o11y_service_settings_page equivalent scoped to projects.