Skip to content
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

Merged
merged 7 commits into from
Jun 17, 2024
Original file line number Diff line number Diff line change
Expand Up @@ -77,33 +77,6 @@ We're always working on ways to reduce the bundle size. Additionally, there are

</Expandable>

<Expandable title="How does Rage Click detection work?">

The Replay SDK tries to detect cases where a user clicked on something, but nothing happened. This is called a "Dead Click" -- a click that seems to be "dead" and does nothing, from the user's perspective. This can happen if a bug prevents the UI from being correctly updated after a button is clicked.

The way that the Replay SDK detects this is by checking if a click on a `<button>` or `<a>` element doesn't lead to either updates to the DOM or a page scroll. If within 7 seconds no updates are detected, the SDK will generate a "Slow Click" in the Replay UI. (We call it a "Slow Click" because it may be possible that something will happen after the 7s, but we chose this as a cutoff time.)

Another concept related to this is "Rage Clicks". A "Rage Click" is when a user clicks on an element many times, which indicates frustration that something isn't working.

When a Slow Click and a Rage Click come together, we have a very good indicator that something is actually wrong, and the Replay SDK will generate a "Rage Click" for this.

Note that there are some limitations to this. On the one hand, there may be _false negatives_ -- we cannot detect all cases; for example, imagine a user clicks a "dead" button, but then clicks a different button afterwards that leads to a DOM update. In this case, since we cannot attribute the DOM update to a specific button, we'll _not_ capture this slow click.

On the other hand, there may be _false positives_. For example, if a user clicks a link that leads to a file download, there is no reliable way to detect that a download was initiated, so a Slow Click may 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.

For example, you could ignore detection of dad and rage clicks for download links in your application like this:

```javascript
Sentry.replayIntegration({
slowClickIgnoreSelectors: [
".download",
// Any link with a label including "download" (case-insensitive)
'a[label*="download" i]',
],
});
```
</Expandable>

<Expandable title='I see the message: "A large number of mutations was detected (N). This can slow down the Replay SDK and impact your customers."'>

The Sentry SDK attempts to minimize potential [performance overhead](/product/session-replay/performance-overhead/#how-is-session-replay-optimized) in a few different ways. For example, by keeping track of the number of DOM mutations that are happening then disabling recording when a large number of changes are detected. Many simultaneous mutations can slow down a web page whether Session Replay is installed or not, but when a large number of mutations happen, the Replay client can incur an additional slowdown because it records each change.
Expand Down
Original file line number Diff line number Diff line change
Expand Up @@ -109,6 +109,16 @@ In `session` mode, this will upload any pending recording data to Sentry. In `bu

Note that it's safe to call `flush()` at any time, even if Session Replay is stopped, in which case, it will do nothing.

## Dead Clicks and Rage Clicks
Copy link
Member

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

Copy link
Contributor Author

@drguthals drguthals Jun 8, 2024

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.

Copy link
Contributor Author

@drguthals drguthals Jun 8, 2024

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

Copy link
Contributor Author

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.

Copy link
Member

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:

Issues
∟ Issue Details
    ∟ Rage Click Issues
Session Replay
∟ Dead & Rage Clicks       <- the new page

"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 QueriesorIssues > Issue Types > Rage Clicks`.
But lets save that for the next PR


The Replay SDK tries to detect cases where a user clicked on something, but nothing happened. This is called a "dead click" -- a click that seems to be "dead" and does nothing, from the user's perspective. This can happen if a bug prevents the UI from being correctly updated after a button is clicked.

Another concept related to this is "rage clicks". A rage click is when a user clicks on an element many times in a short period, which indicates frustration that something isn't working.

When a slow click and a rage click come together, we have a very good indicator that something is actually wrong, and the Replay SDK will generate a "rage click" for this.

Session Replay will generate and link [Rage Click Issues](https://docs.sentry.io/product/issues/issue-details/replay-issues/) to help you identify user frustration and appropriately prioritize issues.

## Examples of Custom Sampling

There are ways to enable custom sampling if you're interested in tracking a particular action or group, for example, a specific segment of users or a problematic URL.
Expand Down
21 changes: 21 additions & 0 deletions docs/product/issues/issue-details/replay-issues/index.mdx
Original file line number Diff line number Diff line change
Expand Up @@ -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.
Copy link
Contributor Author

Choose a reason for hiding this comment

The 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?

Copy link
Contributor Author

Choose a reason for hiding this comment

The 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:
Expand Down
Loading