-
-
Notifications
You must be signed in to change notification settings - Fork 1.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Suggested changes for putting rage click thresholds on more appropriate docs pages #10329
Changes from 3 commits
d045703
1236787
08fa72b
a3f688b
fe3fadd
930c8fb
243a467
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -19,6 +19,27 @@ In order to see rage clicks in your issue stream on the **Issues** page, your or | |
While you can enable **session replay** with JavaScript SDK version 7.27.0, or higher, you'll need to have version 7.60.1 or higher in order to be able to see **rage click issues**. | ||
</Note> | ||
|
||
## Detection Criteria | ||
|
||
"Slow clicks" (also called "dead clicks") are only detected on `<button>`, `<input>`, and `<a>` elements that don't lead to either updates to the DOM or a page scroll within 7 seconds). When the user clicks on one of these elements 3 or more times within that 7 second time frame, it indicates frustration, and the SDK registers a "rage click". | ||
drguthals marked this conversation as resolved.
Show resolved
Hide resolved
|
||
|
||
### Why am I seeing too many or too few rage clicks? | ||
There might be fewer rage clicks than you expect if the user stopped waiting for the site to respond before the 7 second threshold and instead chose to to something else. This is why the rage click issues that you *do* see are so valuable, because the user that clicked at least 3 times and continued waiting at least 7 seconds for the site to respond is likely very frustrated. | ||
|
||
You might also see more rage clicks than you expected from buttons that don't trigger a DOM mutation or page scroll, i.e. Print and Download buttons. There is no reliable way for the SDK to detect that a download or print has initiated, so a slow click might be generated even if the button is not actually "dead". For these cases, you can configure the SDK via `slowClickIgnoreSelectors` - see <PlatformLink to='/session-replay/configuration'>Configuration</PlatformLink> for more details. | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. This link to the configuration redirects to choose which platform you're using first - which looks like an error. Is there a good way to redirect specifically to JS? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. @vivianyentran maybe would know?
drguthals marked this conversation as resolved.
Show resolved
Hide resolved
|
||
|
||
For example, you could ignore detection of dead and rage clicks for download links in your application like this: | ||
drguthals marked this conversation as resolved.
Show resolved
Hide resolved
|
||
|
||
```javascript | ||
Sentry.replayIntegration({ | ||
slowClickIgnoreSelectors: [ | ||
".download", | ||
// Any link with a label including "download" (case-insensitive) | ||
'a[label*="download" i]', | ||
], | ||
}); | ||
``` | ||
|
||
## Get Rage Click Alerts | ||
|
||
To set up alerts and get notified when a rage click occurs, follow these steps: | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think this might be better fit under the other page also edited, the Replay Issues one
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah - I was thinking the same - only thing was that when I was actually searching for this information when I was testing an application I first went to look on the Session Replay docs - so I was trying to find a good place to put this somewhere that made sense on the Session Replay JS SDK docs page...I agree though in general. I couldn't find a good place for it. So happy to have it not show up here.
Reasoning:
I notice rage clicks when I'm looking at the Session Replay, so when I have a question about rage clicks my first inclination is to go to the Session Replay docs, where I couldn't find this information or a link to it.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I was thinking on the
index.md
of the Session Replay JS SDK doc after this section:https://docs.sentry.io/platforms/javascript/session-replay/#error-linking
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
FWIW the original is from the Troubleshooting on the Session Replay JS SDK docs, so removing it completely from this section would seem strange?
There are so many entry points into Session Replay docs though, so I don't think I'm the person who would know the right place necessarily for this.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If we put this as a new page that is a sibling to
/product/session-replay/performance-overhead/
Then in the product space we'll have these in the navbar:
"Rage Click Issues" that we already have, has subheadings: "Detection Criteria, Span Evidence, Fingerprinting" and the new page will have "Dead Clicks and Rage Clicks" only.
... then we have to cross link the pages which is fine, but it just feels like too many pages.
My thought is to put this content directly into
docs/product/issues/issue-details/replay-issues/index.mdx
.That little tree structure is probably in the wrong spot to begin with,
Issues > Issue Details -> X
has a lot of stuff that could be better off inside something like "Issues > Issue Types > X. Like
Issues > Issue Types > N+1 Queriesor
Issues > Issue Types > Rage Clicks`.But lets save that for the next PR