# Identify a visitor

Every visitor starts anonymous: the script gives the browser an id and ties the visit to it. A visitor becomes a known person the moment Tracking learns an email address or a phone number for them, and from then on the visits before and after that moment belong to one person, on the `People` page and in the reports.

You tell Tracking who someone is. There are two ways to do it, and no others.

| Way | You do | Use it when |
|---|---|---|
| **An `identify` call** | Call `lt('identify', …)` where your code already learns the email address | Anywhere in the browser — a sign-up, a sign-in, a social login, a page a signed-in visitor loads |
| **The `email` on a backend event** | Put the address on the event you send to the Events API | Anything that happens after a sign-up, where the browser is not involved |

An `identify` call is dropped for a visitor in cookieless mode: a declining visitor cannot become a person, by design. See [What tracking does with a consent answer](/privacy/tracking-consent).

## Forms are not read

The tracking script does not look at your forms. It does not watch form submissions, it does not read field values, and sending a form never makes a visitor a known person on its own.

Nothing on the page is scanned for an email address or a phone number, whatever the field is called and whatever the visitor typed into it. The only personal data that leaves the browser is what you pass to `identify` yourself.

If people used to appear on the `People` page simply because visitors sent your sign-up form, that no longer happens. The replacement is one line in the code that already handles the submit:

```js
form.addEventListener('submit', () => {
  lt('identify', form.elements.email.value);
});
```

Put that call only on a form that holds the visitor's **own** address — a sign-up, a sign-in, a newsletter box. Not on a form that carries someone else's address: inviting a colleague, sending a gift, referring a friend. An address typed into one of those belongs to another human, and identifying the visitor with it records them as that person — every visit before and after included.

This is why the script no longer reads forms at all. From the outside the two kinds of form look identical and no heuristic can tell them apart; standing in your own submit handler, you can tell instantly.

It is worth knowing what going wrong looks like, because it does not announce itself. Nothing errors, no event is refused: the `People` page is simply wrong. And fixing the code afterwards does not undo it — the visits already attributed to the wrong person stay attributed to them.

Identity you already have is untouched. People identified before this changed keep their identifiers, their journeys and their status.

## Identify explicitly

Call it as soon as you know who the visitor is — after a sign-up, a sign-in, a social login, a checkout, or any step of a multi-step flow that hands you an email address:

```js
lt('identify', 'ada@acme.com');
lt('identify', 'ada@acme.com', { plan: 'pro', signup_source: 'pricing' });
```

The first argument after the command is the email address; the second is an optional object of traits, stored as properties of the event.

The other shape takes an object, and is the one to use when you have a phone number, or both:

```js
lt('identify', { email: 'ada@acme.com' });
lt('identify', { phone: '+15551234567', traits: { plan: 'pro' } });
lt('identify', { email: 'ada@acme.com', phone: '+15551234567' });
```

Only `email`, `phone` and `traits` are read from that object. A call with neither an email nor a phone number is ignored, so there is no harm in calling `identify` with whatever you happen to have.

**Call it again on every page load where the visitor is already signed in.** Repeating a known identity costs nothing and makes sure the visitor is recognised even if a cookie was lost.

### How the values are read

An email address is trimmed and lower-cased, so `Ada@Acme.com` and `ada@acme.com` are the same person.

Phone numbers are accepted conservatively, because a wrongly parsed number would merge two different people. A number in international form — a leading `+` and 8 to 15 digits — is always accepted. A plain 10- or 11-digit North American number is accepted too. Anything else is ignored, and the event still counts on its other signals. If you have the number in international form, send it that way.

## Identify from your backend

An event sent to the Events API carries an `email`, and that email identifies the person exactly as an `identify` call does — see [Record your own events](/acquire/tracking/events) and [Send revenue from your backend](/acquire/tracking/revenue). It is the sturdier route for anything that happens after a sign-up, because it does not depend on the visitor's browser, on their consent answer, or on an ad blocker.

## What a person looks like afterwards

The `People` page lists everyone Tracking has seen. Each row shows the person — their email address, or `Anonymous` and a short id when there is none yet — their status, when they were first and last seen, and where they came from. You can filter by status and search by email address, exactly or by prefix.

Status is one of three:

| Status | What it means |
|---|---|
| `Anonymous` | Seen, but no email or phone number yet |
| `Identified` | An email address or a phone number is known |
| `Customer` | Revenue has been recorded for them — see [Send revenue from your backend](/acquire/tracking/revenue) |

Opening a person shows their whole journey, newest event first, with the page, the source and the properties of each event — including the events from before they were identified. Beside it are the identity signals held for them (the email addresses, the phone numbers, the advertising click ids and the domains they were seen on), their lifetime value, and, where there is one, the attribution decision for their journey.

**MCP.** [`tracking_profiles_list`](/reference/mcp-tools/tracking_profiles_list) and [`tracking_profiles_get`](/reference/mcp-tools/tracking_profiles_get) read the same list and the same person.

## Export or delete a person

A person can be exported or deleted from their own page. **Deleting removes the person, their identifiers and their events.**

**MCP.** [`tracking_profiles_export`](/reference/mcp-tools/tracking_profiles_export) and [`tracking_profiles_delete`](/reference/mcp-tools/tracking_profiles_delete).

## The same person, twice

People do not stay on one device or one identifier.

- **Two devices.** A visitor who browses on a phone and later signs up on a laptop starts as two anonymous visitors. As soon as the same email address is seen on both they become one person, and the earlier anonymous browsing is part of that person's journey.
- **Two identifiers.** Someone who first gives a phone number and later an email address, in either order, stays one person: each new identifier is added to the one already known.
- **Two people on one browser.** A shared or borrowed browser gives two identities to the same anonymous id. An email address or a phone number is a stronger signal than a shared browser, so the identified people are kept apart rather than folded together on that evidence.

When two records do turn out to be one person, the older record survives with its history now spanning both, and a `Customer` status is never lost in the process. This happens on its own, on the next event that ties the two together — there is nothing to merge by hand.

An email address or a phone number is read as identity from an `identify` call and from the events sent to the Events API. **It is never picked up from the properties you attach to an ordinary `track` call, and it is never picked up from a form.**

## Next steps

- [Send revenue from your backend](/acquire/tracking/revenue): tie money to the person and make them a customer.
- [Install the tracking script](/acquire/tracking/install): carry one identity across several domains you own.
- [Read the attribution reports](/acquire/tracking/reports): what a person's journey was credited to, and why.
- [Fix a person who stays anonymous](/acquire/tracking/troubleshooting): the checks in the order worth making.