# Identify contacts after a form redirect

Connect a form submission to the visitor's browser so you can recognize the contact and save their survey answers to your email platform.

You can recognize someone after they submit an external form, then save their survey answers to the right contact. For integrations that support it, an `email` parameter passes the submitted address to a thank-you page where RightMessage looks up the contact.

You'll need your email platform connected, the RightMessage snippet on the thank-you page, and access to your form tool's redirect settings. Creating a contact on your server doesn't identify the browser by itself. The redirect supplies that connection.

## Check which parameter your platform needs

Check your [provider's integration guide](https://rightmessage.com/help/topics/esps-and-crms) before editing the redirect. The generic `email` parameter isn't supported by every integration:

- Braze uses `rm_braze` or its supported browser SDK identity.
- Drip uses `__s` or its supported browser identity.
- Intercom uses `rm_ic` or its supported Messenger identity.
- Klaviyo uses `rm_kl` with the email, or `_kx` from an identifying Klaviyo email link.

Use the value your provider expects. Don't rename its parameter to `email`.

For providers that only look up existing contacts, the contact must exist before RightMessage can identify it. Userlist's email lookup uses a create-or-update endpoint, so it can create or update a user. Read the [Userlist integration guide](https://rightmessage.com/help/integrating-rightmessage-with-userlist) before using that handoff.

> **Warning**
>
> An email in a URL can be read by page scripts and appear in logs. If your page runs advertising or analytics scripts, review [safer identification choices](https://rightmessage.com/help/identifying-visitors-on-sites-with-ad-networks) before using this method.

## Add the email to your redirect

For a provider that supports `email`:

1. Choose a real thank-you page on your website that loads your project's RightMessage snippet.
2. Set your external form's post-submission redirect to that page.
3. Add an `email` query parameter using the form tool's merge syntax for the submitted email field. URL-encode the value.
4. Save the form's redirect settings.
5. If you also changed a RightMessage question, mapping, or widget, [review and publish those changes](https://rightmessage.com/help/publishing-your-changes).

For example, a resolved redirect to [WorkForge](https://workforge.rightmessage.com) could look like this:

```text
https://workforge.rightmessage.com/contact.html?email=jordan%40example.com
```

Use your own page and your form tool's merge syntax, not this fixed test address. If the destination already has a query string, add the email with `&` rather than a second `?`.

## Try it with an existing contact

Use a clean browser session with no previous RightMessage identity. The generic `email` parameter is used when no subscriber identifier is already saved. It isn't a reliable way to switch an identified browser to someone else.

1. Create or choose a synthetic contact in your connected platform, such as `jordan@example.com`.
2. Submit the external form with that contact's email.
3. Check that the redirect contains the submitted address, not an unexpanded merge tag.
4. Open the [RightMessage debugger](https://rightmessage.com/help/using-the-rightmessage-debugger) and check the browser's identity.
5. Answer one mapped survey question.
6. Open the contact in your email platform and check the destination field or tag.

A successful lookup connects this browser to the contact. Later visits in the same browser can reuse the identity. The field or tag check confirms that the answer synced too.

## Try it with a new contact

Repeat the steps in a separate clean browser session with a new synthetic email. If your provider only looks up existing contacts, check that the external form creates the contact first. Userlist's create-or-update lookup works differently, as noted above.

A form that uses an asynchronous service can redirect before the provider has created the record. RightMessage retries the lookup a limited number of times, but a delayed record may still be unavailable. Check the provider record and the browser's identity rather than relying on a fixed wait.

An identifying URL isn't a login. Anyone with the URL can follow it, so don't use it to protect private content.

When both test contacts have the right browser identity and their mapped answer appears in your email platform, the handoff is working. If either check fails, use [anonymous visitor and contact-update troubleshooting](https://rightmessage.com/help/why-visitors-appear-as-anonymous-in-your-people-feed).