Improve slow click / multi click capture

[mydea]

After some discussion, we landed on implementing the following logic/behavior for slow/rage click detection in Replay:

• Clicks generate ui.click breadcrumbs immediately
  • these are debounced by 1s, so any further click on the same element within 1s does not generate a further ui.click breadcrumb!
• Whenever a ui.click breadcrumb is captured, we start looking for 7s for a) further clicks on the same element and b) if the click is a slow click
• After 7s...
  • if no mutation happened in the meanwhile, we create a ui.slowClickDetected breadcrumb with a clickCount counting all clicks on the same element in the last 7s
  • if a mutation happened and more than 1 click in total happened in the last 7s on the element, we create a ui.multiClick breadcrumb with the clickCount
  • If only this one click happened, we create no more breadcrumbs

This means that:

• We always get slow/multi click breadcrumbs after 7s, never before. This means we may loose some, but this is worth it to us so we have better data.
• We count all clicks that happened in the 7s period. The idea is, that if a slow click happens, then after 3s the user starts rage clicking on the same button - we can detect this by seeing that this slow click had a lot of clicks in this 7s.
• There may still be false positives, think a continue button that is clicked a few times in 7s because the user is moving forward fast - but this we can figure out eventually.

One thing to note is that the ui.slowClick / ui.multiClick breadcrumbs will be created with the same timestamp & message as the original ui.click breadcrumb.

[mydea]

Related to #8300

[billyvg]

• Clicks generate ui.click breadcrumbs immediately

  • these are debounced by 1s, so any further click on the same element within 1s does not generate a further ui.click breadcrumb!

If we use the flowchart (which is great btw) in any official capacity, we should clarify this point on there that it is specific to the element.

• Whenever a ui.click breadcrumb is captured, we start looking for 7s for a) further clicks on the same element and b) if the click is a slow click

• After 7s...

  • if no mutation happened in the meanwhile, we create a ui.slowClickDetected breadcrumb with a clickCount counting all clicks on the same element in the last 7s

👍

• if a mutation happened and more than 1 click in total happened in the last 7s on the element, we create a ui.multiClick breadcrumb with the clickCount

Will we still have timeafterclick?

[mydea]

Good point! I can update this, to be clear.

Will we still have timeafterclick?

Yes, this works exactly the same as before, we only wait for 7s even if we detect a mutation before.

[mydea]

One thing to note, which may or may not be unexpected, is that a single click can contribute to multiple clickCount values.

Imagine a sequence like this:

• 0s --> creates ui.click A
• 0.5s
• 1.5s --> creates ui.click B
• 2s
• 2.5s
• 2.7s

--> For A, we'd create a ui.multiClick after 7s with clickCount: 6.
--> For B, we'd create a ui.multiClick after 1.5+7 = 8.5s, with clickCount: 4

I think this is OK (and avoiding this becomes very difficult, because we'd need to keep track of where a click was counted etc.), but it's something to keep in mind when evaluating multi clicks.

[billyvg]

One thing to note, which may or may not be unexpected, is that a single click can contribute to multiple clickCount values.

Imagine a sequence like this:

• 0s --> creates ui.click A
• 0.5s
• 1.5s --> creates ui.click B
• 2s
• 2.5s
• 2.7s

--> For A, we'd create a ui.multiClick after 7s with clickCount: 6. --> For B, we'd create a ui.multiClick after 1.5+7 = 8.5s, with clickCount: 4

I think this is OK (and avoiding this becomes very difficult, because we'd need to keep track of where a click was counted etc.), but it's something to keep in mind when evaluating multi clicks.

Ah, I was under the impression it would only count clicks on that specific element.. I can see a case for both scenarios

[ryan953]

amazing chart, it's very clear!

I think that the timer output at 11s should have a count of 3. there are counts of 0s, 0.5s and 4s leading into it.

ui.multiClick
clickCount: 3

[mydea]

One thing to note, which may or may not be unexpected, is that a single click can contribute to multiple clickCount values.
Imagine a sequence like this:

• 0s --> creates ui.click A
• 0.5s
• 1.5s --> creates ui.click B
• 2s
• 2.5s
• 2.7s

--> For A, we'd create a ui.multiClick after 7s with clickCount: 6. --> For B, we'd create a ui.multiClick after 1.5+7 = 8.5s, with clickCount: 4
I think this is OK (and avoiding this becomes very difficult, because we'd need to keep track of where a click was counted etc.), but it's something to keep in mind when evaluating multi clicks.

Ah, I was under the impression it would only count clicks on that specific element.. I can see a case for both scenarios

It does count only on this specific element, but even on one element this can happen!

I think that the timer output at 11s should have a count of 3. there are counts of 0s, 0.5s and 4s leading into it.

With the current implementation, the click that happens at 4s will have clickCount: 4, because starting with & including this there are 4 clicks from there until 4+7s.