Add inbound-filter docs for replay

[cmanallen]

Pre-merge checklist

If you work at Sentry, you're able to merge your own PR without review, but please don't unless there's a good reason.

• Checked Vercel preview for correctness, including links
• PR was reviewed and approved by any necessary SMEs
• PR was reviewed and approved by a member of the Sentry docs team

Description of changes

Add docs describing replays support for inbound-filters.

Extra resources

Ref: getsentry/sentry#44700

[vercel]

The latest updates on your projects. Learn more about Vercel for Git ↗︎

Name	Status	Preview	Comments	Updated (UTC)
sentry-docs	✅ Ready (Inspect)	Visit Preview	💬 Add feedback	May 9, 2024 6:18pm

[codecov]

Bundle Report

Changes will decrease total bundle size by 11 bytes ⬇️

Bundle name	Size	Change
sentry-docs-edge-server	456.68kB	3 bytes ⬇️
sentry-docs-server	7.43MB	2 bytes ⬇️
sentry-docs-client	6.16MB	6 bytes ⬇️

[vivianyentran]

Should we also update the note here? https://docs.sentry.io/concepts/data-management/filtering/#transactions-coming-from-health-check

[cmanallen]

@vivianyentran Seems like that note applies to sessions and not replay.

[bruno-garcia]

How about we call it segment instead of events? Would that be more accurate?

Suggested change

**Note**: Due to a quirk in how Replay emits successful outcomes versus filtered and dropped outcomes, you may observe a larger than expected increase in filtered outcomes. This is not an error. Filtered outcomes are emitted per **event** whereas successful outcomes are emitted per **replay**. A replay being a collection of events means there is a natural imbalance in the number of outcomes per category.

**Note**: Due to a quirk in how Replay emits successful outcomes versus filtered and dropped outcomes, you may observe a larger than expected increase in filtered outcomes. This is not an error. Filtered outcomes are emitted per **segment** whereas successful outcomes are emitted per **replay**. A replay being a collection of segments means there is a natural imbalance in the number of outcomes per category.

[cmanallen]

I didn't know if that was too much "jargon" or if they would understand. I'm happy to change it if you think its better.

[jas-kas]

"Note: Due to a quirk in how Replay emits successful outcomes versus filtered and dropped outcomes, you may observe a larger than expected increase in filtered outcomes." should we say 'on your Stats page' to contextualize this? That's where this info lives for the user (see Stats in left-nav)

[jas-kas]

I think 'segments' is better IMO. Calling a replay a collection of events is pretty confusing since we already have a notion of 'replay events' and that's tied to our billing, and in that world, one replay is one event.

[jas-kas]

Although I will say that it's hard for me to parse this note and the takeaway. @vivianyentran @lizokm perhaps we can reword and shorten?

[jas-kas]

I don't think the Session Replay - Replay Details product page is the right page to show this information. It's a little bit too in the weeds 😅

I think we will need to 100% modify the Inbound Filters docs page -- https://docs.sentry.io/concepts/data-management/filtering/#inbound-data-filters. This is where the Sales team is looking for this info to share with customers. See thread - https://sentry.slack.com/archives/C03USURCFBJ/p1713986617518859?thread_ts=1713986470.110049&cid=C03USURCFBJ

We could also have a note here - https://docs.sentry.io/product/accounts/quotas/manage-replay-quota/

[jas-kas]

Suggested change

	Session replay supports some inbound filtering rules. Those rules are:
	Session Replay supports some inbound filtering rules. Those rules are:

[jas-kas]

Is this the correct phrasing? It's not that inbound filters apply to Session Replay specifically. It's that errors that are dropped due to the aforementioned Inbound Filters, won't also be captured as part ofreplaysOnErrorSampleRate for Session Replay. I think that nuance is important

[lizokm]

@jas-kas @cmanallen what if we said:
"If you've chosen not to capture certain errors by applying any of the below inbound filter rules, those same rules will also apply to Session Replays."

[jas-kas]

"Note: Due to a quirk in how Replay emits successful outcomes versus filtered and dropped outcomes, you may observe a larger than expected increase in filtered outcomes." should we say 'on your Stats page' to contextualize this? That's where this info lives for the user (see Stats in left-nav)

[jas-kas]

I think 'segments' is better IMO. Calling a replay a collection of events is pretty confusing since we already have a notion of 'replay events' and that's tied to our billing, and in that world, one replay is one event.

[jas-kas]

Although I will say that it's hard for me to parse this note and the takeaway. @vivianyentran @lizokm perhaps we can reword and shorten?

[lizokm]

Here's my suggestion :)

[lizokm]

@jas-kas @cmanallen what if we said:
"If you've chosen not to capture certain errors by applying any of the below inbound filter rules, those same rules will also apply to Session Replays."

[lizokm]

Suggested change

**Note**: Due to a quirk in how Replay emits successful outcomes versus filtered and dropped outcomes, you may observe a larger than expected increase in filtered outcomes. This is not an error. Filtered outcomes are emitted per **event** whereas successful outcomes are emitted per **replay**. A replay being a collection of events means there is a natural imbalance in the number of outcomes per category.

**Note**: Because filtered outcomes are emitted per **segment** whereas successful outcomes are emitted per **replay** (a replay being a collection of segments), you may see a noticeable increase in filtered outcomes on your [Stats](https://sentry.io/orgredirect/organizations/:orgslug/stats) page. This is not an error.

@jas-kas here's what I'd recommend.

Or we can do: Note: Because filtered outcomes are emitted per segment whereas successful outcomes are emitted per replay (a replay being a collection of segments), you may see significantly more filtered than successful outcomes on your Stats page. This is not an error.