docs for messaging_system.event metric are incorrect
Categories
(Firefox :: Messaging System, defect, P2)
Tracking
()
Tracking | Status | |
---|---|---|
firefox122 | --- | fixed |
People
(Reporter: dmosedale, Assigned: dmosedale)
References
(Blocks 1 open bug)
Details
Attachments
(1 file, 1 obsolete file)
The metrics.yaml
file currently documents messaging_system.event
(Glean Dictionary) as
The type of event. Any user defined string (e.g. “click”, “share”, “delete”, “more_items”)
Thanks to Ed for discovering that this documentation was incorrect.
From an stmo query, the actual range of events in the Glean tables from the last 28 days of this comment is:
CLICK
ASR_RS_ERROR
AUTO_ADVANCE
ASR_RS_NO_MESSAGES
CLICK_BUTTON
BLOCK
ENABLE
CLICK_SECONDARY_BUTTON
MOMENTS_PAGE_SET
TRANSACTION_FAILED
INSTALL
DISMISSED
CLICK_PRIMARY_BUTTON
SESSION_END
CLICK_DOORHANGER
INDEXEDDB_OPEN_FAILED
PAGE_EVENT
IMPRESSION
FXA_SIGNIN_FLOW
TARGETING_EXPRESSION_ERROR
SELECT_CHECKBOX
DISMISS
I'm somewhat inclined to remove the possible options from the YAML entirely, on the theory that people are going to be more inclined to keep the Commentary up-to-date than the YAML, and put all the known currently used values there. I'd use this bug to do that. Chris, Perry, having been involved with other Glean stuff for much longer, do you have any words of wisdom here?
From a validation standpoint, it may be worth looking at how this compares to the existing PingCentre stuff. So far I haven't found a way to fully do it easily without joining a bunch of tables messaging_system.{onboarding,cfr,...}, or else looking at the event
field in messaging_system.event_types
, which is not obvious how to segment by date & version to make it fully directly comparable. But I could easily be overlooking something.
That said, looking at (for example) just about:welcome
in both places (here's the PingCentre version shows the same stuff shows the same values as a comparable to the Glean version if one uncomments the restriction to about:welcome
there.
Jeff, I suspect the validation pieces want to be spun off into either a separate bug, or just into the validation work as a whole. What do you think?
Comment 1•2 years ago
|
||
I don't see the problem.
The yaml says that the field can be "Any user defined string" and then it gives a few examples. I wouldn't interpreted a list starting with "e.g." to be exhaustive. And if the field can really be any string, then I don't see much value in trying to keep a running list of all possible values that exist in that field.
Maybe I'm missing something or my understanding is incomplete?
Comment 2•2 years ago
|
||
I'm with Jeff that I don't think this list is expected to or needs to be exhaustive. But it should be appropriately capitalized and only contain items that are actually sent (where did "more_items"
come from, I wonder).
Updated•2 years ago
|
Updated•2 years ago
|
Updated•2 years ago
|
Comment 3•2 years ago
|
||
The severity field is not set for this bug.
:lsmith, could you have a look please?
For more information, please visit BugBot documentation.
Assignee | ||
Updated•2 years ago
|
Updated•1 years ago
|
Updated•1 years ago
|
Updated•1 years ago
|
Updated•1 year ago
|
Updated•1 year ago
|
Updated•1 year ago
|
Assignee | ||
Updated•1 year ago
|
Updated•1 year ago
|
Assignee | ||
Comment 4•1 year ago
|
||
Assignee | ||
Comment 5•1 year ago
|
||
Updated•1 year ago
|
Comment 7•1 year ago
|
||
bugherder |
Description
•