identify() & advanced matching
Tell AdsPing who the visitor is once — every later event inherits the identity automatically, on this page and on future visits.
What identify() does
One call, two effects:
- This session — the identity joins pb.js's advanced-matching pool, so every later
adsping('track', …)call carries it automatically. You don't repeat user data on each event. - Future events — the email and phone are also stored server-side against the visitor. Later events from the same visitor (even on another day) are enriched with them before being forwarded, which is what lifts your Event Match Quality. The other fields are not kept: they apply to this session only, so send them again on the next visit if you have them.
Call it whenever you learn who the visitor is: after login, after signup, or when a form is submitted.
Usage
adsping('identify', {
email: '[email protected]',
phone: '+1 415 555 1234',
firstName: 'Jane',
lastName: 'Doe',
city: 'San Francisco'
});Send only what you actually have — a lone email is already the strongest match signal. Every personal field is SHA-256 hashed before it reaches any destination; Meta, TikTok and Google only ever receive the hash.
Fields
| Field | Format | Example |
|---|---|---|
email | Email address, any case. | [email protected] |
phone | Any format — normalized to E.164 by country. | +1 415 555 1234 |
firstName | Given name, plain text. | Jane |
lastName | Family name, plain text. | Doe |
city | City name, plain text. | San Francisco |
You can pass the other match fields too (state, zipCode, country, dateOfBirth, gender, externalId) — they join the advanced-matching pool for this session and ride along on every later event.
What's captured automatically
pb.js already harvests identity without any identify() call:
- Form inputs — email and phone are picked up as the visitor types into recognizable fields (works with SPA forms that never fire a native submit).
- Click ids & cookies —
fbclid/gclid/ttclidfrom the URL,fbp/fbccookies. - Existing tags — values your site already passes to
fbq('init', …)are mirrored in. - dataLayer pushes — the
user_dataon a GA4 e-commerce push, if you have one.
Which identity wins
Everything in the list above is something we found, not something you told us — read off a form the visitor half-filled, off a call meant for Meta, off an array any script on the page can write to. Sometimes those describe a different person than the one the event is about: a back-office screen, a shared terminal, a container that fills an empty email field with a constant.
So per field, from strongest:
- The value on the
trackcall itself — you put it there, for this event. - What
identify()stated. - What we found on the page. It fills a field nobody stated; it never replaces one.
- What we stored for this visitor earlier — only from sources 1 and 2.
The practical consequence: one identify() after login is not overwritten by anything the page does afterwards, and a found identity never becomes the visitor's stored identity. If your container is the only writer to your dataLayer and you want its pushes to count as statements, see data-trust-datalayer.
[email protected], [email protected], noreply@…. A site that fills a missing email with the same value for every visitor hands them all one identity, which merges unrelated people and matches nobody. Send the field only when you have a real value; leave it out otherwise.Consent (GDPR / LDU)
If a visitor declines tracking consent, tell pb.js:
adsping('consent', 'revoke'); // visitor opted out
adsping('consent', 'grant'); // visitor opted (back) in- After
revoke, every event is flagged with Meta's Limited Data Use (data_processing_options: ["LDU"]) so Meta restricts how the data is processed. - The choice is persisted in a first-party cookie (
_pb_consent, ~13 months) — you call it once from your consent banner, not on every page.