Identify contacts after a form redirect

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 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 before using that handoff.

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.

For example, a resolved redirect to WorkForge (opens in a new tab) could look like this:

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 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.