Identity and devices

Visitors start anonymous. The tag keeps two ids in localStorage and a cookie:

• pixelfox_did, the anonymous distinct id. Replaced by your user id on identify(), rotated by reset().
• pixelfox_device_id, the device id, sent as $device_id on every event. It survives identify() and reset() (logging out on a laptop does not make it a different laptop) and is removed only by optOut().

When a visitor identifies - login, checkout, newsletter signup - call:

pixelfox.identify("user-123", { email: "[email protected]" });

Identity stitching is part of the Pro plan and above. On Free, events still carry whatever email or phone they arrive with, and those still become match keys for the ad platforms, but devices are not linked into one person and events collected while on Free are not stitched retroactively after an upgrade.

What happens on identify

1. The tag switches its distinct_id to your user id and sends an $identify event carrying the email/phone, the anonymous id it used before ($anon_distinct_id) and the device id.
2. The backend finds or creates an identity for that email or phone on your site, adds all three ids to it, and backfills the events those ids already sent, so the anonymous history counts toward the person.
3. The device is attached to the person, and the person is added to the platform-wide person graph (hashed email and phone only).
4. From then on every event from any of the person's ids is stamped with external_id: <identity id> before fan-out, and the dashboard shows one person with their devices.

A person has many devices: the same email identified on a phone and on a laptop is one person with two devices, and both devices' history belongs to them. If an email lands on one identity row and the phone on another, the two are merged the moment an identify carries both.

A device whose storage was cleared

Clearing cookies gives the tag a fresh device id. The backend computes a fingerprint on its side from what the tag sends anyway - user agent, screen size, language and timezone - hashed with a platform secret. A new device whose fingerprint matches a device seen with a person in the last 30 days is attached to that person. The fingerprint never leaves the backend and never creates a person by itself; it only re-attaches one.

Across PixelFox sites

A person identified on one PixelFox site is a known person on every other one. When a device arrives on your site that another site already knows - by device id or by fingerprint - your site gets an identity for that person, marked known from the network, with the email and phone copied in, and the person's match keys ride on your conversions from the first event.

This is sharing between merchants: your site receives contact details the visitor gave to another site. Your cookie notice and privacy policy must disclose that PixelFox recognises visitors across the sites that use it, and the visitor's consent must cover it (events sent under a denied $consent are never linked and record no device).

Why it matters

• Match quality - ad platforms match server events to real users via hashed email/phone and a stable external id. Stitching raises your match quality score and therefore your attributed conversions.
• Cross-device - a phone-then-desktop purchase is one journey, not an abandoned cart plus a mystery order.
• Return visits - a returning person is recognised without re-login, and a known person is recognised on their first visit to a new site.
• Segments - the person's segments (new, repeat buyer, cart abandoner…) are computed per person, not per browser. See segments.

Privacy

Emails are normalised (trimmed, lowercased) and phones reduced to E.164 digits before matching; both are SHA-256 hashed before ever being sent to a destination, and only hashes exist in the person graph. Server-minted ids (the cookieless fallback id and fingerprints) are never sent to an ad platform as an external id. Calling pixelfox.reset() (e.g. on logout of a shared device) starts a fresh anonymous visitor; the device stays the same device.