Identify a visitor

Identify a visitor with their own email or phone using lt('identify', …), or include their email in a backend event. Tracking joins that identity to earlier browser activity when it can. Cookieless browser visits have no identity to join.

Before you start: install the tracking snippet for browser calls, or prepare a public access key for backend events. The examples use Acme and Ada; replace the sample address, phone, and traits with the visitor’s values.

Choose the path that already has the visitor’s identity:

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

The browser drops an entire identify call in cookieless mode. This does not gate the separate backend identity path. See Tracking and consent.

Forms are not read

Submitting a form does not identify a visitor. Tracking neither reads field values nor watches form submissions.

The script does not search the page for emails or phones, regardless of field names. Browser identification uses only the values your code passes to identify.

If you relied on earlier automatic form identification, add an explicit call to the handler that already knows the visitor’s address:

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

Use this only for the visitor’s own address, such as a sign-up, sign-in, or newsletter form. Do not identify from a colleague invitation, gift, or referral form: it would assign earlier and later visits to someone else.

Your application knows what a form means; the script cannot reliably distinguish the visitor’s address from a recipient’s. Identification therefore belongs in your handler.

A wrong address can produce an incorrect person record without an error or rejected event. Correcting the handler later does not undo activity already assigned to that identity.

Previously identified people retain their identifiers, journeys, and status after automatic form reading was removed.

Identify explicitly

Add the call where you learn the visitor’s identity: sign-up, sign-in, social login, checkout, or the relevant step of a multi-step flow.

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

Pass the email after the command. The optional third argument holds traits, stored as properties of the identification event.

For a phone number, or both identifiers, use the object form:

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 the object. Calls without an email or phone are ignored.

Repeat identify on every signed-in page load. Repeating a known identity lets Tracking recognize the visitor after cookie loss.
Verify it works: open People. Confirm that the visitor is Identified and that their earlier tracked browsing appears in the journey.

How the values are read

Email matching trims spaces and ignores case: Ada@Acme.com and ada@acme.com resolve to the same identity.

Prefer international phone format: + followed by 8–15 digits. Plain 10- or 11-digit North American numbers are also accepted. Other formats are ignored to avoid merging different people; the event can still count using other signals.

Identify from your backend

Include email in an Events API event to identify someone from your backend. This path does not depend on the browser, its consent answer, or an ad blocker. You remain responsible for whether you may send that data. See Backend events and Revenue events.

What a person looks like afterwards

Use People to find person records. Rows show an email, or Anonymous with a short id, plus status, first and last seen times, and source. Filter by status or search for an exact email or email prefix.

These statuses distinguish the records:

Status	What it means
`Anonymous`	Seen, but no email or phone number yet
`Identified`	An email address or a phone number is known
`Customer`	A `subscription_started` or `payment` event is tied to them — see Send revenue from your backend

Open a row to read the journey, newest event first, including activity before identification. Events show page, source, and properties. The profile also shows known emails, phones, ad click ids, domains, lifetime value, and any attribution decision.

MCP. tracking_profiles_list and tracking_profiles_get read the same list and the same person.

Export or delete a person

Export or delete a person from their profile page. Deletion removes the person, their identifiers, and their events.

MCP. tracking_profiles_export and tracking_profiles_delete. An erasure is one of the long-running actions a workflow can wait on — see trigger a workflow from a tracked event.

The same person, twice

Tracking joins records across devices and identifiers while keeping stronger conflicting identities apart:

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 an event links two records to the same person, Tracking merges them into the older record automatically. Both histories are retained and Customer status survives; there is no manual merge step.

Identity is read from identify calls and backend Events API events. An email or phone in ordinary track properties does not identify anyone, and neither does a form submission.

Next steps

Send revenue from your backend: tie money to the person and make them a customer.
Install the tracking script: carry one identity across several domains you own.
Read the attribution reports: what a person’s journey was credited to, and why.
Trigger a workflow from a tracked event: the Visitor identified trigger fires on the call above.
Fix a person who stays anonymous: the checks in the order worth making.

Was this page helpful?