dotCMS / dotCMS/core

Add Telemetry metrics for Content Analytics

Open
#31,548 1 comment 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

dotCMS : Metrics OKR : Business Team : Falcon Type : New Functionality
Dominant language
Java
Stars
970
Forks
486
Avg merge
3d 33m
Merged PRs (30d)
170

Description

Parent Issue

No response

User Story

As a system administrator, I want to collect telemetry data on Content Analytics, so I can know if and how much my users are using this feature.

We need to collect telemetry usage data for Content Analytics. This includes storing separate analytics events each time dotCMS receives a request to perform an analytics query. The recorded events should:

  • Identify the source of the query (e.g. viewtool, API, etc.)
  • Include information about:
    • Success or failure of the request (e.g. was it a valid query or not)
    • The parameters sent (limit, offset, filters, measures, etc.)
    • The size of the returned results
  • Include information about the measure(s) queried

Note that activity reports may also query whether and how often users are recording custom analytics events. But those can be queries without any additional events being recorded, so no changes are required for that.

Acceptance Criteria
  1. An event is recorded each time dotCMS receives an analytics query, from each of these sources:
    • Analytics viewtool
    • Analytics API
    • Analytics widget (using the Analytics viewtool)
    • Headless app (using the Analytics API)
  2. The count of analytics queries can be retrieved via a separate analytics query
Proposed Objective

Core Features

Proposed Priority

Priority 2 - Important

External Links... Slack Conversations, Support Tickets, Figma Designs, etc.

No response

Assumptions & Initiation Needs

No response

Quality Assurance Notes & Workarounds

No response

Sub-Tasks & Estimates

No response

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start by tracing how analytics queries enter through the Analytics viewtool and Analytics API, including the widget and headless app paths. Identify where query success, parameters, measures, and result sizes are available. Done means each accepted source records a separate telemetry event and the resulting query count can be retrieved through an analytics query.

Written by the indexing model from the issue text.

Assessment

Tech stack
java
Domain
analytics, backend-api-design, observability
Issue type
Feature
Difficulty
4/5
Estimated time
3-5 days
Activity status
Stale
Clarity
Mostly clear
Newbie friendliness
35/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.