All Products
Search
Document Center

Application Real-Time Monitoring Service:Integrate and use Session Replay and Heatmap for Web & H5

Last Updated:Jun 22, 2026

Overview

Session Replay and Heatmap provide visual, aggregated user behavior analytics to help you identify interaction barriers, optimize page layouts, and improve user experience based on real data.

Session Replay

Session Replay records user operations on a page, including:

  • DOM changes

  • User interactions, such as clicks, inputs, and scrolls

  • Network requests

  • Page performance metrics

You can replay complete user sessions in the monitoring platform to:

  • Quickly locate issues: Replay user actions to reproduce and diagnose error scenarios.

  • Optimize the user experience: Observe real user paths to identify and resolve interaction problems.

  • Increase conversion rates: Analyze user behavior to optimize key flows.

Heatmap

Heatmap collects click data and generates visual heatmaps that help you:

  • Understand user focus: See which areas users click most often.

  • Identify dead clicks: Find areas where users click but receive no response.

  • Optimize page layout: Adjust element positions based on the click heatmap.

  • Improve the user experience: Reduce accidental clicks and increase operational efficiency.

Quick start

Prerequisites

The Real User Monitoring (RUM) SDK v0.1.5 or later must be integrated. Integrate Web & H5 applications.

Enable Session Replay

Add the following configuration to enable Session Replay:

armsRum.init({
  endpoint: "your endpoint",
  replay: true, // Enable session replay
});

Enable Heatmap

Heatmap relies on Session Replay for background page rendering. Enable Session Replay (no specific sample rate is required) and configure trackUserInteractions in the action collector:

armsRum.init({
  endpoint: "your endpoint",
  replay: true, // Enable session replay
  collectors: {
    action: {
      enable: true,
      trackUserInteractions: true, // Enable heatmap data collection
    }
  }
});

Complete configuration example

The following example enables both Session Replay and Heatmap:

armsRum.init({
  endpoint: "https://your-endpoint.com/rum/web/v2",
  // Session Replay configuration
  replay: {
    enable: true,
    sampling: 20, // Session replay sample rate. 20 means 20% of sessions are recorded.
    privacy: {
      level: 'user-input', // Mask only user input.
    }
  },
  
  // Heatmap configuration
  collectors: {
    action: {
      enable: true,
      trackUserInteractions: true, // Enable heatmap analysis
      sampling: 100, // 100% sample rate
    }
  },
  
  // Session configuration
  sessionConfig: {
    sampleRate: 1, // Session sampling configuration. The default sample rate is 100%.
    storage: 'localStorage',
  }
});

Session Replay configuration

Configuration items

Configure Session Replay with the replay parameter, which supports both simple enablement and detailed configuration.

Parameter

Type

Description

Required

Default

enable

boolean

Enables session replay.

No

false

sampling

number

Sample rate as a percentage. Valid values: 0 to 100. For example, 20 means 20% of sessions are recorded.

No

1, which means a 1% sample rate.

url

string

API endpoint for replay data storage.

No

Automatically generated based on the endpoint.

privacy

object

Privacy protection configuration.

No

{ level: 'mask' }

Privacy configuration

Before enabling Session Replay, perform a privacy impact assessment. Configure privacy protection to control how sensitive information is masked in recordings.

Parameter

Type

Description

Required

Default

level

string

Privacy protection level. Valid values:

- 'allow': Records all content without masking.

- 'mask': Masks all text content and input fields.

- 'user-input': Masks only user input, such as passwords and input fields.

- 'allowlisted': Records only allowlisted elements. All other content is masked.

No

'mask'

The allowlisted parameter is an array that takes effect when level is set to 'allowlisted'. It specifies element selectors or elements to record.

You can also control recording behavior with CSS classes:

  • rum-block: Excludes the element and its children from recording. A placeholder of the same size appears during replay.

  • rum-ignore: Excludes input events of the element from recording.

  • rum-mask: Masks the text content of the element and its children.

<!-- This area will not be recorded -->
<div class="rum-block">
  This content will not be recorded
</div>

<!-- Prevents recording of input events for this element -->
<input class="rum-ignore" />

<!-- Masks sensitive information -->
<div class="rum-mask">
  Sensitive information will be masked
</div>

Configuration examples

Example 1: Simple enablement (default configuration)

armsRum.init({
  endpoint: "your endpoint",
  replay: true
});

Example 2: Set the sample rate

armsRum.init({
  endpoint: "your endpoint",
  replay: {
    enable: true,
    sampling: 20, // 20% of sessions are recorded to reduce storage costs.
  }
});

Example 3: Privacy protection - Mask all text

armsRum.init({
  endpoint: "your endpoint",
  replay: {
    enable: true,
    privacy: {
      level: 'mask'  // Masks all text content and input fields.
    }
  }
});

Example 4: Privacy protection - Mask only user input

armsRum.init({
  endpoint: "your endpoint",
  replay: {
    enable: true,
    privacy: {
      level: 'user-input'  // Masks only user input, such as passwords and input fields.
    }
  }
});

Example 5: Privacy protection - Whitelist mode

armsRum.init({
  endpoint: "your endpoint",
  replay: {
    enable: true,
    privacy: {
      level: 'allowlisted',
      allowlisted: ['.main-content', '#app', '.product-card']  // Records only these elements.
    }
  }
});

How it works

  1. When recording starts: Session Replay starts recording at the following times:

    • When a session is initialized

    • After the page finishes loading (DOMContentLoaded)

  2. Data upload: Recorded data is uploaded as follows:

    • When the page is hidden (visibilitychange)

    • When the page is frozen (freeze)

    • Before the page unloads (beforeunload)

    • When the route changes (pv)

  3. Recording limits:

    • The maximum recording length for a single session is 1 hour (3600 seconds).

    • Recording stops automatically after the maximum length is reached.

  4. Sampling control:

    • The sample rate is controlled at the session level. A replay is sampled only if its corresponding session is sampled.

    • You can configure this using replay.sampling.

    • The sampling decision is made when the session is initialized and remains unchanged for the entire session.

Heatmap configuration

Configuration items

Configure Heatmap with the collectors.action collector. Set trackUserInteractions to true for heatmap data collection.

Parameter

Type

Description

Required

Default

enable

boolean

Enables click event collection.

No

true

trackUserInteractions

boolean

Tracks user interactions for heatmap analysis. When true, collects click positions and target element details.

No

false

sampling

number

Sample rate as a percentage. Valid values: 0 to 100.

No

100

Configuration details

  • trackUserInteractions: false (default):

    • Collects click events only for interactive elements such as `button`, `a`, `input`, `select`, `option`, and `textarea`.

    • Collected data includes basic information such as the element name, XPath, and duration.

    • Suitable for basic click statistics.

  • trackUserInteractions: true:

    • Collects click events for all elements, including non-interactive elements.

    • Collected data includes:

      • Position information: X and Y coordinates of the click relative to the document and the element.

      • Target element information: Element selector, width, height, whether it is interactive, and whether the interaction is trusted.

      • Viewport information: Width and height of the page viewport.

    • Suitable for heatmap generation scenarios.

Configuration examples

Example 1: Enable Heatmap (recommended configuration)

armsRum.init({
  endpoint: "your endpoint",
  collectors: {
    action: {
      enable: true,
      trackUserInteractions: true,  // Enable heatmap analysis
      sampling: 100,  // 100% sample rate
    }
  }
});

Example 2: Collect only basic click events (Heatmap disabled)

armsRum.init({
  endpoint: "your endpoint",
  collectors: {
    action: {
      enable: true,
      trackUserInteractions: false,  // Disable heatmap
      sampling: 100,
    }
  }
});

Collected data fields

When trackUserInteractions: true, each collected click event contains the following fields:

position (Position information)

{
  x: 123,        // Click X coordinate (relative to the document)
  y: 456,        // Click Y coordinate (relative to the document)
  ex: 50,        // Relative X coordinate within the element
  ey: 30         // Relative Y coordinate within the element
}

target (Target element information)

{
  selector: "#root > div > button:nth-child(15)",  // Element selector
  width: 120,      // Element width (in pixels)
  height: 40,     // Element height (in pixels)
  reaction: 1,     // Specifies whether the element is interactive (0 = non-interactive, 1 = interactive)
  trust: 1         // Specifies whether the interaction is trusted (0 = not trusted, 1 = trusted)
}

viewport (Viewport information)

{
  width: 1920,    // Viewport width (in pixels)
  height: 1080    // Viewport height (in pixels)
}

How it works

  1. Event listener: The SDK listens for click events on the page during the capture phase.

  2. Element detection:

    • If trackUserInteractions: false, only clicks on interactive elements are collected.

    • If trackUserInteractions: true, clicks on all elements are collected.

  3. Data collection:

    • Calculates click position relative to the document and the element.

    • Retrieves element information such as the selector, size, and interactivity.

    • Determines interaction trustworthiness based on element size, visibility, and other factors.

  4. Data reporting: Collected data is reported to the monitoring platform along with other RUM events.

Use cases

Common scenarios for Session Replay

1. Reproduce and debug errors

Scenario: A user reports an error but cannot describe how to reproduce it.

Solution:

  • Enable Session Replay and set a reasonable sample rate, such as 20%.

  • When an error occurs, use the session ID to find the corresponding replay.

  • Replay the user's actions to quickly identify the root cause.

2. Optimize user experience

Scenario: You want to analyze user paths in key flows and improve conversion rates.

Solution:

  • Increase the sample rate for key pages such as the purchase flow.

  • Replay user sessions to observe user habits.

  • Find interaction barriers and optimize the page layout and interactions.

3. Support customer service

Scenario: Customer service needs to understand what problem a user encountered.

Solution:

  • Find the corresponding session replay using the user ID or session ID.

  • Replay the user's actions to quickly understand the problem context.

  • Provide a more accurate solution.

Scenarios for Heatmap

1. Optimize page layout

Scenario: You want to identify the most frequently clicked areas and optimize the page layout.

Solution:

  • Enable heatmap data collection.

  • View the click heatmap in the monitoring platform.

  • Adjust the position of important elements based on the heatmap.

2. Analyze dead clicks

Scenario: You want to find areas where users click but receive no response (dead clicks).

Solution:

  • Use the target.reaction field to identify clicks on non-interactive elements.

  • Analyze the distribution and frequency of dead clicks.

  • Optimize the page to reduce dead clicks.

3. Optimize for mobile devices

Scenario: Mobile users have a high accidental click rate, and you need to optimize click areas.

Solution:

  • Use the heatmap to view the click distribution on mobile devices.

  • Identify hotspot areas with frequent accidental clicks.

  • Adjust element size and positioning to reduce accidental clicks.

Best practices

Best practices for Session Replay

1. Set the sample rate

  • Production environment: Set the sample rate to 10% to 20% to balance cost and coverage.

  • Staging environment: Set the sample rate to 100% to help with troubleshooting.

  • Key pages: Increase the sample rate for pages that are critical to conversion rates.

const isProduction = process.env.NODE_ENV === 'production';
armsRum.init({
  endpoint: "your endpoint",
  replay: {
    enable: true,
    sampling: isProduction ? 20 : 100,  // 20% for production, 100% for staging
  }
});

2. Privacy protection

  • Sensitive information: For pages that contain sensitive information, use the 'mask' or 'user-input' level.

  • Public pages: For public pages, you can use the 'allow' level to obtain more complete replays.

  • Compliance requirements: Set the privacy level based on your compliance requirements.

3. Optimize storage costs

  • Set a reasonable sample rate based on your needs.

  • For non-critical pages, you can lower the sample rate or disable recording.

  • Periodically clear expired recording data. The default retention period is 30 days.

4. Performance considerations

  • Session Replay may affect page performance. Enable it only on key pages.

  • Monitor the volume of recorded data to avoid affecting reporting performance.

Best practices for Heatmap

1. Set the sample rate

  • Analysis phase: Use a 100% sample rate to obtain complete data.

  • Stable operation: You can lower the rate to 50% to 80% to reduce data volume.

  • High-traffic pages: You can lower the sample rate as needed.

armsRum.init({
  endpoint: "your endpoint",
  collectors: {
    action: {
      enable: true,
      trackUserInteractions: true,
      sampling: 80,  // 80% sample rate
    }
  }
});

2. Combine with business analysis

  • Analyze heatmaps with other dimensions, such as page paths and user properties.

  • Focus on the click heatmaps of key conversion paths.

  • Periodically analyze changes in heatmaps to optimize the page layout.

3. Mobile optimization

  • Accidental click rates are higher on mobile devices. Pay attention to dead clicks.

  • Use the target.trust field to identify trusted clicks.

  • Optimize click area sizes for mobile elements.

FAQ

FAQ about Session Replay

Does enabling Session Replay affect page performance?

Session Replay affects page performance in the following areas:

  • Memory usage: Recorded data consumes some memory.

  • CPU usage: Monitoring DOM changes consumes CPU resources.

  • Network transfer: Uploading recorded data consumes network bandwidth.

Recommendations:

  • Set a reasonable sample rate to avoid recording all sessions in production.

  • Disable recording on non-critical pages.

  • Monitor page performance metrics to ensure the impact remains acceptable.

How can I control the volume of recorded data?

You can control data volume with the following strategies:

  1. Lower the sample rate: Reduce the number of recorded sessions.

  2. Set the privacy level: Use the 'mask' or 'user-input' level to reduce the amount of recorded content.

  3. Limit the recording length: A single session can be recorded for a maximum of 1 hour.

  4. Filter unwanted elements: Use the allowlisted mode to record only key areas.

Is recording for Canvas and IFrame elements supported?

No. For compliance and performance reasons, Canvas and IFrame recording is not currently supported. These areas appear as blank spaces during replay.

How does the sample rate work?

The sampling decision is made when a session initializes and persists for the entire session duration. For example:

  • If the main RUM session sample rate is 20% and the replay sample rate is 20%, the effective sample rate for Session Replay is 4% (20% × 20%).

  • If the replay sample rate is set to 20%, 20% of sessions are recorded.

  • The sampling decision is based on a hash of the session ID, ensuring consistency for the same session.

  • Once a session is selected for recording, it is recorded for its entire duration.

FAQ about Heatmap

When is heatmap data reported?

Heatmap data is reported along with other RUM events at the following times:

  • When reportConfig.maxEventCount is reached, data is reported in a batch.

  • When the reportConfig.flushTime interval is reached.

  • Before the page is unloaded.

What information does heatmap data contain?

When trackUserInteractions: true, heatmap data includes the following information:

  • Position information: X and Y coordinates of the click (document coordinates and coordinates within the element).

  • Element information: Selector, size, and whether the element is interactive.

  • Interaction information: Whether the interaction is trusted.

  • Viewport information: Width and height of the page viewport.

How can I determine if a click is valid?

Use the following fields to determine click validity:

  • target.reaction: 1 indicates an interactive element, and 0 indicates a non-interactive element.

  • target.trust: 1 indicates a trusted interaction, and 0 indicates a possible accidental click.

A dead click is typically indicated by reaction: 0 or trust: 0.