Measure the time it took the user to click a result or press <enter>. A histogram should do it. Bucket size TBD.

What's the starting point of the timer? Should this take into account the querying time? Basically, should we start: a) as soon as the user stops typing b) as soon as the later clicked result is shown to the user I'm assuming b) makes more sense.

The question we are trying to answer is "how fast was the result delivered?", so the starting point should be the last keystroke (with each new one resetting the timer). I think we want to stop the timer once the last result is displayed or when one result is selected, whatever happens faster.

(In reply to Panos Astithas [:past] from comment #2) > The question we are trying to answer is "how fast was the result delivered?" So this seems to be a code performance metric, and maybe a network performance metric if we keep search suggestions in the mix. I guess we might need to differentiate the two in some way. How do we plan to use this data?

Dave and I are talking about this. Let's talk about it together in person. Paolo and Marco are raising very good questions. The idea here is to put quantitative numbers to be able to compare why one engine might be better than another, or what is the threshold where users perceive that speed is slow, or quality isn't good. There's a lot of detail here though...

An assertion I'm putting in here is that display time matters a lot (i.e. the time that the user sees it) and that may then drive click behavior, which is necessarily slower since the user makes a decision (based on display), then has to move the mouse and click a button. The click may take a second. The decision may have been made on first display in a fraction of a second. We're de-prioritizing this but I'm adding the comment that we may need to calculate based on display time, but only capture (send to telemetry) when the user clicks. We would want these numbers keyed by result time.