Add a `terminal` extra key to the urlbar exposure event
Categories
(Firefox :: Address Bar, task, P1)
Tracking
()
| Tracking | Status | |
|---|---|---|
| firefox132 | --- | fixed |
People
(Reporter: adw, Assigned: adw)
References
Details
Attachments
(1 file)
It would be helpful if the exposure event recorded which result types were terminal, i.e., which types were present at the end of the session at the time of engagement or abandonment. This is something Dave mentioned to me. The extra keys in Glean events can only be string, boolean, or quantity, so I think we can use an approach similar to the engagement/abandonment events where we have parallel lists represented by comma-separated strings.
Of course, terminal exposures are already recorded in the engagement/abandonment events, but only visible exposures, not hidden exposures, and it's not easy to correlate earlier non-terminal exposures in the exposure event with the later related engagement/abandonment. There are solutions to both of those problems. For correlation, we could introduce a session ID that's recorded in all events of the same urlbar session, or we could just assume events with nearly identical timestamps come from the same session. For hidden exposures, we could record them in engagement/abandonment too in some way, possibly annotating them as hidden.
Regardless, including terminal data directly in the exposure event seems reasonable and would make the event more in line with the keyword_exposure event.
|
Assignee | |
Comment 1•8 months ago
|
||
Please see the bug for context and motivation.
I found a problem with the terminal calculation I added in bug 1915507
D220501. Basing it on query contexts isn't quite right. Ideally, for visible
results, terminal will be true iff the result is in view.visibleResults at
the end of the session, i.e., iff the result is recorded in the engagement or
abandonment event. Anything else would be confusing.
During the last query in a session, the view will be full of stale results from
previous queries. As the view updates itself, it will mark these rows as stale
and call addExposure() for them, passing in the current (final) query context.
It's not incorrect to add exposures since these rows are in fact visible. And if
the final query is canceled, they'll remain visible and actually be terminal
results. However, if the final query finishes without being canceled, the view
will remove these rows, and they won't be terminal at all, but since the view
called addExposure() for them with the final query context, TelemetryEvent
will think they are.
For visible exposures, the terminal calculation needs to be based on the
actual visible rows at the end of the session, same as how the results in the
engagement/abandonment events are determined. For hidden exposures, we can just
use queryContext.results.
|
||
Comment 3•8 months ago
|
||
| bugherder | ||
Description
•