Simulate visitor data with __rm_test

Use the __rm_test query parameter to preview a segment's content with synthetic visitor data instead of a real contact. It supplies test context to the installed RightMessage snippet.

A valid payload disables RightMessage analytics tracking and the normal segment-sync pass for that runtime instance. It does not publish a draft, grant debugger access, or authenticate the visitor. The page still uses its loaded configuration, normally the published project configuration.

Test URL and base64 encoding

The parameter value is standard base64 containing a JSON object. Its maximum encoded length is 10,000 characters. The runtime decodes with atob, parses JSON, and validates the resulting object during initialization.

Illustrative URL:

https://example.com/pricing?__rm_test=BASE64_JSON_VALUE

Use URL encoding for the parameter. Standard base64 can contain +, /, and =, so string concatenation without encoding can corrupt it. URL.searchParams.set handles the query encoding.

This illustrative browser code builds the URL with ASCII sample values:

const payload = {
	segments: {
		dim_workforge_role: 'seg_workforge_manager'
	}
};
const url = new URL('https://example.com/pricing');
url.searchParams.set('__rm_test', btoa(JSON.stringify(payload)));
console.log(url.toString());

For non-ASCII text, an ASCII-safe JSON serialization with Unicode escape sequences avoids btoa's character restriction. Do not treat arbitrary UTF-8 bytes as though the runtime applies a UTF-8 decoder after atob.

Payload schema

Both segments and context are optional. An empty object is valid and still activates test mode. Omit unused properties rather than passing unexpected types.

The validator checks ID prefixes, not whether the referenced group and segment exist in your loaded project. Use actual IDs from that project. A syntactically accepted payload with unrelated IDs does not establish the intended segmentation.

The serialized payload must not contain __proto__, constructor, or prototype anywhere, including within a string value. Unknown provider properties fail validation. For example, subscriberId, isAnonymous, and totalRevenue are not allowed provider-payload keys even though related values exist in normal visitor context.

The root validator ignores unknown root properties and checks segments and context only when their values are truthy. Falsy values such as null can therefore be accepted without supplying overrides. Use the object shapes above rather than relying on those validation gaps.

Provider context fields

The provider key must match the connected integration's runtime name. Only the matching provider object is applied. Without an integration, supplied provider context is ignored with a warning; valid segment overrides can still be used.

The validator checks the allowed keys but does not fully validate these nested value types. For example, a non-array tags value can pass the initial shape check and then fail when the overlay tries to map it. Passing validation is not proof that an arbitrary nested object is usable.

These values change the integration's template context, not its loaded profile data. They do not create a subscriber. Provider signal checks and Code-node methods such as RM.hasTag() and RM.getCustomField() read profile data, not this synthetic overlay. Use explicit segments overrides to preview a segment's content.

Illustrative payload, not executed. PROVIDER_RUNTIME_NAME must be replaced with the actual connected integration name:

{
	"segments": {
		"dim_workforge_role": "seg_workforge_manager"
	},
	"context": {
		"PROVIDER_RUNTIME_NAME": {
			"email": "visitor@example.com",
			"customFields": {
				"company": "WorkForge",
				"team_size": "12"
			},
			"nativeFields": {
				"first_name": "WorkForge visitor"
			},
			"tags": [{ "id": "tag_workforge_team", "name": "Team interest" }],
			"lists": [],
			"events": [],
			"purchases": []
		}
	}
}

With valid group and segment IDs from your project and a matching provider name, the selected segment is overridden. Templates see the supplied provider context, and RightMessage tracking is disabled. This example is illustrative, not an executed response or a provider delivery confirmation.

Test mode across reloads and navigation

The payload is read when the runtime initializes. Segment overrides apply after source prepopulation, and provider context overlays the normal context. Changing only the query string through a client-side route does not parse a new test payload. Reload the page to start with a different payload.

The test state remains in that initialized runtime across SPA navigation. There is no dedicated __rm_test cookie that guarantees the same simulation on a later full-page load. Preserve the parameter on each full-page test entry when needed.

To leave test mode:

1. Remove __rm_test from the URL.
2. Fully reload the page.

Deleting the parameter with History or calling reset does not reinitialize the tracking flag. Use a separate test browser because leaving test mode does not undo all changes to visitor storage or other side effects.

Invalid payload behavior

Malformed base64, invalid JSON, an encoded value over 10,000 characters, or a rejected shape logs [RightMessage] Failed to parse __rm_test data and leaves ordinary tracking enabled. An empty parameter does not activate test mode.

The debugger can report Test mode active for an accepted payload or Test mode unavailable for a validation failure. A URL containing the parameter is not itself evidence that analytics are suppressed.

A wrong provider name is different from invalid JSON. It can produce an accepted test mode with no matching provider overlay. Wrong segment IDs are also different from a decoding failure. Check the actual visitor context and selected content rather than relying on the URL's appearance.

For the underlying value paths, see Flow data and Liquid reference. For runtime commands, see Browser JavaScript commands and events.