1962509 - Increase the Glean category character limit of 40 characters

Status: NEW

(Data Platform and Tools :: Glean: SDK, enhancement, P3)

Description

[isabella]

Attachment: Library > History Panel > Clear History Sheet (Example)

Request

Currently we have a 40 character limit on the glean category field and a 70 character limit on the name field.

We would like to increase the category character limit from 40 to a reasonable maximum within the constraints of the tooling.

Background Motivation

For the iOS telemetry audit (started H1 2025), we are interested in introducing a new name taxonomy. Very generally, we would like to follow a naming scheme such as: top_level_component.optional_one_or_more_subcomponents.surface.element_with_user_action.

This taxonomy will uniquely identify the UI elements a user is interacting with. This makes it easier for those viewing the Glean dictionary (especially product management) to find the telemetry they're interested in.

Currently, we are running up against some limitations on implementing this naming scheme within the metrics.yaml file(s) and the glean parser.

Since we can only use dots . in the category part of a name, we would be forced to define the above example like this in the YAML:

top_level_component.optional_one_or_more_subcomponents.surface:  // 40 character limit on category
      element_with_user_action:  // 70 character limit on name
           ...

As you can see, we will very quickly run out of characters in the category name.

We hope to fully qualify the path to the element a user interacts with, so we are likely to have very nested naming for items that appear within settings screens, for example, where the user might drill down several screens before reaching a toggle.

Examples

Examples of some of the category names we would like to support:

• autofill.password_generator.<insert subcomponents>
• settings.homepage.shortcuts.<insert subcomponents>
• tabs_panel.inactive_tabs_panel.<insert subcomponents>
• library.reading_list_panel.<insert subcomponents>

In these examples, it's easy to see how adding additional subcomponents to identify app features will quickly cause us to run into the 40 character limit on categories.

A more concrete example: library.history_panel.clear_history_sheet.option_selected. This one has a 41 character category, and therefore we cannot use our desired naming pattern.
^ See the attached screenshot for a visual reference of the interaction being described in the above event.

Comment 1

[Travis Long [:travis_]]

Unfortunately I cannot get to this in the short term, so I am untaking it to focus on other things.

Comment 2

[isabella]

As discussed in slack, we also are hitting another limit (which might be arbitrary, or related to limits in BigQuery, requiring some investigation).

share.open_in_firefox_action_extension:
  url_shared:
    type: event
    description: |
      Recorded when the user shares a URL from the "Open in Firefox" Action Extension.
    bugs:
      - https://github.com/mozilla-mobile/firefox-ios/issues/20805
    data_reviews:
      - https://github.com/mozilla-mobile/firefox-ios/pull/30142
    notification_emails:
      - [e-mail]
    expires: "2026-01-01"
    metadata:
      tags:
        - Share
        - OpenInFirefoxActionExtension

In this example, we are getting an error in the glean parser for open_in_firefox_action_extension being longer than 29 characters.

  'share.open_in_firefox_action_extension' is not valid under any of the
    given schemas
        'share.open_in_firefox_action_extension' does not match
        '^[a-z_][a-z0-9_]{0,29}(\\.[a-z_][a-z0-9_]{0,29})*$'
        'share.open_in_firefox_action_extension' is not one of ['$schema',
        '$tags']

Due to this limitation, we now have to either break up the name with another . (changing the semantic meaning) or use a less specific name for the open_in_firefox_action_extension... which is an Action Extension called "Open In Firefox", so that's a bit challenging. We will probably go with share.action_extensions.open_in_firefox for now.

Comment 3

[Chris H-C :chutten]

Let's pop this back into triage then.

Comment 4

[Chris H-C :chutten]

Alas the serious thought and planning necessary to up the limit is not within our bandwidth this quarter. So this bug's going back to the P3 list. But we can remove the "subcategory" limits of 29 characters and stick with just the 40-character limit on category names. I'll file a blocking bug for that in a moment.

A point raised by :srose in Data Engineering is that this method of metric taxonomy might itself not be ideal. It couples the instrumentation tightly to a particular organization of code. Refactors of code could result in changing the names of a lot of metrics, necessitating the migration of any analyses that depend on them.

A looser coupling mechanism is offered by a metric's or ping's tags which, as it's not the most advertised feature, might be something you hadn't considered?

Comment 5

[isabella]

Thanks for taking a look, sad to hear it's not an easy adjustment!

A point raised by :srose in Data Engineering is that this method of metric taxonomy might itself not be ideal. It couples the instrumentation tightly to a particular organization of code. Refactors of code could result in changing the names of a lot of metrics, necessitating the migration of any analyses that depend on them.

In practice we haven't been coupling too deeply with UI (my original ticket probably misrepresented this). Our naming tends to group feature interaction within the category of that feature (e.g. add a bookmark using the app menu would be under app_menu.<interaction>). There are many other ways of adding bookmarks (several different long press context menus, adding a bookmark manually in the bookmark panel, etc.) which we would want to record as separate events. So coupling adding a bookmark from the app menu is actually meaningful and relevant. Usually Product wants to know specifically which UI element in the visual hierarchy is being interacted with so Data Science can build user journeys.

The most recent example of where we hit this limit is with the webcompat reporting form (which wasn't a UI limitation actually but a cross-platform naming limitation). Related thread: https://github.com/mozilla-mobile/firefox-ios/pull/35009#discussion_r3715016674

We need to report the telemetry in this JIRA comment when a user submits a broken site report. We can't change any names because we need alignment with Desktop and Android. Some of the names are quite long already (e.g. tab_info.antitracking.is_private_browsing). At the very least, we wanted to organize all report fields under a common category for iOS.

At the same time, we also have a Broken Site Report screen for this feature, and we want to collect some interaction data from the user (what they tap, etc.) as specified in another ticket. We don't want this getting mixed up with the report contents as described above.

My hope then was to group the broken site report telemetry as follows:

• broken_site_report.report_contents.<report fields>
• broken_site_report.<ui interactions>

But now we hit length restrictions on broken_site_report.report_contents.tab_info.antitracking.is_private_browsing, for example.

To work around naming length restrictions, we were forced to do the opposite:

• now all the report fields are shallowly under broken_site.<report fields>
• we nested interactions separately under broken_site_report.interactions.<ui interactions>.

So this one was less about UI coupling and more of just wanting the top namespace to be "broken site report" followed by "the report's contents". 😅

A looser coupling mechanism is offered by a metric's or ping's tags which, as it's not the most advertised feature, might be something you hadn't considered?

P.S. We have started leveraging tags as well, they're very helpful so Product can find all telemetry related to a feature and/or sub-feature!