Repository navigation
Improve slow click / multi click capture #8379
Description
After some discussion, we landed on implementing the following logic/behavior for slow/rage click detection in Replay:
- Clicks generate
ui.clickbreadcrumbs immediately- these are debounced by 1s, so any further click on the same element within 1s does not generate a further
ui.clickbreadcrumb!
- these are debounced by 1s, so any further click on the same element within 1s does not generate a further
- Whenever a
ui.clickbreadcrumb 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.slowClickDetectedbreadcrumb with aclickCountcounting 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.multiClickbreadcrumb with theclickCount - If only this one click happened, we create no more breadcrumbs
- if no mutation happened in the meanwhile, we create a
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
continuebutton 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.
Reacted by Bruno Garcia
Metadata
Metadata
Assignees
Labels
No labels
Activity
mydea commentedon Jun 22, 2023
Related to #8300
billyvg commentedon Jun 22, 2023
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.
👍
Will we still have
timeafterclick?mydea commentedon Jun 22, 2023
Good point! I can update this, to be clear.
Yes, this works exactly the same as before, we only wait for 7s even if we detect a mutation before.
mydea commentedon Jun 22, 2023
One thing to note, which may or may not be unexpected, is that a single click can contribute to multiple
clickCountvalues.Imagine a sequence like this:
--> For A, we'd create a
ui.multiClickafter 7s withclickCount: 6.--> For B, we'd create a
ui.multiClickafter 1.5+7 = 8.5s, withclickCount: 4I 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 commentedon Jun 22, 2023
Ah, I was under the impression it would only count clicks on that specific element.. I can see a case for both scenarios
ryan953 commentedon Jun 22, 2023
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.
mydea commentedon Jun 22, 2023
It does count only on this specific element, but even on one element this can happen!
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.
fix(replay): Adjust slow/multi click handling (#8380)