---
title: Configuring Journeys in Datadog
description: >-
  Configure journeys with meaningful start and end events, technical coverage,
  SLOs, Synthetic tests, and variants.
breadcrumbs: >-
  Docs > Journey Monitoring > Journey Monitoring Guides > Configuring Journeys
  in Datadog
---

> For the complete documentation index, see [llms.txt](https://docs.datadoghq.com/llms.txt).

# Configuring Journeys in Datadog

## Overview{% #overview %}

This guide explains how to configure journeys that represent important user flows and reveal their health.

Journey configuration has three steps:

1. Create a journey and define its user flow.
1. Add RUM operations that represent critical technical steps.
1. Add Synthetic tests that cover the journey.

After completing these steps, validate the journey's key performance indicators (KPIs), operations, service level objectives (SLOs), tests, and variants.

## When to use Journey Monitoring{% #when-to-use-journey-monitoring %}

Journey Monitoring combines user behavior and technical health for an end-to-end flow. It can serve as the primary place to monitor and troubleshoot a flow that would otherwise require separate configurations across several products.

Common alternatives include:

- **Real User Monitoring (RUM)**:
  - Funnels in the RUM Session Explorer or funnel widgets based on RUM events
  - Widgets that track user activity, such as button clicks or page views
  - Custom metrics or actions that measure flow volume, time to completion, or completed journeys
  - Custom vitals that represent key technical steps, which RUM operations can represent within a journey
- **Synthetic Monitoring**: Multiple tests that cover the same flow but are not organized into a journey's test suite
- **Product Analytics**: Funnels, journey paths, or other visualizations that track behavior across an end-to-end flow

Journey Monitoring uses Product Analytics to understand user behavior and experience, RUM to evaluate performance and availability, and Synthetic tests to detect regressions and measure journey uptime.

## Before you begin{% #before-you-begin %}

Before following this guide, review the [Journey Monitoring overview and prerequisites](https://docs.datadoghq.com/journey_monitoring.md). To use Journey Monitoring, your organization must have a paid or trial subscription to at least one of the following products: RUM without Limits, Product Analytics, Synthetic Browser Tests, or Synthetic Mobile Tests.

### Permissions and roles{% #permissions-and-roles %}

Journey Monitoring uses assets from several products, so access to journeys and linked assets depends on each product's permissions.

To create or edit journeys:

- Your role must have Journey Monitoring write access.
- Creating a journey's Synthetic test suite also requires Synthetic Monitoring write access. Without it, Datadog creates the journey without a test suite, and you can add one later.

For more details about viewing and editing journeys and their linked assets, see [Roles and Permissions](https://docs.datadoghq.com/journey_monitoring/roles_and_permissions.md).

## Step 1: Create a journey{% #step-1-create-a-journey %}

### Choose a user flow{% #choose-a-user-flow %}

Create journeys for critical, user-facing flows that users must complete to support a business outcome. A journey should span multiple steps and represent a significant action.

Follow these guidelines to keep each journey focused:

**Do:**

- Create a separate journey for each distinct user flow, and connect related journeys to one another.
- Use one high-level journey and attribute filters to compare cohorts, such as users in the United States and the United Kingdom.

**Do not:**

- Create a journey for a single, short interaction. Use a [RUM operation](https://docs.datadoghq.com/real_user_monitoring/operations_monitoring.md) instead.
- Combine several distinct user flows in one journey.
- Create duplicate journeys that differ only by an attribute value, such as country.

### Choose a creation method{% #choose-a-creation-method %}

Create a journey manually or start with a suggested journey. For instructions, see [Journey Monitoring setup](https://docs.datadoghq.com/journey_monitoring.md#setup).

Choose a creation method based on whether you have a specific user flow in mind:

- Start with a [suggested journey](https://docs.datadoghq.com/journey_monitoring/map/suggested_journeys.md) if you are unsure which journeys to create. Suggested journeys provide high-level KPIs, including starts, conversions, and conversion rate.
- Review new suggested journeys as you release features and update the application experience. Datadog generates suggestions based on user activity in the application.
- Create a journey manually when you have a specific user flow that you want to monitor.

### Define start and end conditions{% #define-start-and-end-conditions %}

A journey is defined by its start and end events. Select action events, view events, or both.

#### Multiple start and end events{% #multiple-start-and-end-events %}

Multiple start events can represent several entry points into the same user flow. Multiple end events can represent several valid conclusions.

Each additional event broadens the journey definition. A large number of start or end events can make the journey's scope unclear and its KPIs less precise.

#### Attribute filters{% #attribute-filters %}

Journey-level attributes include or exclude broad cohorts, such as internal users. Attributes on individual start and end conditions further narrow the flow.

Including important attribute filters in the journey's name or description helps users understand the scope of its KPIs.

#### Referrer paths{% #referrer-paths %}

Referrer paths limit a start or end event to instances that follow a specific page view. They help distinguish an event that appears in several journey contexts from the instance that belongs to a particular journey.

#### Journey variants{% #journey-variants %}

The base journey definition includes only start and end events. A variant adds a specific sequence of intermediate action or view events between those points. Variants distinguish common paths through the same journey without changing the journey's overall scope.

Selecting a variant filters the journey's metrics and telemetry to that sequence of events. This lets you compare volume, conversion rate, and time to completion across different paths. Attribute filters can further narrow a variant to a specific cohort.

Each variant requires a unique name and at least one intermediate event. For information about creating, analyzing, and deleting variants, see [Journey variants](https://docs.datadoghq.com/journey_monitoring/details_report/variants.md).

#### Start and end event selection{% #start-and-end-event-selection %}

A start event should clearly begin the journey and represent an intentional user action.

{% alert level="danger" %}
Choose an end event that confirms that the journey is complete. Clicking "Pay" or "Submit" doesn't mean the action worked. If a later event confirms success, use that event instead, so failed attempts aren't counted as completed journeys.
{% /alert %}

For example:

- **Sign-in journey**
  - Start: The user opens the sign-in page.
  - End: The application redirects the user to the home screen.
  - Avoid ending in: The user clicks **Sign in**.
- **Checkout journey**
  - Start: The user opens the checkout page.
  - End: The application displays a payment confirmation modal.
  - Avoid ending in: The user clicks **Pay**.
- **Form submission journey**
  - Start: The user opens the form.
  - End: The application displays a submission confirmation message.
  - Avoid ending in: The user clicks **Submit**.

### Add names, tags, and ownership{% #add-names-tags-and-ownership %}

Tags and team ownership help teams find relevant journeys and filter the journey catalog. A consistent naming and tagging convention keeps journeys organized as the catalog grows.

## Step 2: Add RUM operations{% #step-2-add-rum-operations %}

RUM operations provide technical coverage for key moments in the journey. Their availability and latency help explain whether technical performance contributes to user drop-off.

### Link suggested operations{% #link-suggested-operations %}

The journey details report uses time correlation to suggest existing RUM operations that may be part of the journey. Link an operation only if users encounter it while completing the journey.

{% image
   source="https://docs.dd-static.net/images/journey_monitoring/journey-monitoring-correlated-operations.ee1b839b41f9076a911e3923dbccd6e3.png?auto=format&fit=max&w=850 1x, https://docs.dd-static.net/images/journey_monitoring/journey-monitoring-correlated-operations.ee1b839b41f9076a911e3923dbccd6e3.png?auto=format&fit=max&w=850&dpr=2 2x"
   alt="The Journey Monitoring details report showing time-based correlated RUM operations with executions, success rate, latency, and SLO creation options." /%}

Linking an operation:

- Links the operation to the journey and identifies it as part of the journey's critical path.
- Automatically creates an availability SLO for the operation if it does not already have an SLO.

### Create operations{% #create-operations %}

Create an operation with one of the following methods:

- [In Datadog](https://docs.datadoghq.com/real_user_monitoring/operations_monitoring.md?tab=browser#create-operations-from-datadog)
- [With the RUM Operations API](https://docs.datadoghq.com/api/latest/rum-operations.md)
- [With the RUM SDK APIs](https://docs.datadoghq.com/real_user_monitoring/operations_monitoring.md?tab=browser#create-operations-with-the-sdk-apis)

### Create SLOs for operations{% #create-slos-for-operations %}

Each linked operation requires at least one SLO for Datadog to evaluate its contribution to the journey. An operation can have availability SLOs, latency SLOs, or both. For guidance, see [Best practices for creating SLOs on RUM operations](https://docs.datadoghq.com/real_user_monitoring/guide/best-practices-for-creating-slos-on-operations.md).

When you create an operation from the journey details report, Datadog links it to the journey and creates an availability SLO. If you create an operation with the RUM SDK APIs or RUM Operations API, use the [RUM Operations API](https://docs.datadoghq.com/api/latest/rum-operations.md) to link it to the journey.
Start with the operation that has the greatest effect on journey conversion. Add more operations as needed.
- For a user sign-in journey, monitor the final sign-in action to verify that valid credentials result in successful authentication.
- For an ecommerce checkout journey, monitor the payment action because a failed payment prevents the user from completing the journey.

## Step 3: Add Synthetic test coverage{% #step-3-add-synthetic-test-coverage %}

Synthetic tests provide technical coverage for critical journey paths. Test failures can indicate regressions that affect users, and covering tests determine journey uptime.

Datadog automatically creates a Synthetic test suite and an editable uptime SLO with a default objective of 99.9% for each journey. It also adds Synthetic tests that cover the journey. For information about test coverage, managing tests, and the uptime SLO, see [Journey uptime](https://docs.datadoghq.com/journey_monitoring/uptime.md).

### Review journey coverage{% #review-journey-coverage %}

Datadog uses RUM data to identify Synthetic tests that cover a journey. These tests appear on the journey details page and the Synthetic test suite page.

- Review the tests that Datadog identifies as covering the journey.
- If Datadog identifies covering tests that are not in the suite, an indicator highlights the additional tests.

### Add tests to a journey{% #add-tests-to-a-journey %}

Add covering tests when the suite is empty or when Datadog identifies additional tests:

- To add existing tests, select **Manage journey coverage**, then select the tests to add.
- To create coverage, create a [browser test](https://docs.datadoghq.com/synthetics/browser_tests.md) or [mobile application test](https://docs.datadoghq.com/synthetics/mobile_app_testing.md), then add it to the journey's suite. For more information, see [Test Suites](https://docs.datadoghq.com/synthetics/test_suites.md).

{% image
   source="https://docs.dd-static.net/images/journey_monitoring/journey-monitoring-covering-tests.952a4d127528df75887370779f9373e2.png?auto=format&fit=max&w=850 1x, https://docs.dd-static.net/images/journey_monitoring/journey-monitoring-covering-tests.952a4d127528df75887370779f9373e2.png?auto=format&fit=max&w=850&dpr=2 2x"
   alt="The Manage Tests in Suite panel showing Synthetic browser tests that cover a journey." /%}

**Preview**: When no Synthetic test covers a journey, [Bits Testing](https://www.datadoghq.com/blog/bits-testing-test-coverage/) can generate a covering browser test. [Sign up for the Bits Testing preview](https://www.datadoghq.com/product-preview/bits-testing/).

### Maintain coverage{% #maintain-coverage %}

- Changes to a journey's start or end conditions can affect which tests cover it. Review coverage after changing these conditions.
- A journey reports uptime only when its suite contains at least one covering test. If the journey loses coverage, it stops reporting uptime.

Managing coverage modifies Synthetic tests, so it requires Synthetic Monitoring write access and a restriction policy on the suite. See [Roles and Permissions](https://docs.datadoghq.com/journey_monitoring/roles_and_permissions.md).

## Validate the Journey Monitoring configuration{% #validate-the-journey-monitoring-configuration %}

A well-configured journey has the following characteristics:

- Its top-level KPIs—starts, conversion volume, conversion rate, and time to convert—align with expected user behavior.
- Its linked RUM operations and Synthetic tests represent the technical performance of critical steps in the journey.
- Each linked operation has at least one SLO and a high success rate, indicating that critical steps are available to users.
- Its Synthetic tests produce consistent results without intermittent failures.
- If users can complete the journey through different expected paths, variants represent those paths.

## Further reading{% #further-reading %}

Additional helpful documentation, links, and articles:

- [Learn about Journey Monitoring](https://docs.datadoghq.com/journey_monitoring.md)
- [Learn about the journey details report](https://docs.datadoghq.com/journey_monitoring/details_report.md)
- [Learn about journey uptime](https://docs.datadoghq.com/journey_monitoring/uptime.md)