Session Replay Android Middleware

This article covers the installation of Session Replay using the Android SDK middleware. If your app is already instrumented with (maintenance) Amplitude SDK, use this option.

If your app is already instrumented with (latest) Amplitude Android SDK, use the Session Replay Android SDK Plugin.

If you use a provider other than Amplitude for in-product analytics, choose the standalone implementation.

Before you begin

Use the latest version of the Session Replay Middleware above version . For a list of available versions, see all release versions on Maven Central.

The Session Replay Middleware requires that:

1. Your application is Android-based.
2. You are using 2.40.1 or higher of the (maintenance) Amplitude Android SDK.
3. You can provide a device ID to the SDK.

Supported Android versions

Session replay supports down to Android 5.0 with a minimum SDK of 21 minSdk = 21. This should support over 99.6% of global Android devices according to Google's distribution data in Android Studio.

Quickstart

Add the latest version of the session replay middleware to your project dependencies

1// Install latest version from Maven Central
2implementation("com.amplitude:middleware-session-replay-android:@{$ android.session_replay.version $}")
3// You will also need the (maintenance) Amplitude Analytics SDK if it's not already installed
4implementation("com.amplitude:android-sdk:[2.40.1,3.0.0]")

Configure your application code.

 1import com.amplitude.api.Amplitude
 2import com.amplitude.api.SessionReplayMiddleware
 3 
 4// Initialize (maintenance) Amplitude Analytics SDK instance
 5val amplitude = Amplitude.getInstance()
 6    .initialize(this, AMPLITUDE_API_KEY)
 7    // Replay events will be flushed on close as well
 8    // If setFlushEventsOnClose(false) you must call flush() manually
 9    .setFlushEventsOnClose(true)
10 
11// Create Session Replay Middleware
12val sessionReplayMiddleware = SessionReplayMiddleware(amplitude, sampleRate = 1.0)
13 
14// Add session replay middleware
15// Recording will be handled automatically
16amplitude.addEventMiddleware(sessionReplayMiddleware)
17 
18// Track events
19amplitude.logEvent("Setup (maintenance) Amplitude Android SDK with session replay!")
20 
21// Send replay events to the server
22amplitude.uploadEvents()
23 
24// You can also call flush() on the middleware directly to only send replay events
25// sessionReplayMiddleware.flush()
26 
27// Always flush before app exit (onPause)
28// override fun Activity.onPause() { sessionReplayMiddleware.flush() }

Configuration

Pass the following option when you initialize the Session Replay middleware:

Mask on-screen data

By default session replay hides all user input (EditText, inputType="password")

The Session Replay SDK offers three ways to mask user input, text, and other View components. This can be enabled in both the layout XML and Kotlin/Java code.

Privacy tags in layout XML

Privacy control

Privacy methods on the Session Replay SDK

To use privacy methods first import the SessionReplay class. Then call one of the methods below.

1import com.amplitude.android.SessionReplay

Privacy Modifiers for Jetpack Compose

Three privacy Modifiers are included. Modifier.ampUnmask().ampMask().ampBlock(). When combined the most private modifier wins.

User opt-out

The Session Replay middleware follows the Android SDK's optOut setting, and doesn't support user opt-outs on its own.

1import com.amplitude.api.Amplitude
2import com.amplitude.api.SessionReplayMiddleware
3 
4// Set optOut on the Amplitude SDK
5val amplitude = Amplitude.getInstance()
6        .initialize(this, AMPLITUDE_API_KEY)
7        .setOptOut(true)
8 
9amplitude.addEventMiddleware(SessionReplayMiddleware(amplitude, /* session replay options */))

EU data residency

Session Replay is available to Amplitude Customers who use the EU data center. Set the serverZone configuration option to EU during initialization. For example:

1import com.amplitude.api.Amplitude
2import com.amplitude.api.SessionReplayMiddleware
3 
4// Set serverZone on the Amplitude SDK
5val amplitude = Amplitude.getInstance()
6        .initialize(this, AMPLITUDE_API_KEY)
7        .setServerZone(AmplitudeServerZone.EU)
8 
9amplitude.add(SessionReplayMiddleware(amplitude, /* session replay options */))

Sampling rate

By default, Session Replay captures 0% of sessions for replay. Use the sampleRate configuration option to set the percentage of total sessions that Session Replay captures. For example:

To set the sampleRate consider the monthly quota on your Session Replay plan. For example, if your monthly quota is 2,500,000 sessions, and you average 3,000,000 monthly sessions, your quota is 83% of your average sessions. In this case, to ensure sampling lasts through the month, set sampleRate to .83 or lower.

Keep the following in mind as you consider your sample rate:

• When you reach your monthly session quota, Amplitude stops capturing sessions for replay.
• Session quotas reset on the first of every month.
• Use sample rate to distribute your session quota over the course of a month, rather than using your full quota at the beginning of the month.
• To find the best sample rate, Amplitude recommends that you start low, for example .01. If this value doesn't capture enough replays, raise the rate over the course of a few days. For ways to monitor the number of session replays captured, see View the number of captured sessions.
• Replays with processing errors don't count toward your monthly quota. Replays with a retention error message have already been counted against the quota, when the session was still in the retention period.

1// This configuration samples 1% of all sessions
2amplitude.addEventMiddleware(SessionReplayMiddleware(amplitude, sampleRate = 0.01))

Disable replay collection

Once enabled, Session Replay runs on your app until either:

• The user leaves your app
• You call sessionReplayMiddleware.stopRecording()

Call sessionReplayMiddleware.stopRecording() before a user navigates to a restricted area of your app to disable replay collection while the user is in that area.

Call sessionReplayMiddleware.startRecording() to re-enable replay collection when the return to an unrestricted area of your app.

You can also use a feature flag product like Amplitude Experiment to create logic that enables or disables replay collection based on criteria like location. For example, you can create a feature flag that targets a specific user group, and add that to your initialization logic:

 1import com.amplitude.api.Amplitude
 2import com.amplitude.api.SessionReplayMiddleware
 3 
 4// Your existing initialization logic with Android SDK
 5val amplitude = Amplitude.getInstance().initialize(this, AMPLITUDE_API_KEY)
 6 
 7if (nonEUCountryFlagEnabled) {
 8  // Create and Install Session Replay Middleware
 9  val sessionReplayMiddleware = SessionReplayMiddleware(amplitude, sampleRate = 0.5)
10  amplitude.addEventMiddleware(sessionReplayMiddleware)
11}

Data retention, deletion, and privacy

Session replay uses existing Amplitude tools and APIs to handle privacy and deletion requests.

Retention period

If your Amplitude plan includes Session Replay, Amplitude retains raw replay data for 30 days from the date of ingestion.

If you purchase extra session volume, Amplitude retains raw replay data for 90 days from the date of ingestion. If you need a more strict policy, contact Amplitude support to set the value to 30 days.

Changes to the retention period impact replays ingested after the change. Sessions captured and ingested before a retention period change retain the previous retention period.

Replays that are outside of the retention period aren't viewable in Amplitude.

DSAR API

The Amplitude DSAR API returns metadata about session replays, but not the raw replay data. All events that are part of a session replay include a [Amplitude] Session Replay ID event property. This event provides information about the sessions collected for replay for the user, and includes all metadata collected with each event.

 1{
 2  "amplitude_id": 123456789,
 3  "app": 12345,
 4  "event_time": "2020-02-15 01:00:00.123456",
 5  "event_type": "first_event",
 6  "server_upload_time": "2020-02-18 01:00:00.234567",
 7  "device_id": "your device id",
 8  "user_properties": { ... }
 9  "event_properties": {
10    "[Amplitude] Session Replay ID": "cb6ade06-cbdf-4e0c-8156-32c2863379d6/1699922971244"
11  }
12  "session_id": 1699922971244,
13}

Data deletion

Session Replay uses Amplitude's User Privacy API to handle deletion requests. Successful deletion requests remove all session replays for the specified user.

When you delete the Amplitude project on which you use Session Replay, Amplitude deletes that replay data.

Bot filter

Session Replay uses the same block filter available in the Amplitude app. Session Replay doesn't block traffic based on event or user properties.

Session Replay storage

If a user opts out tracking in your app, use the optOut configuration option to disable replay collection for that user.

(alpha) Session Replay stores data in persistent storage, specifically the file system.

• Memory usage grows until you call flush() to transfer the session replay data to the server.
• Session data isn't retried on failure to transfer to the Amplitude servers.

Amplitude recommends setting amplitude.setFlushEventsOnClose(true) in the Amplitude SDK Configuration (the default) to send session data to the server on each app exit.

Known limitations

Keep the following limitations in mind as you implement Session Replay:

• (alpha) Session replay doesn't support all view components. Contact Amplitude (with a session replay link) for more information.

• (alpha) Session replay doesn't support Jetpack Compose.

• Session Replay doesn't stitch together replays from a single user across multiple projects. For example:

  • You instrument multiple apps as separate Amplitude projects with Session Replay enabled in each.
  • A known user begins on one app, and then switch to another.
  • Amplitude captures both sessions.
  • The replay for each session is available for view in the corresponding host project.

• The User Sessions chart doesn't show session replays if your organization uses a custom session definition.

• Session Replay can't capture the following Android views:

  • WebView
  • MapView
  • Canvas Views

Multiple Amplitude instances

Session Replay supports attaching to a single instance of the Amplitude SDK. If you have more than one instance instrumented in your application, make sure to start Session Replay on the instance that most relates to your project.

Troubleshooting

For more information about individual statuses and errors, see the Session Replay Ingestion Monitor.

View components don't appear in replay

(alpha) Session replay is in alpha and doesn't support all Android View components.

Captured sessions contain limited information

Session Replay requires that the Android SDK sets sessionId and deviceId at a minimum. If you instrument events outside of the Android SDK, Amplitude doesn't tag those events as part of the session replay. This means you can't use tools like Funnel, Segmentation, or Journeys charts to find session replays. You can find session replays with the User Sessions chart or through User Lookup.

If you use a method other than the Android SDK to instrument your events, consider using the Session Replay Standalone SDK for Android.

Replay length and session length don't match

In some scenarios, the length of a replay may exceed the time between the [Amplitude] Start Session and [Amplitude] End Session events. This happens when a user closes the [Amplitude] End Session occurs, but before the Android SDK and Session Replay middleware can process it. When the user visits the app again, the SDK and middleware process the event and send it to Amplitude, along with the replay. You can verify this scenario occurs if you see a discrepancy between the End Session Client Event Time and the Client Upload Time.

Session replays don't appear in Amplitude

Session replays may not appear in Amplitude due to:

• Lack of connectivity
• Failed to flush recording before exiting the app
• No events triggered through the Android SDK in the current session
• Sampling

Lack of connectivity

Ensure your app has access to the internet then try again.

No events triggered through the Android SDK in the current session

Session Replay requires that at least one event in the user's session has the [Amplitude] Session Replay ID property. If you instrument your events with a method other than the Android SDK, the Android SDK may send only the default Session Start and Session End events, which don't include this property.

For local testing, you can force a Session Start event to ensure that Session Replay functions.

1. In Amplitude, in the User Lookup Event Stream, you should see a Session Start event that includes the [Amplitude] Session Replay ID property. After processing, the Play Session button should appear for that session.

Sampling

As mentioned above, the default sampleRate for Session Replay is 0. Update the rate to a higher number. For more information see, Sampling rate.

Some sessions don't include the Session Replay ID property

Session replay doesn't require that all events in a session have the [Amplitude] Session Replay ID property, only that one event in the session has it. Reasons why [Amplitude] Session Replay ID may not be present in an event include:

• The user may have opted out or may not be part of the sample set given the current sampleRate. Increasing the sampleRate captures more sessions.
• Amplitude events may still send through your provider, but getSessionReplayProperties() doesn't return the [Amplitude] Session Replay ID property. This can result from optOut and sampleRate configuration settings. Check that optOut and sampleRate are set to include the session.

Session Replay processing errors

In general, replays should be available within minutes of ingestion. Delays or errors may be the result of one or more of the following:

• Mismatching API keys or Device IDs. This can happen if Session Replay and standard event instrumentation use different API keys or Device IDs.
• Session Replay references the wrong project.
• Short sessions. If a users bounces within a few seconds of initialization, the SDK may not have time to upload replay data.
• Page instrumentation. If Session Replay isn't implemented on all pages a user visits, their session may not capture properly.
• Replays older than the set retention period (defaults to 90 days).