# Avoid exposing contact identity in page URLs

Recognize your contacts without putting raw email addresses in page URLs, and check what your advertising and analytics scripts receive.

You can recognize contacts without putting their raw email addresses in page URLs. Use a supported on-page form or JavaScript identification method, then check what your other scripts receive. Identifying URLs can be read by page scripts and saved in server logs.

You'll need access to your forms, redirects, and analytics setup. Connect your email platform and install RightMessage on the destination page so it can look up the contact. Use a synthetic contact, such as `jordan@example.com`, while testing.

## Find where emails enter your URLs

Look through your email links and form redirects for raw email parameters, such as `?email=jordan%40example.com`.

Review your advertising and analytics providers' current data policies before sending identifying values through a URL. Replacing an email with a provider contact ID doesn't automatically make it anonymous or permitted. An ID can still identify a person when connected to other data.

## Use the supported method for your form

For a supported on-page form, use [website form identification](https://rightmessage.com/help/identifying-visitors-automatically) instead of adding the email to its redirect URL.

For a custom form, ask your developer to identify the visitor in the browser after the intended submission. The [JavaScript commands](https://rightmessage.com/help/javascript-hooks) distinguish email lookup from identification by provider ID. Use the command that matches the identifier you have.

If your email platform needs an identifying email link, follow its [integration guide](https://rightmessage.com/help/topics/esps-and-crms). Keep the documented parameter and expected identifier rather than inventing a substitute.

Don't turn on **Email Watcher** just to avoid URL parameters without reviewing how it works. It can capture an email before submission and mistake a colleague's or gift recipient's address for the visitor's own.

## Check identification and your analytics requests

1. Open a clean browser session.
2. Submit the form or follow the email link as your synthetic contact.
3. Check the expected identity in the [RightMessage debugger](https://rightmessage.com/help/using-the-rightmessage-debugger).
4. Inspect the destination URL and requests sent by your analytics and advertising scripts.
5. Confirm that those scripts aren't receiving data your policies prohibit.

Check the requests even if the address bar looks clean. Removing a parameter after the page loads doesn't undo the original request or prevent scripts from reading it earlier. RightMessage's cross-domain `_rm` parameter contains encoded context, not encrypted data.

You're done when RightMessage recognizes the intended contact without an unnecessary raw-email parameter, and your other scripts receive only permitted data. Identification working doesn't tell you how every other script handled the information.

If your form needs a controlled redirect where email lookup is appropriate, follow [identify contacts after a form redirect](https://rightmessage.com/help/identifying-visitors-with-email-query-parameters). The [identification FAQ](https://rightmessage.com/help/identity-and-cross-device-faq) covers the wider identity risks and what happens across devices.