Carry visitor context across domains

Visitors can move between your sites without losing their identity and choice answers. RightMessage passes that information through supported links, redirects, or a shared subdomain cookie. Both sites need the same RightMessage project installed.

For example, if WorkForge (opens in a new tab) sent someone to a second site through a RightMessage link offer, that site could use their earlier choice answers. The link passes the supported information. It doesn't give the sites shared access to all of each other's browser storage.

Which links carry visitor information?

A RightMessage link offer adds context when the destination has a different hostname. That includes another subdomain.

A flow's Redirect node carries context only when you enable Send subscriber data?. This setting starts off. It appears for an absolute URL, not a same-site path such as /pricing.html. See the Redirect node reference for its controls.

Ordinary links on your website don't start carrying context when you install RightMessage. Typing another domain into the address bar doesn't pass link context either.

What travels with the visitor?

The _rm query parameter can carry:

• The browser's visitor ID.
• An available provider contact ID and provider identifier.
• Stored segments from answered choice questions.
• Eligible campaign assignments.

RightMessage can include up to 128 campaign assignments, adding no more than 1,200 encoded characters. It considers assignments the visitor has already been exposed to first.

When adding assignments, RightMessage checks that the full encoded context stays within 3,500 characters. For links, its URL query representation must also fit that limit. Large context can therefore carry identity and answers without every campaign assignment.

The optional provider-data snapshot used in cookies can be dropped to reduce the size. If the basic context is still oversized, the encoder can return it anyway. The cookie code warns about large values but can't guarantee the browser will save them. Browser and storage restrictions can prevent a transfer.

Only stored answer-based segments travel as answers. The destination evaluates conditions based on its current URL, referral, and page behavior again. The handoff doesn't copy every typed input answer or the visitor's full activity history.

What happens to the URL parameter?

The destination reads URL context before checking the shared context cookie. It then removes _rm from the visible address through browser history replacement, without reloading the page.

The original request can still appear in server logs, and an earlier script may have already read it. Encoded context isn't encrypted. Don't publish a visitor-specific context link for everyone to use.

How do subdomains share context?

Where browser rules allow it, RightMessage saves context in an _rm_ctx cookie. A shared parent-domain cookie can preserve context between subdomains without adding a parameter to every link.

The cookie is configured for up to 365 days. Browser policies, cleared site data, and storage restrictions can shorten that time. On hosted domains with a public suffix, RightMessage can fall back to a host-only cookie. That cookie won't share context with sibling hosts. Localhost is excluded from this cookie behavior by default.

A cookie on one registered domain can't be read as a cookie on another. A cross-domain link provides the handoff between those sites.

Check a published handoff

Test with a synthetic contact following the normal published link or redirect. A debugger session intentionally doesn't send cross-domain context from offer links or Redirect nodes, so a forced preview won't test this handoff.

1. Follow the published link from the source site to a destination with the same project installed.
2. Compare the visitor identity and answered segments on both sites. Use the debugger to inspect them after the normal handoff.

The destination needs the same question and segment IDs to understand the answers. A different project's snippet won't make the projects interchangeable.

Does this work across devices?

No. Context travels with this browser's navigation or available cookie. It doesn't identify a separate phone or laptop. That device needs its own identification event, such as a supported email-link click.

See how visitor identification works for the ways a browser connects to a contact.