> ## Documentation Index
> Fetch the complete documentation index at: https://docs.usertick.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Identify your users

> Send your user ID and traits with each response, prove them with a hash from your server, and link responses to contacts.

Without identification, a response records the answers but not the person who gave them. When your page passes its signed-in user to `Usertick.identify()`, every response from that person carries your user ID. The inbox then shows who answered, responses link to your contacts, and integrations name the same person in your other tools.

## Identify the signed-in user

After your page knows who is signed in, call `identify()` on every page load. With the script tag, `Usertick` exists once the Usertick code has loaded, so the call waits for the page's `load` event when it isn't there yet.

```js theme={null}
const identify = () =>
  Usertick.identify("user_123", {
    plan: "pro",
    email: "maya@usertick.com",
    name: "Maya Chen",
    company: "Usertick",
  });

if (window.Usertick) identify();
else window.addEventListener("load", identify);
```

The widget uses the identity in two places:

* On the page, the [sign-in state and trait rules](https://docs.usertick.com/surveys/targeting.md#sign-in-state-and-traits) and the variant conditions read it, and every survey on the page is checked again right away.
* When the visitor submits a response, the response carries the user ID, the traits, the [hash](#verify-who-the-visitor-is) and an anonymous ID for this browser. Page views and surveys that only open carry none of it, and nothing is sent before Submit.

The traits `email`, `name` and `company` become the person's email, name and company in the inbox.

The anonymous ID is a random ID the widget creates for each browser. It is kept in a first-party cookie, or in `localStorage` when cookies are blocked. The user ID, the traits and the hash are kept in `localStorage` until `logout()` or `reset()`. A response that couldn't be sent yet waits in the browser for up to 7 days with the identity it had. [Cookies and consent](https://docs.usertick.com/installation/cookies-and-consent.md) lists every key the widget stores.

| Value | Limit |
| - | - |
| User ID | A string of up to 256 characters |
| Traits | Up to 50, with keys of 1 to 64 characters. Each value is a string of up to 256 characters, a number, or true or false |
| Hash | 64 hex characters |

The widget drops anything past these limits and logs a warning in the browser console. It also logs a warning and ignores the value when the user ID isn't a string, when the hash is passed as the third argument itself instead of as `{ hash }`, and when a new hash isn't 64 hex characters, in which case the stored hash stays.

Later calls with the same ID merge their traits into the stored ones and keep the hash, so `Usertick.identify("user_123", { seats: 15 })` updates one trait. A call with a different user's ID starts with no traits and no hash, so one person's traits never carry over to the next.

## Sign the user out

When the user signs out, call `logout()`:

```js theme={null}
Usertick.logout();
```

`logout()` forgets the ID, the traits and the hash, and `identify(null)` does the same. The next response is anonymous and carries a new anonymous ID, so on a shared computer the next person's answers are never tied to this user.

Integrations never name a person by the anonymous ID. Analytics tools such as Segment, Mixpanel and Amplitude receive only responses that carry your user ID from `identify()`, so an anonymous response never reaches them.

The list of surveys this browser has seen is kept, so a survey that was already answered doesn't come back. While nobody is signed in, `logout()` keeps the anonymous ID, so the call is safe on every anonymous page load.

## Reset for testing

```js theme={null}
Usertick.reset();
```

`reset()` forgets everything the widget remembers in this browser: the surveys it has seen, the visit counters, the anonymous ID and the `identify()` record with its hash. Responses waiting to be sent are kept. The method is meant for testing; to sign someone out, use `logout()`.

## Turn it off

Identity is sent by default, and two switches turn it off:

* **Send user identity with responses**, on each site in **Settings → Sites**. When it is off, no response from that site's widget carries a user ID, traits, a hash or an anonymous ID, whatever the page passes to `identify()`, and Usertick drops any identity that reaches it from that site anyway. The sign-in state and trait rules on the page keep working. Link, QR and email surveys have no site, so this switch doesn't affect them.
* **Anonymous responses**, on each survey, under **Privacy** on the **Settings** tab of the editor's **Survey** step. When it is on, the survey's responses carry no user ID, traits or anonymous ID, on your website and on the survey's link, QR and email pages.

Answers to a [Contact question](https://docs.usertick.com/surveys/question-types.md#contact-details) are kept with either switch, because they are answers. An email send gives each person their own link, so a response from it stays tied to the contact it was sent to.

## What the inbox shows

A response opened in the [inbox](https://docs.usertick.com/results/inbox.md) shows who answered:

* the user ID, name, email and company,
* a mark when a [hash](#verify-who-the-visitor-is) proved the identity,
* the traits, marked when they didn't come signed,
* what the person entered in a Contact question,
* the contact the response is linked to.

The email shown follows one order: the contact an email send went to, then an email from `identify()` that a hash proved, then the email entered in a Contact question, then an email from `identify()` without a valid hash. An answer to any other question is never taken as the person's email, even when it is an email address.

The inbox also filters by who answered (**Identified**, **Verified**, **Not verified** or **Anonymous**), by one user ID, by trait values such as `plan` is `pro` (up to 10, all of which must match), and by whether the response is linked to a contact. Grouped by who answered, the list uses the same words. Exports carry a **Verified** column next to the email.

## How a response links to a contact

Usertick links each new response to a contact in **Email → Contacts** when it can, and the first match wins:

1. The contact an email send went to.
2. A verified user ID that matches a contact's **External ID**.
3. A verified email from `identify()` that matches a contact's email. When that contact has no external ID yet, it gets the user ID.
4. The email entered in a Contact question that matches a contact's email.

When nothing matches, Usertick creates the contact:

* A verified identity with an email creates a contact with that email, the name and the user ID as its external ID.
* Otherwise, an email entered in a Contact question creates a contact with that email and name.
* An identity without a valid hash never creates or changes a contact.

A name only fills a contact's empty name and never replaces one. Answers someone gave anonymously before signing in aren't merged into the contact.

Each contact shows its external ID and every response linked to it, from the website, links and email, with the reason for the link. An external ID can also be set by hand, and one external ID belongs to one contact.

## Verify who the visitor is

Anyone can call `identify()` from the browser console with any ID. To prove that the ID is genuine, your server computes a hash of the user ID with a secret key, and the page passes it as the third argument:

```js theme={null}
Usertick.identify("user_123", { plan: "pro" }, { hash: "HASH_FROM_YOUR_SERVER" });
```

The hash is computed once per user and never expires. Verification is optional and available on every plan. [Verify your users](https://docs.usertick.com/installation/verify-users.md) explains when you need it, how to compute the hash in seven languages, the verification modes and how to rotate the key.

## Link surveys

A [link survey](https://docs.usertick.com/channels/link.md) takes the same identity from its address. When your system builds the link for a person, add `uid=user_123&uh=HASH`, with the hash your server computes for that user ID. The page reads both, removes them from the address bar, and sends them with the response, and a reload of the same tab keeps them. A link carries no traits, and `uid` without `uh` arrives unverified. Without them, the page sends only its own anonymous ID, and a survey with **Anonymous responses** on sends neither. See [Verify link survey readers](https://docs.usertick.com/installation/verify-users.md#verify-link-survey-readers).

## Integrations

Tools that track people receive your user ID, the email or both, and never the anonymous ID. Mixpanel, Amplitude and Segment need your user ID, Klaviyo and Mailchimp need the email, and Customer.io, Braze, Iterable and Intercom take either. A response without what the tool needs is skipped, and the workflow's **Activity** gives the reason. In **Monitor** and **Enforced**, an email that came without a valid hash never reaches a CRM, a mailing list or an event tool. See [how a tool knows who answered](https://docs.usertick.com/integrations/overview.md#how-a-tool-knows-who-answered).

Google Analytics, FullStory and UXCam get no identity at all. Their event carries the survey ID, the response ID and the score. See [Google Analytics, FullStory and UXCam](https://docs.usertick.com/integrations/page-events.md).

A [workflow](https://docs.usertick.com/workflows/overview.md) can also check who answered in its conditions: identified or not, verified, linked to a contact, the user ID, the email or a trait. Its messages can show the same values.

## Privacy

* **Only with a response.** The user ID, the traits and the hash leave the page only when the visitor submits a response, and never when either switch is off.
* **A guard against personal data in the wrong place.** The `email` trait must be one email address, or it is dropped. The name and every other trait value are dropped when they hold an email address, a card number, an IBAN or a phone number written as one (with a leading `+`, parentheses or three or more groups). Plain digit strings, dates and IPv4 addresses are kept, so IDs and timestamps pass. The user ID isn't checked, because many sites use the email as the ID.
* **The AI never sees who answered.** The AI that reads responses gets no user ID, traits, email or name. From a Contact question it gets only the message, never the name, email, phone or company.
* **Erase a person.** To delete everything one person sent, call the API with their email or your user ID. See [Erase personal data](https://docs.usertick.com/developers/api/erasure.md#erase-everything-one-person-sent).


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.