feat(discover-split): Update Discover, Alerts, Dashboards docs (#11101)

In preparation for the dataset split in discover and dashboards, we need
to update the docs to reflect this new change.

The changes typically involve removing `event.type:error` or
`event.type:transaction` from being mentioned in search fields because
after the dataset is selected, these are redundant. It also updates
screenshots and calls out the dataset selector more explicitly.

Co-authored-by: Liza Mock <[email protected]>

docs/concepts/search/searchable-properties/events.mdx

@@ -8,8 +8,8 @@ Events are the underlying event data captured using Sentry SDKs — that is, err
 
 You can search by event properties in the following [sentry.io](https://sentry.io) pages:
 
-- Discover - in the query builder
-- Dashboards - within the widget builder, depending on dataset selection
+- Discover - in the query builder (depending on the dataset selection)
+- Dashboards - within the widget builder (depending on dataset selection)
 - Performance - only in transaction summaries
 - Issues - as indicated in the list below
 - Alerts - when creating a metric alert

docs/product/alerts/create-alerts/metric-alert-config.mdx

@@ -85,7 +85,6 @@ For some metric alerts, you can set the event type that you want to be alerted a
 - `event.type:error` OR `event.type:default`
 - `event.type:default`
 - `event.type:error`
-- `event.type:transaction`
 
 ### Tags & Properties
 

docs/product/dashboards/widget-builder/index.mdx

@@ -48,15 +48,19 @@ A big number visualization displays the current value of a single function. This
 
 ## Choose Your Dataset
 
-In the dataset selection step, choose which type of data you would like to use in your widget. This data is classified into two different datasets: [errors and transactions](#errors--transactions) and [issues](#issues).
+In the dataset selection step, choose which type of data you would like to use in your widget. This data is classified into four different datasets: [errors](#error), [transactions](#transactions), [issues](#issues), and [releases](#releases).
 
-### Errors & Transactions
+### Errors
+Choosing "Errors" allows you to query and aggregate error events in the same way you would for a [Discover Query](/product/explore/discover-queries/). This data is comprised of errors that occur in your application, which Sentry will use to group into issues, for example:
 
-Choosing "Errors and Transactions" allows you to query and aggregate error and transaction events in the same way you would for a [Discover Query](/product/explore/discover-queries/). Some widget examples include:
+- Users most affected by errors
+
+### Transactions
+
+Choosing "Transactions" allows you to query and aggregate transaction events in the same way you would for a [Discover Query](/product/explore/discover-queries/). This data is comprised of events that track the performance of operations in your application. Some widget examples include:
 
 - Tracking performance of an endpoint
 - Throughput by country
-- Users most affected by errors
 
 ### Issues
 

docs/product/dashboards/widget-library/index.mdx

@@ -29,16 +29,16 @@ You can change the title, queries, fields, visualization types, sort order, and
 
 To monitor how your app is performing on a certain release, you can modify the "Duration Distribution" widget by adding the release version to the search condition:
 
-- Search condition 1: `event.type:transaction release.version:{version}`
+- Search condition 1: `release.version:{version}`
 
 To compare performance with another release version, you can add another query by clicking the "Add Query" button and querying for a different release version:
 
-- Search condition 2: `event.type:transaction release.version:{another_version}`
+- Search condition 2: `release.version:{another_version}`
 
 You can also compare performance before and after a certain version with the following conditions:
 
-- Search condition 1: `event.type:transaction release.version:<{version}`
-- Search condition 2: `event.type:transaction release.version:>={version}`
+- Search condition 1: `release.version:<{version}`
+- Search condition 2: `release.version:>={version}`
 
 ### Response thresholds
 
@@ -52,15 +52,15 @@ Set one of the y-axis values to `count()` and remove the other two axes:
 
 To the first query, add the search condition for satisfactory transaction duration (this example uses 300ms as the satisfactory response threshold):
 
-- Search condition 1: `event.type:transaction transaction.duration:<300`
+- Search condition 1: `transaction.duration:<300`
 
 Add another query for the tolerable condition by clicking the "Add Query" button. In this example, we're using the [Apdex](/product/performance/metrics/#apdex) definition where tolerable response times are between the satisfactory threshold and four times the satisfactory threshold:
 
-- Search condition 2: `event.type:transaction (transaction.duration:<1200 AND transaction.duration:>=300)`
+- Search condition 2: `transaction.duration:<1200 AND transaction.duration:>=300`
 
 Finally, add a third query for for the frustrating transaction duration:
 
-- Search condition 3: `event.type:transaction transaction.duration:>=1200`
+- Search condition 3: `transaction.duration:>=1200`
 
 The chart now shows cumulative counts at different response time thresholds.
 

docs/product/explore/discover-queries/query-builder.mdx

@@ -15,12 +15,17 @@ From the **Discover** page, you can build a query in three ways.
   2. Enter a new display name
   3. Click "Save"
 
-There are four main building blocks that impact the results of your saved query. You can use a combination of these to narrow down your search.
+There are five main building blocks that impact the results of your saved query, a combination of which can be used to narrow down your search:
 
-1. Project, environment, and date range filters
-2. Search Conditions
-3. Interactive Graph
-4. Table Columns
+1. Dataset selection
+2. Project, environment, and date range filters
+3. Search conditions
+4. Interactive graph
+5. Table columns
+
+## Dataset Selection
+
+The dataset selector allows you to query for either errors or transactions. You can only query one dataset at a time. The errors dataset returns events related to errors, while the transactions dataset returns transaction events that help you see application performance. 
 
 ## Filter by Project, Environment, and Date Range
 
@@ -101,8 +106,16 @@ Above the table, click "Columns" to open the modal that shows you a list of all
 
 ### Stacking Functions
 
-You can also add any of the following functions as columns to stack events:
+You can also add the following functions as columns to stack events, depending on the selected dataset:
+
+#### Errors
+- `count()`
+- `count_if(...)`
+- `count_unique(...)`
+- `eps()`
+- `epm()`
 
+#### Transactions
 - `any(...)`
 - `apdex(...)`
 - `avg(...)`

docs/product/explore/discover-queries/uncover-trends.mdx

@@ -24,7 +24,7 @@ Sentry notifies you in real-time when your application breaks, and then provides
 
 2. Select the projects, environments, and date range of errors you'd like to query.
 
-3. Sentry monitors different types of events for errors and performance. To query issues, filter by `event.type:error` in the search bar.
+3. Sentry monitors different types of events for errors and performance. To query issues, select the "Errors" dataset using the Dataset dropdown.
 
    ![Filter by Error type](./img/004.png)
 
@@ -57,7 +57,8 @@ The true power of **Discover** lies in its ability to query through all your err
 
 Create a report looking into all the errors occurring in the URL endpoints across your applications.
 
-- Search condition: `event.type:error has:url`
+- Dataset: Errors
+- Search condition: `has:url`
 - Table columns: `url`, `platform.name`, `count()`
 
 ![Errors by URL](./img/005.png)
@@ -71,7 +72,8 @@ Create a report looking into all the errors occurring in the URL endpoints acros
 
 Whether your code is running on mobile, in browser, or on a server, an unhandled fatal error might crash your application. To find out where those crashes are happening, run the following query in **Discover**:
 
-- Search condition: `event.type:error handled:no level:fatal`
+- Dataset: Errors
+- Search condition: `handled:no level:fatal`
 - Table columns: `mechanism`, `platform.name`, `count()`
 
   ![Crashes](./img/006.png)
@@ -87,7 +89,8 @@ To look deeper into one of the crash types:
 
 To find out which files in your codebase are generating the most errors, run the following query in **Discover**:
 
-- Search condition: `event.type:error has:stack.filename`
+- Dataset: Errors
+- Search condition: `has:stack.filename`
 - Table columns: `stack.filename`, `count()`, `count_unique(issue)`
 
 ![By File Names](./img/010.png)
@@ -102,7 +105,7 @@ You can continue exploring a specific filename by adding it to the filter and ch
 
 To find out how the health of a specific project is improving (or not) over time as you release new versions, create the following query:
 
-- Search condition: `event.type:error`
+- Dataset: Errors
 - Table columns: `release`, `count()`, `count_unique(issue)`
 
 ![Issues per release](./img/012.png)