# How visitor identification works

You'll learn how RightMessage recognizes a contact in their browser, uses their CRM data, and remembers them when they return.

Identification lets you use a contact's existing data to decide what to show them on your website. A supported form, email link, or another identification method connects their browser to their contact record.

Connecting your email platform alone doesn't identify everyone who visits. Until the browser is identified, you can still use page visits, campaign parameters, device information, and answers to show something relevant.

## What identification changes

Imagine a subscriber visiting the [WorkForge](https://workforge.rightmessage.com) [pricing page](https://workforge.rightmessage.com/pricing.html). Without an identifying link or a previous identification event, RightMessage sees a browser on that page, not a subscriber record.

When the subscriber follows an identifying email link, RightMessage looks up the identifier through the connected platform. It can then use the contact's available fields, tags, and other supported data. WorkForge can show a product demo instead of asking that subscriber to opt in again.

Knowing an email address, finding its provider record, and updating a field are separate steps. [Visitor data and identity](https://rightmessage.com/help/visitor-data-and-identity) explains how they fit together.

## Ways a browser becomes identified

Your setup determines how RightMessage gets the contact's identity:

- An identifying **Email** question or a RightMessage form captures an email through its configured contact action. A question's **Identify the visitor** and consent settings decide whether the answer identifies the visitor.
- A **Popup** with **After a form is submitted** configured watches a supported website form and captures its email. Installing the snippet alone doesn't turn on this form observer. HubSpot has a separate supported form-callback path.
- An email link includes your provider's identifying parameter. Some platforms add it automatically. Others need a merge tag in the link.
- A page URL includes a supported identifying email parameter. Braze, Drip, Intercom, and Klaviyo don't use the generic `email` parameter. See [form redirect identification](https://rightmessage.com/help/identifying-visitors-with-email-query-parameters).
- Optional **Email Watcher** captures a valid email when the visitor leaves a field or presses Enter. It's off by default and can run before submission.
- A developer uses the JavaScript identity API, or a supported provider supplies an identifying cookie or browser integration.

For setup, see [website form identification](https://rightmessage.com/help/identifying-visitors-automatically) or your [email platform's integration guide](https://rightmessage.com/help/topics/esps-and-crms).

## Each provider uses its own identifier

Use the parameter and value your provider expects. Some need a contact ID. Others accept an email through a documented parameter. You can't swap one type for another.

ActiveCampaign uses `rm_ac` with the contact identifier. Kit uses `ck_subscriber_id`. Klaviyo's `rm_kl` parameter accepts the subscriber's email and resolves it to a profile ID.

Klaviyo also resolves its `_kx` email-link exchange identifier through the server. That value isn't a contact ID you can copy into another provider's parameter. Klaviyo checks an explicit identifier first, then saved subscriber state, the exchange identifier, its SDK cookie, and an inferred email. If a lookup fails, that doesn't tell you the person isn't a subscriber.

## What the browser remembers

After successful identification, RightMessage saves the recognized-contact state in that browser. Return visits can use it while the relevant browser storage remains available.

Clearing cookies or site data, changing browser profiles, or using another device can remove that connection. Each new device needs its own identification event. Once both devices are identified, their activity can be associated with the same contact. RightMessage doesn't silently recognize every device a person owns.

[Cross-domain context](https://rightmessage.com/help/how-visitor-context-is-preserved-across-different-domains) can carry supported context between configured sites. It doesn't provide automatic cross-device recognition.

## Identifying visitors with JavaScript

The JavaScript API treats provider IDs and email lookups differently:

| If you need to…                                   | Method                                                                                 |
| ------------------------------------------------- | -------------------------------------------------------------------------------------- |
| Select a provider contact and refresh its profile | `identify(contactId)`. Requires a connected integration.                               |
| Look up an email and use the matching contact     | `identifyByEmail(email)`. Requires an integration and an email.                        |
| Resolve an identifier through your provider       | `lookup(id)`. Looking up a contact doesn't itself select that contact for the browser. |

Email lookup isn't read-only for every provider. Userlist uses its create-or-update endpoint to resolve emails, so identification can create or update a user.

The [browser JavaScript commands reference](https://rightmessage.com/help/javascript-hooks) has the call syntax. Never use personalization identity as authentication or permission to show private account data.

To see what RightMessage knows about your current browser, open the [debugger](https://rightmessage.com/help/using-the-rightmessage-debugger). If an identity or field update is missing, follow [anonymous visitor troubleshooting](https://rightmessage.com/help/why-visitors-appear-as-anonymous-in-your-people-feed).